Publishing an MCP Server as a Discovery Channel: What It Actually Wins You

TL;DR

• Publishing an MCP server does not open a discovery channel. The Model Context Protocol specification (version 2025-11-25) defines the wire protocol and says nothing about discovery, so a published server is connectable, not findable.

• The phrase “discovery channel” collapses four separate jobs — awareness, selection, connection, and retrieval-and-reuse. Publishing a server does only the last two. Awareness and selection happen elsewhere, at the earned layer.

• Where agents actually find servers — public registries, direct installs, and vetted directories — publishing is the price of admission, not the deciding factor. Among the roughly 20,000 catalogued servers, selection is a trust-and-curation problem, and trust is earned.

• The real, under-claimed payoff is reuse: a first-party server gives an agent structured, persistent access, so it returns. That makes an MCP server a retention asset — build it, but measure it as depth, not discovery.

The claim worth dismantling: “publish a server, open a channel”

What is an MCP server?

An MCP server is a small adapter that exposes one product’s data or tools to an AI agent over a shared standard, so any compatible client — Claude, ChatGPT, Cursor — can query it the same way. It is the machine-readable front door to your service; it is not, on its own, a listing in a directory that anyone will read.

The pitch has spread through marketing decks since early 2026, and it is tidy. MCP (Model Context Protocol, the open standard that lets an AI agent connect to and query an external tool or dataset) is the new integration layer for agents. Publish a server, the argument runs, and you have opened a fresh discovery surface — a place where agents will find you, the way pages were once found in an index. The reasoning is seductive precisely because the word discovery is doing the persuading. Registries are described as “discovery layers.” Vendors write about “AI tool discovery.” Drop a server into that vocabulary and it starts to sound like a channel you get discovered through.

It is worth stating plainly what the protocol actually specifies, because that is where the claim quietly breaks. The MCP specification, at version 2025-11-25, defines the wire protocol — how a client and a server talk once they are already connected — and says nothing about discovery. A server that speaks flawless JSON-RPC (the request-and-response format MCP messages ride on) still has no built-in way for a stranger to find it. Discovery was left to a separate layer that the protocol neither governs nor guarantees you a place in.

Connectable is not the same as findable

That gap — between connectable and findable — is the whole article. A community developer can wrap a public API in an MCP server this afternoon, and technically that server is as connectable as any FTSE 100 company’s. It joins the roughly twenty thousand servers that one registry alone, Glama, had indexed by 2026 — most of them, by that registry’s own account, thin wrappers. Being connectable puts you in the phone book. It does not make the phone ring. The parallel to the earned links and mentions that make any page findable is exact: publishing a page has never been the same as being discovered through it. The index will hold anything, and holding is not ranking.

Why argue about a noun? Because the noun routes the money. A team that books an MCP server as an acquisition channel sets acquisition expectations — inbound pipeline, a cost per new agent reached — then staffs and budgets to hit them. When the inbound never comes, the reasonable-looking conclusion is that the channel underperformed, and the server is cut at the next review. The asset was fine; the category was wrong. The reverse error is quieter and just as expensive: a business that could own a real retention moat never builds the server at all, because “discovery” was not a priority this year. Getting the noun right — retention, not discovery — is what puts the budget where the return actually is.

The MCP Misfiling Map

Is publishing an MCP server a discovery channel?

No. It is a connection-and-reuse asset that has been mislabelled as an awareness-and-selection one. Publishing a server makes an agent able to query you once it has already found and chosen you; the finding and the choosing happen at a different layer entirely.

The confusion is a filing error. “Discovery channel” is not one job; it is four, bundled under a single word — and a published MCP server does only two of them. The map below pulls them apart and scores each.

The MCP Misfiling Map

Read down the second column and the shape is stark. Publishing a server returns a “Yes” on exactly the two rows the word discovery is not about — connection and reuse — and a “No” on the two rows it is about — awareness and selection. An MCP server is a connection-and-reuse asset wearing an awareness-and-selection label. The two “Yes” rows are genuine value; they are simply not discovery. Connection is plumbing — necessary, commoditised, identical for everyone who can host an endpoint. Reuse is the real prize, and we will come back to why it is worth more than the discovery you were promised. Confuse the two and you will pour budget into the plumbing while treating the reuse as a rounding error — which is the exact misallocation the map exists to catch.

Key takeaway

