How AI agents get live data and tools, and how to choose

A language model on its own knows what it learned in training. To answer “what are people saying about our new menu this week?”, “which legal entity is behind this fund?” or “what did this company file last month?”, an agent has to reach something outside itself.

The ways an agent reaches the outside world

Four of them bring back information:

1. Search. A search API returns ranked results and snippets for a query. It is the fastest way to find out what exists and what is new.
2. Reading web pages. Page extraction and crawling tools turn pages into clean text, Markdown or structured data an agent can read. Use them when you know where the answer lives, such as a help centre or a pricing page.
3. Specialist data APIs. Official registries, maps and business listings, social media data, company and jobs data. These return structured facts, often more reliably than reading pages, from the organisation that keeps the record.
4. Your own systems. Internal databases, documents and tools, connected the same way.

A fifth kind of tool makes things: image, video and voice models. What they return is new content, not information about the world. It can be exactly what you asked for, but it is not evidence, and the questions to ask are about quality, rights and cost rather than sources.

Most useful requests combine several. A shortlist of local businesses might use listings to find them, reviews to rank them and their own websites to check opening hours.

How agents connect to them

Agents call outside systems through tools: functions the model can decide to use, with a name, a description and inputs. One open way to offer tools is the Model Context Protocol (MCP). In its own words, MCP is “an open-source standard for connecting AI applications to external systems.” Anthropic introduced it in November 2024. Several assistants, including Claude and ChatGPT, can connect to MCP servers; what is available depends on the product, plan and settings. IKAG reaches assistants through its own MCP server.

MCP standardises the connection. It does not decide which source is right for a request. If you connect ten MCP servers, the model chooses between ten sets of tools from their descriptions, and every server brings its own key, pricing and terms.

A worked example: one question, three sources

Take “which legal entity is behind Apple, and where is it incorporated?” Search would find many pages about Apple. A registry holds the record itself, so this is how the question goes through public registries, using records captured on 29 August 2026 (SEC EDGAR) and 7 October 2026 (GLEIF and Wikidata).

• A name alone is not enough. Names are not unique. Searching the global LEI register for the name “SPDR S&P 500 ETF Trust”, for example, returns three different entities, one of them inactive. A careful tool lists them and asks which one you mean.
• An identifier is. With Apple’s SEC identifier, CIK 0000320193, the SEC EDGAR record gives the legal name, Apple Inc., and California as the state of incorporation.
• Community data can agree, not prove. Wikidata’s item for Apple gives the same name. That is useful support, but Wikidata is edited by its community, so it never decides the answer on its own.
• Some things stay unknown. The SEC record does not say whether the company is active, and it is not dated, so you cannot call its facts current. The GLEIF register has no LEI registered against that CIK, so an LEI cannot be attached from these records alone.

Field	Value	From
Legal name	Apple Inc.	SEC EDGAR; Wikidata agrees
Incorporated in	California, United States	SEC EDGAR
Active?	Not in these records	None
LEI	Not linked by a record	None

The answer is narrower than “everything about Apple”, and every part of it can be checked.

How to choose a source

Kind of source	Best for	Watch for
Search	Finding things, news, broad questions	Snippets are not answers; check the page
Reading web pages	Known pages, documentation, prices	Site terms and robots.txt; pages change shape
Specialist data APIs	Structured facts, registries, listings, social data	Coverage gaps; pricing by plan, usage or both
Your own systems	Private knowledge	Access control
Models that make things	Images, video, voice	Quality varies by model; usage rights

Five questions decide most choices:

• Freshness. How recent does the answer need to be, and does the source say when it last updated the fact?
• Authority. Is there a primary source, such as an official registry?
• Coverage. Does this source cover the place, language or platform you need?
• Cost. What does a request cost, and how is it billed?
• Terms. May you use the data this way? Respect robots.txt (standardised as RFC 9309 in 2022), terms of service and data protection law.

Why provenance matters

When an agent combines several sources, the answer is only as trustworthy as your ability to check it. Prefer sources and tools that return the record behind each value and when the source last updated it, and that say what they could not establish. Then a person can verify the answer, and an agent can weigh sources instead of guessing.

Where IKAG fits

IKAG is building one connection between AI assistants and agents and specialist sources like these. It is opening to early users and data partners first. Its first capability, company legal identity from the GLEIF and SEC EDGAR registries with Wikidata as support, run offline on captured records, behaves as the example above does. Web pages, listings, social media data and other sources come next. You can inspect real output from the first capability.