Are MCP servers a visibility channel?

The short answer: nobody knows

No published study, ours included, has measured whether publishing an MCP server is associated with a business being referenced more often by AI agents. Not weak evidence — none, in either direction. The rest of this page is about why the question is still worth stating carefully, and what would settle it.

The hypothesis, stated so it can be wrong

Hypothesis Publishing a public MCP server that exposes a business's structured data changes how often that business is referenced, recommended, or cited by AI agents that support MCP, relative to a matched business without one.

Stated that way it is a measurement question, not a strategy question, which is why it belongs to the programme described in the AI visibility measurement standard rather than to a tactics list. Until it is answered it stays where the tactic evidence scoreboard puts everything of this kind: plausible, untested, and not to be sold as a tactic.

What observation would confirm or refute it?

A hypothesis that nothing could disprove is not worth publishing. Here is what we would accept as an answer, in each direction, before any data is collected.

Four things would make any such result hard to read, and they need stating in advance rather than after. Selection: businesses that publish a server early already have engineering capacity and an appetite for new channels. Configuration effects: if servers reach agents mostly through manual setup, the measurement captures relationships, not protocol effects. Data quality: a business with a server probably has cleaner data generally, which plausibly helps on the ordinary web too — the same confound the content freshness study has to control for. Small populations: any comparison run today would have very few participants, with all the instability that implies.

What would not count: one business, one quarter, one improvement. Nor a server you configured into your own agent, which proves the server works rather than that it is discoverable. Nor server logs read as user demand, since automated probing and indexing traffic look like interest and are nothing of the kind. Any commitment to run this also carries a commitment to publish a flat result in the null results registry, on the terms set out in the citation dataset strategy.

What MCP actually is

The Model Context Protocol defines a standard way for an AI application to connect to external tools, data sources and services. Rather than parsing a rendered HTML page, an agent can query an MCP server that exposes a business's catalog, documentation, pricing or availability through a structured interface.

A server exposes some combination of three primitives. Tools are callable functions like "search inventory" or "check availability". Resources are structured or unstructured data an agent can read. Prompts are reusable templates guiding how an agent uses the server. Which of these to expose is the publisher's choice; no convention for a good business-facing server has settled yet.

The baseline to beat is that an assistant can already fetch and read the open web, as Anthropic's web-search tool documentation describes. A server is a claim that a structured interface beats that baseline for your specific data.

The four-step chain the claim depends on

Step one is unsolved: there is no general index of business servers to browse, so today a human usually configures the connection. Steps two and three are ordinary engineering and model-behaviour questions. Step four is the one most often skipped in discussion of this idea.

Open question If the agent uses your data but names no source, you gained accuracy for the user and no visibility for yourself. That is the same accounting problem behind AI referral traffic and zero-click search, and the crawl-side version of the imbalance is measured in crawl-to-referral ratios for AI bots. Whether tool-sourced information gets attributed at all is undocumented.

Discovery has three candidate answers and no winner. A directory, which raises the usual questions about who runs the list and what stops it becoming paid placement. A well-known location on your own domain, borrowing the pattern behind robots files, sitemaps and documented crawler behaviour — the option with the strongest precedent, and the only one that would make timing measurable the way the crawl-to-citation latency study measures it for pages. Or platform curation, where the agent's operator maintains an approved set. That last is closest to what exists today and the least open of the three.

How does MCP compare with the other agent surfaces?

The pattern is a trade between reach and reliability. The web page reaches everything and is read badly; the server is read cleanly and reaches almost nobody by default. That trade is the whole argument. If discovery improves, the balance shifts. If it does not, a server stays a private integration rather than a public channel — and the asymmetry today is enormous, as which domains actually get cited shows.

Reaching for search habits here also leads to wrong moves. There is no ranking — a tool is called or it is not. There is no keyword; an agent selects a tool by its described purpose. Volume is not the goal, and bad data has an immediate real-world cost rather than a ranking one. The closest useful analogy is publishing an API, not publishing a site, which makes this a different activity from AI SEO entirely.

What do the precedents say?

The first-mover argument borrows from history, so it is worth naming a case where it worked and one where it did not. Structured product feeds became genuinely important, and businesses that maintained clean ones early were well placed when the surfaces consuming them grew — a cheap bet, because the feed was useful for other purposes meanwhile. Several older machine-readable formats went the other way: specified, adopted by enthusiasts, quietly ignored by the systems they were meant to inform.

The live analogue is llms.txt. Adoption grew quickly. And the overwhelming majority of published files receive no AI requests at all — consistent with Ahrefs' own study, with Google calling it speculative, and with our own null result in does llms.txt work. It is the closest available analogue to the bet this page describes, and so far it has not paid. The counter-example is IndexNow, which had a published getting-started path and a consuming system that actually wanted it.

Hypothesis The difference is instructive, and it is the test we would apply here. Formats that survived were useful to their publisher independently of any discovery benefit. Ones that failed were adopted purely on the promise of future visibility.

Six questions that settle it for your business

Before writing any code, answer these honestly. They take an hour and usually settle the matter.

1. Do you have data an agent would want? Live availability, prices, stock, structured specifications. Marketing copy does not qualify.
2. Is that data already correct in a system? If it is scattered or stale, fix that first. A server over bad data spreads bad data faster.
3. Do you already run an API? If yes, the marginal cost is small. If no, this is a real project.
4. Would you be comfortable if a competitor queried it hourly? Assume they will.
5. Who owns it in six months? An unmaintained interface is worse than none, because it fails silently and confidently.
6. Would you still do it if visibility were zero? If your own customers or partners would use it, the answer may be yes — and that is the only justification currently supported by evidence.

Reporting this to a stakeholder is simpler than it looks. Be direct that there is no evidence. Frame the decision on whether the interface serves your own customers. Offer a checkpoint in two quarters rather than a forecast. A speculative bet is a legitimate thing to choose, provided everyone knows that is what it is.

What does it cost, and what could go wrong?

Two of those deserve expanding. Accuracy liability is different in kind from a web page's: structured answers are taken literally, so a wrong price returned to an agent about to act is worse than a wrong price a human reads. And action risk — exposing anything that changes state, a booking or an order — raises authorisation and reversal questions that read-only data simply does not. Start read-only.

What would a good server look like?

No conventions have settled. What follows is reasoning rather than evidence, borrowed deliberately from ordinary API design.

• Few tools, clearly named. A short list is easier for a model to choose between.
• Descriptions that state limits. An agent that knows a boundary can decline instead of producing a wrong answer.
• Timestamps on everything. One last-verified field lets a consumer decide how much to trust the rest.
• Errors that explain. A generic failure invites a guess, and a guess reaches a user as a fact.
• Stable shapes. Renaming a field silently breaks every consumer at once.
• An obvious owner, with a contact point in the documentation.

What would change this page

Three developments would move this from speculation to something measurable. A published discovery mechanism, letting agents find servers without manual configuration. Any operator documenting that its consumer product queries third-party servers, and how it selects them. And evidence on whether tool-sourced information is attributed to its source at all.

Limitations

• This entire page is hypothesis, not finding — labelled as such throughout rather than presented with false confidence.
• MCP adoption among consumer-facing AI agents is still early — any effect measured today may not generalise once adoption matures.
• No first-party data underlies this page. Unlike the pre-registered work on the studies index, it is a protocol sketch and a reading of precedent.

Two ways on from here. If you want the evidence-grading habit this page applies, rather than more speculation, the GEO tactic evidence scoreboard grades every commonly recommended tactic. If you want to be told when the discovery or attribution questions above are actually answered, the newsletter is where dated updates to this page get sent.