The label is the error, not the technology. Sort any “AI discovery surface” into these four jobs before you fund it. If it only earns a “Yes” on connection and retrieval, you are buying fulfilment infrastructure — price it and staff it as such, not as a source of new demand.

Where agent discovery actually happens: three doors

Where do agents actually find MCP servers?

Through three doors — public registries, direct installs by a human who already knows you, and curated directories the platform has vetted. Publishing a server is the price of admission to all three and the deciding factor in none.

If discovery does not happen through the protocol, then where? An agent reaches your server through one of three doors, and it is worth walking each, because none of them is opened by the act of publishing.

Door one — the registry

The most-cited “discovery layer” is the registry. The official MCP Registry, in preview since September 2025, listed close to two thousand servers by 2026; community catalogues went far wider — Glama alone indexed around twenty thousand — and sub-registries such as QVeris layered capability routing over ten thousand-plus tools. These are real, and you should be in them: as one directory put it, a server that sits in no registry is invisible to a meaningful slice of the agent market. But a registry is a phone book, not the businesses in it. An agent does not connect to a registry to get work done; it queries the registry to find the one server it actually needs, then connects to that. For example, a regional coffee-equipment retailer that wraps its public product API in a server has done nothing wrong — but it now sits beside nineteen thousand-odd other wrappers, listed and unreached, in the phone book and never called. Being listed is necessary, and it is table stakes — the same status being indexed has always had for a web page. It clears a floor. It does not win the choice.

Door two — the direct install

The second door is the one the “discovery channel” story quietly ignores. A person who already knows your product pastes your server’s URL into Claude’s custom-connector dialog, or enables it in ChatGPT’s developer mode (in beta to paid tiers since 9 September 2025), and authorises it over OAuth. Notice what has happened: the discovery occurred entirely off the MCP surface. The human sought you out because they already trusted the brand; the server is merely what they connect once the decision is made. For example, a developer who already relies on your product adds your server so their agent can reach it — no new demand was created; an existing relationship was deepened. This is the most common path, and it is not acquisition at all. It is fulfilment.

Door three — the vetted directory

The third door is the curated set inside a platform. OpenAI’s apps directory offers one-click, permission-scoped installs of MCP-backed integrations it has vetted — Notion, Linear, Salesforce Agentforce among them; Claude’s connectors directory marks some entries as verified by Anthropic and leaves the rest as community connectors. Here selection is explicit, and it is a trust decision made by the platform, not a keyword you can target. That vetted slot is worth more than a raw listing for the same reason a genuinely earned editorial placement outweighs a paid insertion: someone with a reputation to protect has vouched for you.

Three doors, one pattern. Publishing the server is the entry fee at each, and the decision — list-rank, prior trust, or platform vetting — is made by something other than the server itself. In the layered view of the agentic web — access, then discovery, then selection, then transaction — selection is the one layer with no protocol of its own. It is also the layer that decides who gets chosen.

Selection is a trust problem, and trust is earned

Once you accept that discovery lives at the registry-and-directory layer, the next question is what wins there — and the answer folds the whole thing back into the earned layer.

The defining fact of the 2026 server ecosystem is abundance, not scarcity. With tens of thousands of servers catalogued and most of them wrappers, the hard problem stopped being finding a server and became knowing which are real, maintained, and safe to hand credentials to — a curation problem, not a count problem. The practical checks that separate a server worth depending on from the thousands that are not are all trust checks: is it first-party, documented on the vendor’s own site, actively maintained, and safe with your data? A first-party server from a vendor you already trust carries roughly the underlying API’s own risk; an unvetted community wrapper is a credential you may come to regret handing over.

The platforms hard-code trust as the gate

This is not a soft preference; the clients enforce it. Anthropic’s guidance is blunt — only connect to servers built by organisations you trust, and review the permissions each one requests. OpenAI flags developer-mode connections as elevated risk and warns explicitly about malicious servers. When a platform’s own advice is “prefer the first-party, the maintained, the vouched-for,” it has made earned trust the selection criterion. You cannot buy past that filter; you can only be the kind of source it lets through — which is also, not coincidentally, how a site recovers standing after losing a search engine’s trust: by becoming demonstrably trustworthy, not by paying to skip the check.

Semantic match gets you shortlisted, not chosen

