My agent needs live prices, not training data. Give it a tool call.

My agent needs live prices, not training data

The short answer. Stop asking the model what the price is and start letting it fetch the price. Connect it to a live data tool over MCP, have it call that tool whenever a number matters, and keep the receipt of the call. On Zambo that is live_price on the endpoint at https://zambo.dev/mcp: ask for a symbol, get the current figure from a live feed, and get a verifiable receipt binding the exact returned text to the second it was returned. The model then reasons over a fact instead of performing one.

Why training data cannot do this job. A model's knowledge ends at its training cutoff, and prices do not care. The BTC figure in a model's weights is from whenever its data was gathered, quoted with the same confidence at $60,000 as at $82,295. Worse, the failure is invisible from the answer alone: a remembered price, a blended average of old prices, and a pure invention all read identically. Prompting harder does not fix it, because the missing thing is not effort. It is a channel to the present, and a channel is a tool, not a prompt.

Scope, stated once and applied everywhere on this page: a verifiable receipt proves the saved result was not changed since it was saved. It does not prove the price was the correct market price, and it does not vouch for the feed. It proves the record: the figure in the receipt is the figure the tool returned, at the time stamped on the receipt, unaltered since.

The ways to give an agent live data

• Direct API function calls. Wire the agent to one data provider's API as a function. Works, and every new kind of data is a new integration with its own key, errors, and no shared record of what came back.
• An MCP server with data tools. One connection, a catalog of tools behind it, the same calling shape for prices as for everything else. On Zambo the endpoint carries live_price inside a 153 tool catalog, so the agent that fetches a price can also audit a site, extract a document, or check a receipt without a second integration.
• Retrieval over documents. The right tool for text the agent should read: filings, docs, your own corpus. The wrong tool for a ticking number, because an index is only as fresh as its last crawl and carries no per-answer record.
• Asking the model to browse or remember. Browsing helps when the agent can reach a readable page, and fails silently when it cannot. Remembering is not a data source at all; it is the failure this page exists to replace.

Whichever route you pick, judge it on three properties: the number is fetched at decision time, the source is a live feed rather than a snapshot, and the call leaves a record. Most setups manage the first two on a good day. The third is the one that decides whether you can ever audit the decision, and it is the one built into every Zambo call by default.

The receipt is the record of which price the agent saw

The live number matters in the moment. The record matters later, when the decision built on that number gets questioned: a trade reviewed by a partner, a quote sent to a client, a report a reader disputes. In that moment the question is never really "what is BTC worth?" It is "what did your agent see, and when, and can you show me it has not been edited since?" A chat transcript cannot answer it, because transcripts are text the agent itself produces. A receipt answers it in one recompute: recorded inputs (symbol: ETH), saved output (the price text exactly as returned), timestamp (23:05:31 UTC), output digest committed at call time. If the digest recomputes through the public verifier, the figure in front of the reviewer is the figure the agent acted on. That is the audit value, and it costs nothing extra: the receipt is minted by the call itself, not written up afterward by anyone.

The same pattern runs under whole jobs, not just single prices: a run of calls closes under one root, covered in Did my AI agent really complete the task?, and the single-call version is covered in Did my AI agent actually run it?

Live prices for your agent, step by step

1. Connect the endpoint. Add https://zambo.dev/mcp to your AI, once. In Claude, ChatGPT, Gemini, Cursor, or Grok, it is a connector add; the catalog comes with it.
2. Ask for the number as a call, not a question. The agent calls live_price with the symbol. The tool fetches the current figure from a live feed and returns it with its timestamp.
3. Keep the receipt id. It rides along with every result (the run link is the receipt). File it with whatever the number fed: the trade note, the report, the client quote.
4. Verify whenever it matters. Open the receipt at the public verifier or recompute the output digest yourself. No account, no cooperation from the agent, no trust in the transcript.

live_price is on the free tier, so the pattern costs nothing to test end to end. When an agent needs the wider catalog unlocked around the clock, it can pay its own way: the x402 page shows how an agent buys the $0.99 Day Pass itself with USDC on Base, and how a human pays the same pass by card through PayPal instead.

The format underneath: AER-1

The receipts used in every section above follow one open format: AER-1, IETF Internet-Draft revision 23 (draft-zambo-aer1-23). AER-1 is an IETF Internet-Draft, not a finalized standard. It defines the per-step verifiable receipt and the workflow record that links receipts for a run, so a receipt produced in one place can be checked by a receiver somewhere else, with no account on the system that produced it and no cooperation from the operator who ran the agent.

To put live data and receipts under your own agent: start with the live demo for a single checked call, then a Zambo Day Pass for a day of calls with a verifiable receipt under each one.

Questions, answered