What AI agents need from product data: fresh, structured, token-efficient and accurate
By Scott Macpherson, Founder, Bancadia
Published 6 min read
AI agents need four things from product data: it has to be fresh, highly structured and queryable, cheap to look up in tokens, and accurate enough that the model never has to guess. Web pages fail on all four. In one test I ran, the raw HTML of five product sites cost about 78 times more tokens than a single MCP query returning the same five products, and still left out facts the query returned.
Why does freshness matter so much for AI product recommendations?
Because the user acts on the answer. Rates move, fees get added, waiver thresholds change, promotions expire. A person reading an old blog post at least sees the date at the top. An agent working from a months-old crawl states the old fee as fact, and its user opens an account expecting terms that no longer exist.
Freshness has two parts. The data has to be current, and the agent has to be able to tell that it's current. A value without a timestamp forces the agent to either trust it blindly or hedge everything. Every listing Bancadia returns carries a last_modified timestamp and an is_verified flag, so the agent can say "as of this date" when it quotes a fee. How we track and flag staleness is on our methodology page.
What does "structured and queryable" mean for product data?
It means every attribute that decides fit is a typed field: the monthly fee is a number, accepted entity types are a fixed list of values, cash deposit support is true or false. And it means an agent can query on those fields, asking for "accounts that accept S corps in California and Nevada, pay interest and support sub-accounts", and get back only what matches.
Structure is what lets an agent use what it knows about its user. An agent with deep context turns that context into filters, and filters need fields. I go through the full set of dimensions for business checking, and which ones Bancadia supports today, in your product data has to keep up.
Prose can't do this. "Low fees for growing businesses" isn't a value. "No monthly fee with a $1,500 average balance" is closer, but an agent still has to parse it, and parsing is where errors creep in.
How many tokens does an agent waste reading product pages?
A lot. A token is the unit language models read and are billed in, roughly a short word or part of one. Every token an agent spends reading markup, navigation, scripts and marketing copy costs money and adds latency, and at agent scale that adds up across every user and every question.
I measured it. On October 1, 2026, I ran one real query against Bancadia's MCP server for the hypothetical Texas landscaping LLC from the agent is the lead: query_business_checking with entity_types_accepted: ["llc"], available_states: ["TX"], cash_deposit_available: true, accounting_integration_available: true and monthly_fee_max: 15. It returned five accounts. I then fetched the website each of those five listings links to (for these online-first institutions, the homepage is the main product page) and counted tokens for all three versions with the same tokenizer.
| What the agent reads | Tokens for all five accounts | Compared with the MCP response |
|---|---|---|
| Raw HTML of the five product pages | 305,168 (27,787 to 75,354 per page) | About 78 times larger |
| Visible text only (scripts, styles and tags stripped) | 13,627 | About 3.5 times larger |
One query_business_checking response | 3,916 | Baseline |
Method: pages were fetched with a standard desktop browser user agent; "visible text" removes script, style, noscript, svg and template elements, comments and tags, and collapses whitespace; the MCP figure is the full JSON text of the tool result. All counts use Google's Gemini countTokens API with the gemini-2.5-flash model. Other tokenizers will give different absolute numbers, but the ratios are what matter. This is one query on one day, not a benchmark.
The smaller numbers flatter the pages. Even after stripping everything but the visible text, the pages still didn't answer the question. All five accounts passed the cash_deposit_available filter, but the phrase "cash deposit" appeared on only one of the five pages. The MCP response, in under a third of the tokens, stated the monthly fee, cash deposit support, the outgoing domestic wire fee and a last_modified timestamp for all five, as typed values the agent could compare directly.
And this is the best case for scraping: the agent already knew which five sites to read. Without a query, it would have to find the candidates first, which means more pages and more tokens.
How does structured product data reduce AI hallucinations?
By taking away the need to guess. When a model has to infer a fee from a marketing page, it fills gaps with whatever seems plausible. That's what a hallucination is in this setting: a confident statement the source never made.
Interest rates are a good example. A product page that says "earn up to 2% APY" invites the agent to quote 2%. But the top rate often needs a paid plan or a minimum balance, and the default rate can be much lower or zero. Bancadia's data separates the two: apy_max is the best rate the account can pay, apy_default is what a customer gets by default, and plan_tiers shows what each plan costs and earns. An agent reading those fields doesn't have to guess which number applies to its user.
Structured data can also say "I don't know" honestly. In Bancadia's responses, a null field means we don't have that data point yet, not that the feature is absent. A page that doesn't mention cash deposit fees just leaves a gap, and a model will often fill it.
For financial products, accuracy isn't a nice-to-have. A wrong fee or rate becomes a real decision by a real business, and the agent that recommended it loses that user's trust.
What should financial institutions take from this?
Agents will recommend from whatever data they can get. If the only source for your product is your marketing page, they'll get an expensive, partial and possibly outdated version of it, and that version is what they'll tell their users. If your product is available as fresh, structured, accurate data an agent can query cheaply, that's what gets recommended instead.
That's the gap Bancadia fills for business checking: one MCP server that agents query, returning typed, timestamped fields for every listed account. For agent builders, our integration guides show the exact calls.
Frequently asked questions
What do AI agents need from product data?
Four things: freshness, structured and queryable fields, token-efficient lookups, and accuracy. Without them an agent quotes stale terms, can't filter, spends heavily on tokens, and guesses.
How many more tokens does scraping a product page cost than an MCP query?
In one test on October 1, 2026, the raw HTML of five business checking product pages was 305,168 tokens, versus 3,916 for one MCP query covering the same five accounts: about 78 times more.
How does Bancadia show data freshness?
Every listing returned over MCP carries a last_modified timestamp and an is_verified flag, so an agent can tell its user how current a fee or rate is.
Why do AI agents hallucinate fees and rates?
Usually because the source doesn't state the value clearly, so the model infers one. Structured fields with explicit values, and explicit nulls when a value is unknown, remove the need to infer.
Work with us
For banks, credit unions and fintechs: Want your products queryable by AI agents? We're onboarding early partners. Email Scott at [email protected].
For agent builders: connect your agent to Bancadia's MCP server. Start with the agent integration guides.