Blog · Machine readability

Your API and MCP server as a visibility surface

Published 10 August 2026 · Updated 12 October 2026 · 8 min read

Your API and MCP server as a visibility surface
Photograph: Kirill Sh / unsplash

The short answer: Your public API, its documentation and any MCP server you ship are now places an assistant can read your brand directly, with no crawl, no ranking and no click in between. Treat them as published content rather than plumbing. Tool names, the wording of each description, and the metadata in your registry entry are what a model has to go on when it decides whether to reach for you, and they shape whether the sentence it then writes about you is true.

Many teams still file this under engineering. The marketing site gets a schema audit and a tone of voice document. The API reference gets whatever the code generator produced in

  1. Where a connector exists, both of those are being read on a buyer's behalf, and

    2. only one of them has an editor.

Two doors, and only one of them is guarded

Where a host application supports connected tools, an engine can reach a brand two ways. The first is retrieval: it fetches pages, cuts them into passages, keeps a few, writes an answer. That path is the subject of Structured data for AI search: what to mark up first, and it is the one almost everyone is working on.

The second door is a tool call. Where a host application has your server connected, the model can call a function instead of guessing what your pricing is. When it does, the answer is sourced from you, dated by you, and phrased from fields you control. That is a better position than hoping a passage survives a chunker, and it is why MCP servers for brands: a practical look is worth reading next to this one.

The catch is that the second door rarely sits inside any editorial process. Tool descriptions are copy, and copy nobody on the content team has read is copy nobody has edited. Ask who in your own company owns those strings. We cannot tell you what the answer is in companies we have not audited.

What a model actually reads before it calls you

A host lists the tools your server offers, and the model sees a small record for each: the name, a title, a description, an input schema and an output schema, plus behavioural annotations such as readOnlyHint, destructiveHint, idempotentHint and openWorldHint. In ChatGPT specifically, OpenAI's plugin reference documents extra fields under _meta, including a UI template resource URI and the short status strings shown while a tool runs, capped at 64 characters each. Those _meta keys are OpenAI's, not the protocol's, so do not assume another host reads them.

Two details in that list matter more than they look.

The first is that annotations are hints about behaviour, not enforcement. The specification is explicit that a host decides what to do with them, and a host may show a read-only tool with less friction than one marked destructive. Mislabel a harmless lookup as destructive and you may have added a confirmation step between a buyer's question and your data, in whichever hosts choose to act on the hint.

The second is that the description is prompt text. It is concatenated into the model's context alongside every other connected server's descriptions, and the model picks on the strength of that wording. A description reading Gets data gives the model nothing to choose on, next to a neighbour whose description names the entity, the units and the freshness. We have not measured how often wording alone flips a call, and we know of no published figure for it, so treat this as an argument from how selection works rather than a measured effect.

The July 2026 revision of the protocol, dated 2026-07-28, went further and made the machinery itself discoverable. Servers must now implement a server/discover call that advertises supported protocol versions, capabilities and identity. Method and tool names travel in the Mcp-Method and Mcp-Name HTTP headers, so a gateway in front of you can route and authorise on headers alone. List results carry ttlMs and cacheScope. The spec also asks servers to return tools in a deterministic order, because a stable order improves prompt cache hit rates on the client side.

Read that last point again. Shuffle your tool list on every deploy and you forfeit a caching benefit the specification explicitly asks for. What that costs you in practice is not something we can see from outside a host, so we make no claim about it.

The failure modes nobody tests for

Four are easy to miss, and none of them appear in a normal uptime check.

Silent namespace drift. In the official MCP Registry, server names are reverse DNS, such as com.example/server, and the registry documents namespace authentication through a verified GitHub account or a domain challenge. Other marketplaces set their own rules. Publish under a contractor's namespace during a pilot and the canonical pointer to your brand belongs to somebody else. This is the same entity problem described in sameAs and the identity links engines check, moved into a package registry.