There is a genuine optimisation surface here, and it is worth naming precisely so you do not overrate it. Google Cloud’s Agent Registry exposes a search_mcp_servers tool that finds servers by capability and description — ask it for “servers that offer BigQuery data tools” and a clear, accurate description is what surfaces you. That is real, and you should write those descriptions well. But semantic match only assembles a shortlist of the plausibly relevant; among that shortlist, the same trust signals decide the pick. Description gets you considered; corroboration gets you chosen. And corroboration is the earned layer in its most literal form: the evidence, elsewhere on the web, that you are who your server claims to be. Across Ahrefs’s 75,000-brand study, brand mentions correlated with AI visibility at 0.664 against 0.218 for raw backlinks; Muck Rack’s May 2026 analysis of more than 25 million citations found 84% were earned and 0.3% paid. The signals that make a model comfortable naming you are the signals that make an agent comfortable connecting to you — which is exactly why it pays to study the corroboration your rivals are accumulating, not just their tooling.

It is worth being precise about why this cannot be bought. Earned and paid citations are not substitutes that trade off against one another; they are different mechanisms, and the corroboration an agent trusts is, by construction, the one you did not pay for. A rival can outspend you on an ad slot beside the answer and still lose the connection, because the trust check the agent runs — first-party, maintained, independently vouched-for — reads a ledger money does not write. That is the durable fact under the whole selection layer: the tie-breaker is the one input with no purchase button, which is exactly why it survives when everything buyable has been bought.

Key takeaway

You do not optimise an MCP server into being chosen. You describe it clearly to clear the shortlist, then win the pick with the same earned trust — first-party proof, real maintenance, independent corroboration — that decides every other selection an agent makes.

The payoff you are underselling: reuse, not reach

Here is the turn. Dismantling the discovery claim is not an argument for skipping the server — it is an argument for building it for the job it is genuinely good at, which happens to be worth more than the one it was sold for.

An MCP server does one thing no other surface in your stack does: it gives an agent structured, persistent, first-party access to your data or tools, on demand. Not a page to parse and possibly misread — a queryable interface that returns clean, current, authoritative answers every time. And agents are built to exploit exactly that. Anthropic’s own engineering work on code execution with MCP showed an agent cutting its tool-loading cost from 150,000 tokens to 2,000 — a 98.7% reduction — by loading tools on demand rather than all at once. The consequence is decisive: agents do not browse the full catalogue on every task. They reach for the small set of servers they already know and trust for a capability, and they reach again.

This is a retention annuity, not an acquisition funnel

That “reach again” is the entire economic case. Once your first-party server is the trusted, connected source for a capability an agent needs repeatedly, you are not re-discovered each time — you are reused. For example, a compliance agent that must check a regulatory status every week does not re-shop the registry every week; it returns to the server that answered cleanly last time. The first successful connection then amortises across every later query at almost no marginal cost — the same shape as an earned asset that keeps paying, which is why durable practitioners invest in assets that compound rather than placements that expire. Discovery, if you had it, would be a one-off. Reuse compounds.

Put the two economies side by side. A discovery event, even a good one, is linear: one agent finds you once, and to grow you need the next finding, and the next. Reuse is closer to a subscription you never had to sell — the connected agent returns on its own schedule, and each return costs almost nothing to serve. For example, a pricing agent that re-checks a supplier’s live rates before every quote can generate dozens of queries a month from a single connection made once. Under a discovery frame that traffic is invisible, because no new agent was acquired; under a reuse frame it is the entire point.

Which businesses this is actually worth for

This reframes who should build a server, and why. If your data is static, thin, or already trivially read from a page, an MCP server adds little; the page was enough. The server earns its keep when your value sits in structured, changing, or gated data an agent needs to query repeatedly and correctly — pricing, live availability, regulatory status, account-specific answers. For those businesses the server becomes a retention moat: once an agent depends on it, a competitor must not merely be found but dislodge an incumbent that already works. That is a far stronger position than “discoverable,” and it is precisely the position the label talked you out of valuing.

The negative case is as useful as the positive. A local services business whose only agent-relevant data is a handful of prices and its opening hours should not build a server at all; a well-structured page carries that, and the server would be maintenance for no reuse. Reserve the build for data worth querying twice. The question is never whether you can stand up a server; it is whether an agent would have any reason to come back to it.

The Cold-Agent Test

How do I tell an acquisition channel from a fulfilment one?

Ask whether a stranger could arrive there unprompted. A true discovery channel brings you agents that have never heard of you; a fulfilment channel serves agents that were already routed to you elsewhere.

