Live Web Search Your Agent Can Actually Call

Copy this line to your agent to give your agent live web search at runtime.

set up https://monid.ai/SKILL.md and use exa /search to fetch fresh web results and contents inside your agent loop

An agent should fetch the web when it is answering, not weeks earlier when someone built its index. We ship live web search as a single runtime call: Exa's /search endpoint on Monid returns ranked results and the extracted page contents in the same response, so the agent reads fresh sources the moment it needs them and skips the separate fetch-and-parse step entirely. Monid is a pay-per-call data API marketplace: one integration and one wallet reach hundreds of external data endpoints across web search, scraping, enrichment, social data, and generative media, without a separate signup per vendor. This post is about why we put web search behind that same interface, and the few principles that make it work for an agent rather than a nightly batch job.

TL;DR

• A pre-built vector index answers questions about the past. An agent answering questions about right now needs a call it can make mid-reasoning, which is what exa /search is.
• One call returns ranked results and the cleaned page text together, so there is no second scrape-and-parse hop to wire, retry, or pay for separately.
• Web search lives in the same catalog and the same wallet as every other data endpoint, so adding it does not mean a new key, a new invoice, or a new client library.
• Because Monid ships as an MCP server, the agent discovers and routes this call itself. You do not hand-code the tool call; the model picks it when the question calls for it.

Four principles behind agent-callable web search

We designed this around four ideas. Naming them makes it clear what a runtime web-search tool has to get right.

1. Runtime, not build-time

Most "give your agent the web" setups are actually build-time: a crawler runs on a schedule, an embedding job turns pages into vectors, and the agent retrieves from that frozen snapshot. That is a fine design for a corpus that does not move, like your own documentation. It is the wrong design for questions about this morning. The index is only ever as fresh as its last crawl, the crawl costs compute whether or not anyone asks about those pages, and a breaking story from an hour ago simply is not in there.

Runtime search inverts that. The agent decides, in the middle of reasoning, that it lacks a fact, and it fetches at that instant. Nothing is pre-indexed, nothing goes stale, and you pay for the search you actually needed rather than a standing crawl of pages nobody queried. The tradeoff is latency on the request itself, which is exactly the tradeoff you want when correctness depends on freshness.

2. Results plus contents in one call

The reason web search is usually two vendors is that retrieval and reading are usually two jobs. A search API hands back a ranked list of URLs. Then something has to open each URL, strip the navigation and ads, and return clean body text a model can hold in its context. Teams bolt a scraping or extraction service onto the search API to do that second half, and inherit two failure modes, two rate limits, and a pile of glue.

Exa's /search folds both halves into one request. Set the contents field and the response carries, per result, the cleaned text (with an optional maxCharacters cap), highlights (the sentences most relevant to a sub-query), and a per-source summary. The agent never sees raw HTML and never calls a second service. One request, one charged unit, results and readable contents arriving together.

3. One wallet across every data endpoint

An agent rarely needs only search. The same session might enrich a company, pull a few social posts, or generate an image. If each of those is a separate vendor, you are managing a drawer of API keys, reconciling a stack of invoices, and teaching your agent a different client for each. We think that is the actual tax on building capable agents, and it is the tax Monid removes.

Web search sits in the same catalog as company enrichment, LinkedIn scraping, and the rest, priced the same pay-as-you-go way and drawn from the same wallet. Adding live search to an agent that already talks to Monid is not a new integration. It is one more endpoint the agent can already reach. Current per-endpoint pricing is at monid.ai/tools, and because inspecting an endpoint is free, the agent can read the price before it ever spends.

4. MCP-native, so the agent routes it itself

Because Monid ships as an MCP server, the agent does not get a hardcoded search() tool you wrote. It gets the whole catalog as callable capability and picks the right endpoint for the question in front of it. When it hits something outside its training window, it can discover the search endpoint, inspect the schema, and make the call on its own, all inside its normal loop. Discover and inspect are free; only the run bills. That is the one sentence of mechanism worth stating, because it is what turns "web search" from a tool you plumb into a decision the model makes.

Set up once

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More details in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add --label main --key <your-api-key>

More details in the CLI quickstart.

The one call, end to end

Here is the whole runtime step. Pass the agent's question as query, keep numResults small because a few strong sources beat a wall of text, bound the window with startPublishedDate for anything time-sensitive, and set contents so the response arrives already readable.

monid run -p exa -e /search \
  -i '{"query": "latest EU AI Act enforcement guidance",
       "type": "neural",
       "category": "news",
       "numResults": 5,
       "startPublishedDate": "2026-07-01T00:00:00Z",
       "contents": {"text": {"maxCharacters": 1200},
                    "highlights": {"query": "enforcement changes", "numSentences": 2}}}' \
  -w
# -> five recent sources, each with up to 1200 chars of clean body text
#    and the two most relevant sentences, plus a costDollars breakdown

The -w flag waits inline so the agent gets everything in one shot. The fields that shape a good research step are type (from instant and fast up through neural, deep, and deep-reasoning), category (narrow to news, research paper, company, financial report, and more), the date bounds, and includeDomains or excludeDomains to trust or drop sources. There is also outputSchema, which asks Exa to synthesize one structured JSON object across every source it read, so your code gets a filled-in answer instead of a pile of pages. Every one of these is visible from a free monid inspect -p exa -e /search before you spend a cent.

What live search actually costs

Because /search bills per call rather than per token or per page, the cost of one research step is a flat unit you know before you run it. Asking for five results or fifty is still one charged call, and setting contents does not add a second charge because there is no second service. An agent that fires a handful of search calls per session sits in fractions of a cent to a few cents per session, and a tool running those all day lands in single-digit dollars. Compare that to a standing crawl-and-embed pipeline, where you pay compute continuously to keep an index warm whether or not anyone queries it. Reach for a deep search mode when a question is genuinely hard, keep it lean when it is not, and the bill tracks the work. Live prices are at monid.ai/tools.

FAQ

Why not just build a vector index of the web? An index answers from whenever it was last crawled, which is the wrong tense for questions about now. Runtime search fetches at the moment the agent asks, so freshness is guaranteed and you never pay to keep pages warm that nobody queries.

How does one call do both search and extraction? Exa's /search takes a contents object alongside the query. Set it and each result comes back with the cleaned page text, highlights, or a summary, so retrieval and reading happen in the same request instead of across two vendors.

Do I need a separate Exa key and a scraper? No. You integrate Monid once and fund one pay-as-you-go wallet, and that wallet reaches Exa's search-and-extract endpoint alongside every other data endpoint in the catalog. No second key for parsing, no second invoice.

Can the agent decide to call this on its own? Yes. Monid ships as an MCP server, so an agent that hits a question it cannot answer from memory can discover the endpoint, inspect the schema for free, and make the call itself. See monid.ai/SKILL.md.

Try it

Point your agent at Monid, hand it a question you know the answer to, and let it call exa /search with contents set. If the extracted text matches what you would find opening the pages yourself, wrap it as the agent's live-search step and let the model reach for it whenever its training runs out. Start at monid.ai.