Stale aggregation. The official registry is a metadata index that points at npm, PyPI, Docker Hub and remote URLs. Its own documentation says it expects downstream aggregators to pull on a regular but infrequent basis, giving once per hour as the example. That is the registry's stated expectation, not a schedule we have measured in any marketplace. Your own fix may be live in a minute, while the directory a buyer's assistant reads is an hour or more behind, with a cached list result sitting on top of that.

Deprecated transport rot. In the 2026-07-28 revision, HTTP plus SSE is reclassified as deprecated in favour of Streamable HTTP, under a published feature lifecycle policy with a minimum twelve month deprecation window. Roots, Sampling and Logging were deprecated in the same revision, and the handshake, protocol sessions and the Mcp-Session-Id header were removed outright. A server built against a 2025 tutorial still runs, right up to the host release that drops the old path.

Documentation that contradicts the schema. When the reference page says a field is optional and the schema marks it required, the model gets one story from retrieval and a different one from the tool call. The answer it writes may hedge, and a hedge reads to a buyer as uncertainty about your product.

Treat it as a publishing surface, with checks

Run these in an afternoon.

  1. Print your own tools/list payload and read it as copy. Does each description name the

    2. entity, say what the data covers and say how fresh it is? Would a stranger pick the right tool from the names alone?

  2. Diff two consecutive deploys of that payload. If the order changes without the content

    3. changing, fix the ordering.

  3. Check who owns the namespace in every registry and marketplace that lists you, then

    4. check that the listed website is one you control and have verified. OpenAI's plugin submission guide, for the ChatGPT directory, asks for a display name of at most 30 characters, a subtitle of at most 30, a long description of up to 4,000, and a domain verification challenge served as plain text. Those limits are OpenAI's; other directories publish their own. Someone should own those strings who also owns the brand's words elsewhere.

  4. Grep your logs for the host user agents that reach the server, not just the page

    5. crawlers. The method is the same one in Reading your server logs for AI bot traffic, pointed at a different hostname.

  5. Ask three engines your top buyer question with your connector enabled and again with it

    6. off, and repeat the pair over several days. The gap between the two answers is the closest thing to a read on the surface's value. One pair of runs is an anecdote, not a measurement, because answers move between runs on the same prompt.

If you want to see how findings like these get written up with the evidence attached, the sample audit report shows the shape.

Honest limits

Adoption numbers for this surface are thin, and we have published none of our own here. A security vendor's analysis of the official registry, published on 20 December 2025, reported about 1,691 unique underlying npm and PyPI packages behind tens of millions of duplicated server entries, which says the supply side is real and duplicated, and says nothing at all about how often any server gets called. We know of no host that reports invocation counts back to the server operator, so what we can see is what an operator logs, and absence in those logs is not proof that nothing called you.

We have no clean way to attribute a tool call to revenue: in the server logs we have read, these calls arrive with no referrer and often no stable user identifier. Every claim above about wording, ordering and labelling is read off published specifications and vendor documentation, not off an experiment we ran, and none of it is scoped beyond the hosts whose documentation we cite. The before-and-after test in the checklist is a sample of answers on a handful of prompts, not a census of what engines say about you.

FAQ

Does publishing an MCP server help if nobody has connected it? Not directly. A server nobody has connected is not in the model's tool list, so it cannot be called. The second order effect is real though: the documentation, the registry entry and the verified domain are themselves indexed content, and they corroborate who you are.

Should the content team own the tool descriptions? Someone who writes for a living should review them. Engineering owns the schema and the behaviour. The wording is copy, and it competes against other servers' copy inside the same context window.

Is this worth doing before the basics are fixed? No. If pages cannot be fetched or your identity does not resolve, fix that first. This surface rewards companies whose data is already clean and whose buyers ask operational questions.

How often does the protocol change? Often enough to need a calendar entry. The revision dated 2026-07-28 follows one dated 2025-11-25, and it adopted a feature lifecycle policy giving at least twelve months before a deprecated feature is removed. Reading the changelog once a quarter is enough.

Sources

Related reading

Structured data for AI search: what to mark up firstsameAs and the identity links engines checkReading your server logs for AI bot trafficMCP servers for brands: a practical lookAuthor and publisher markup that survives scrutinyDuplicates, canonicals and confused AI answers