You will be pitched other “AI discovery surfaces” this year, and you need a faster test than building a whole map each time. Here is the diagnostic. For any channel, ask three questions.

The Cold-Agent Test

1. Could an agent that has never encountered your brand reach this surface on its own, unprompted?

2. Does arriving here require the agent to have already selected you from among the alternatives?

3. If you paused all earned media and brand-building, would arrivals here fall toward zero?

Scoring. A genuine discovery channel answers Yes, No, No. A fulfilment channel answers No, Yes, Yes.

Run a bare MCP server through it. Could a cold agent reach it unprompted? No — it must already be at a registry and must already know to want you. Does arriving require prior selection? Yes. Would arrivals collapse without earned activity? Yes. Three for three: fulfilment, not discovery. Now run a registry-listed server: the listing earns a marginal “Yes” on the first question — a cold agent could surface it by capability — but the second and third still hold, because being listed among twenty thousand is findable, not chosen. The listing moves you from invisible to eligible. It does not move you to selected.

The value of the test is that it discriminates. Point it at an llms.txt file — the machine-readable content map some sites now publish for models — and it scores No, Yes, Yes for the same reason a server does: a cold agent does not stumble onto your llms.txt without first being sent to your domain by something earned. Point it at a widely syndicated piece of original research and it flips to Yes, No, No — a stranger genuinely can meet you there for the first time. Same three questions, opposite verdicts, and each verdict is a budget instruction: fund the first as retention, the second as acquisition.

Key takeaway

The test tells you which budget line an item belongs on. Anything that answers No / Yes / Yes is retention — fund it for depth and measure reuse. Reserve acquisition budget for surfaces where a stranger genuinely lands, which for agents remains the earned layer.

A worked example: Thameside Compliance ships a server

Consider Thameside Compliance, a UK SaaS with about £8M in annual recurring revenue that sells current UK regulatory and company-status data to accountants and law firms. Its data is exactly the kind an agent needs to query repeatedly and get right, so a server genuinely makes sense. The board has a £120,000 “agent-readiness” budget for 2027 and one real decision: what the server is for.

The acquisition framing — the one to avoid — treats the server as a discovery channel and spends to match: roughly £70,000 to build an elaborate, many-tool server on bespoke hosting, £30,000 to “promote the channel,” and £20,000 of contingency, on the expectation that agents will find their way in. The reuse framing spends almost inversely: about £15,000 for a lean, well-documented first-party server, listed in the official registry and the main community catalogues with first-party verification and clear tool descriptions; £25,000 to make the underlying entity and data machine-resolvable, so a model can confirm Thameside is who the server says it is; £65,000 into the earned corroboration — trade coverage, practitioner citation, genuine references — that gets the server selected and cited in the first place; and £15,000 into measurement.

Thameside’s £120k, two ways

Look at the acquisition column on its own terms and it fails before any agent shows up. The £30,000 to “promote the channel” assumes there is demand to capture, but a server generates no demand — it answers requests some earlier, earned signal produced. The £70,000 elaborate build buys tools no one has been given a reason to reach for. The plan spends most heavily on the two jobs a server cannot do — create awareness and win selection — and least on the two it can. The reuse column is not merely cheaper; it is aimed at the jobs that exist.

The timeline separates them. In month one the acquisition build looks busier — more tools, a slicker server — while inbound “discovery” stays flat, because no cold agent arrives; the only connections are a handful of installs from firms that already knew Thameside, which is the direct-install door, retention wearing a discovery badge. By month three the reuse build is listed, verified, and beginning to earn the citations that make agents choose it from the registry for regulatory-status queries; the acquisition build is still waiting for demand it never generated. By month six the reuse server has become a reused default — accounting agents return to it weekly, queries compound at almost no marginal cost, and dislodging Thameside now means beating an incumbent that already works. The acquisition team concludes that “MCP doesn’t drive discovery.” They are right, for the wrong reason: they built a retention asset and judged it as an acquisition one.

Measure reuse, and turn it into a citable asset

Note the £15,000 measurement line, because it does double duty. The metric that matters is not installs; it is reuse — queries per connected agent, return rate, and which door referred each connection. And there is an earned-media dividend hiding in that data. An honest, first-party write-up of your own server’s query logs — how often agents return, what they ask, how reuse builds over months — is precisely the kind of original, named evidence this field is short of. Published, it becomes a citable asset that earns the very corroboration the server needs, built on the domain-specific data only you hold. Measure the server as retention; then publish the measurement as earned media.

