Product discovery is moving from web pages to APIs and MCP servers

What is changing about how people find products?

Software systems have talked to each other through APIs for years. What's new is that software now does the shopping. AI assistants research purchases, compare options and, more and more, take actions for the person they work for. Answer engines return one synthesized answer instead of ten blue links.

The plumbing for this arrived quickly. The Model Context Protocol (MCP) is an open standard for connecting AI models to external tools and data; Anthropic introduced it in November 2024 and the specification is public. A capability published once as an MCP server can be called by any agent that speaks the protocol.

I believe product discovery will follow. When a small-business owner asks their AI CFO where the business should bank, the answer won't come from a person scrolling a comparison site. It will come from an agent that calls a tool, weighs the results against what it knows about the business, and explains its choice.

Why doesn't SEO-era product content work for AI agents?

The discovery system we have was built for human eyeballs. Product information lives in HTML designed to persuade. Fee schedules live in PDFs. The comparison layer on top is mostly listicles, written once for an average reader and ranked by some mix of editorial judgment and payout.

Agents inherit all of that when they scrape. Scraped pages are fragile: a site redesign breaks the parser. They're stale: last quarter's crawl quotes last quarter's rate. And they're unverifiable: the agent can't tell the standard rate from the promotional one, or whether a fee it found applies to the plan its user would actually get. Then the model states the result with full confidence.

For most products that's an annoyance. For financial products, where a wrong fee or rate costs the end user real money, it isn't good enough.

What do AI agents need from product data instead?

Four things, which I go through in detail in what AI agents need from product data:

• Freshness. Data that's current when the agent asks, with a timestamp so the agent can tell.
• Structure the agent can query. Typed fields for fees, rates and eligibility that an agent can filter on, not prose to interpret.
• Token efficiency. A lookup that returns the fields the agent needs and nothing else, rather than tens of thousands of tokens of page markup.
• Accuracy. Authoritative values, so the model isn't guessing a fee from marketing copy.

Underneath all four is one idea: every business is a different combination of entity type, state, balances, cash habits and software. An agent should be able to express that whole combination as a query and get back only the products that fit. I make that case in why agents need filterable product data.

What is Bancadia building?

Bancadia is a queryable data layer for financial products, delivered as an MCP server. The MCP server is the only way in; there is no public REST API. An agent calls query_business_checking with what it knows about its user (entity type, state, fee ceiling, required features such as cash deposits or an accounting integration) and gets back structured listings with fees, rates, eligibility and an application link. A second tool, get_business_checking_listing, returns the full fee schedule and feature detail for one listing.

The agent keeps the relationship with its user and decides when a recommendation is useful. Bancadia handles the product data and, as bank and affiliate partners come online, the commission. When a recommendation converts, Bancadia is designed to earn an affiliate commission and share it with the agent that made the recommendation.

Where things stand today: the data is free to use, it's compiled from institutions' own published materials, and coverage is early. There are no live bank partnerships and no commissions being paid yet. How listings get in and how results are ordered is on our methodology page.

Why pay agents for conversions instead of selling ads?

By the time an agent recommends a business checking account, it already knows the business, has narrowed the options and is ready to help its user apply. That isn't an impression. It's something very close to a qualified lead, and qualified leads have always been paid for on conversion, the way affiliates are paid.

My bet is that, as more discovery runs through agents, conversion-based pay takes share from impression-based pay. I lay out the full argument in In AI search, the agent is the lead.

Why start with business checking?

We're starting with business checking, for agents that serve small businesses: AI CFOs, bookkeeping and accounting agents, treasury tools, entity-formation platforms and SMB software. Those agents already hold the facts that decide which account fits, such as entity type, state, transaction volume and how much cash the business handles. And opening a business account is a high-intent moment with a clear best answer for each business.

From there we'll add more business financial products, following what integrating agents ask for. Longer term, I think the same pattern (structured product data plus conversion-based attribution) applies to agentic commerce broadly. That's a direction, not current scope.

Frequently asked questions