The strongest objection: registries are discovery, and you can rank in them

The honest counter to all of this is not weak, and it deserves its strongest form. Registries are a discovery surface. Being listed is real. And there is a genuine, winnable discipline in doing it well — submitting to the official registry and the major catalogues, verifying first-party ownership, writing capability descriptions a semantic search can match, keeping the record maintained. A server in no registry is, as the directories say, invisible to part of the market. So publishing and listing a server plainly does add discovery. Isn’t “it’s not a discovery channel” too strong?

Take the concession fully: yes, list your server everywhere it belongs, and yes, do the description work — it has real return. To be concrete about the discipline being conceded: verify first-party ownership so your record outranks the community wrappers of your own API; write tool descriptions in the language of the task an agent is completing, not your internal feature names, so semantic search matches them; list in the official registry and the two or three catalogues your buyers’ clients actually query; and keep the record current, because a stale or broken server is dropped fast. That is real work, and skipping it is a genuine own-goal. But look at what kind of return it buys. First, registry presence is a threshold good. It moves you from invisible to eligible, and once everyone competent has listed, presence converges to table stakes — a disqualifier if you lack it, not a differentiator if you have it. It has a floor and a low ceiling, the economics of any baseline everyone eventually meets. Second, the criteria that decide rank and selection within a registry are themselves earned-trust signals: first-party verification, maintenance, reviews, safety. Winning the registry contest does not route around the earned layer; it routes straight back into it. Third, the final selection happens at query time, among the shortlist, on trust the agent applies — which publishing and listing do not control.

So the objection relocates discovery from the protocol to the registry, and it is right to. But inside the registry the structure is unchanged: listing is the gate, earned trust is the tie-breaker. “List your server” is true and worth doing. “An MCP server is a discovery channel” overclaims what the listing buys — much as calling a bought link insertion an “authority signal” overclaims what money can purchase.

What would prove this wrong

There is a clean falsifier. If a dominant agent platform began selling server selection — letting you pay to be the default server for a capability class, ahead of better-corroborated rivals, overriding the trust checks — then a published server would become a buyable acquisition channel, and this article would be wrong. Watch for sponsored registry placement and paid “preferred server” slots. It is unlikely for the same reason ad-funded answer engines still fence their answers off from paid influence: an agent that connects a user to an unreliable server because someone paid degrades its own output, and reliability is the product these platforms compete on. The visible 2026 trend runs the other way — toward tighter curation, first-party verification, and namespace ownership, not looser pay-to-rank. If that reverses, revisit the whole argument. Until it does, the server is retention — and defending that retention is closer to protecting a hard-won position from interference than to chasing new reach.

What to do Monday

Strip it to actions.

• Reclassify the line item. Move “publish MCP server” out of your acquisition budget and into retention and infrastructure. It is fulfilment, and mis-filing it is what wastes the money.
• Ship a lean, first-party server — but only if it is warranted. Build one when your data is structured, changing, or gated enough to be queried repeatedly. If a static page already serves the data, skip the server and save the build.
• List and verify everywhere it belongs. The official MCP Registry and the major catalogues, with first-party verification and clear, capability-accurate tool descriptions. Treat this as table stakes to clear, not a campaign to win.
• Put the real budget into being chosen. Selection is a trust decision, so fund the earned corroboration — coverage, citation, genuine references — that makes both models and agents comfortable naming you. This is the same earned-media work that decides which entity gets recommended.
• Switch the KPI. Stop counting installs as if they were discovery. Measure reuse: queries per connected agent, return rate, and which door referred each connection.
• Run the Cold-Agent Test on every new “AI discovery surface” you are pitched this year. No / Yes / Yes means retention. Price it accordingly.
• Publish your own numbers. A first-party study of your server’s reuse — built on data only you hold — is a citable asset that earns the corroboration the server depends on, and it travels across every market you operate in.

One line to leave with: a published MCP server does not get you discovered. It gets you connected and — if your data is worth returning to — reused. Build it for the reuse, earn the discovery elsewhere, and stop paying acquisition prices for a retention asset. The same rule holds whether your market is the City of London or the fast-growing agent economies of India and South Asia: the surface where a stranger truly lands is the earned one, and being the source an engine reaches for is still the work that decides everything downstream. For the toolset that supports it, our guide to the best link building tools and our primer on sponsorship-based link building map the earned-and-paid terrain the server sits on top of.