Direct answer
There is no single MCP marketplace. The Model Context Protocol is an open spec for connecting models to tools, and discovery happens in pieces: registries list servers, hosts like ChatGPT and Claude load a filtered set, and the model reads your tool's name, description, and JSON schema before deciding to call it. Visibility here is written, not bought.
The protocol is a contract, not a storefront
Anthropic published MCP in November 2024 as an open standard, and the specification describes a client-server relationship: a host application — Claude Desktop, an IDE agent, ChatGPT — connects to a server that exposes tools, resources, and prompts over JSON-RPC. That's the whole shape of it.
Think of a wall socket, not a shopping aisle. The socket standard tells every appliance how to draw power; it says nothing about which lamp gets plugged in. MCP does the same job for capability. It removes the integration tax — one server, many hosts — and it removes the gatekeeping too. Nobody approves your server. Nobody shelves it. That freedom is also the trap: teams ship a working MCP server, announce it, and then watch it get called by exactly no one, because a protocol that lets everyone in provides no mechanism for being found.
"So how do I get listed?" is the wrong first question. The right one is: when a model has sixty tool definitions in front of it and a user's sentence to match against, what makes it reach for yours?
"Marketplace" is the wrong noun — and that's the point
Registries exist. The project's GitHub org hosts reference servers and tooling, and third-party directories have sprouted around them. But three gates stand between a listing and an actual tool call, and each gate obeys different rules:
- Existence. Does a host's discovery layer know your server is out there? Registries and docs pages answer this.
- Loading. Does the host pull your server into the context window at all? Connector allowlists, authentication, and per-session tool budgets answer this.
- Selection. Given a user question, does the model choose your tool over its siblings? Your metadata answers this.
Most teams optimize only the first gate and then blame the protocol. The second gate is largely out of your hands — it's product policy at OpenAI, Anthropic, and Google. The third gate is entirely yours, and it's where the leverage sits.
There's no public data on how any major host ranks or filters tools before inference; vendors don't publish it and there's no third-party benchmark. So stop looking for the algorithm. Optimize for the thing you can inspect: the text you write.
What a model actually reads before it calls you
Tool selection is a language problem wearing a JSON costume. OpenAI's function-calling guidance is blunt about this: the description field is how the model decides when and whether to invoke a function, which makes it prompt copy, not documentation.
Here's the before-and-after from a payments server we reviewed:
Before
{ "name": "ll_query", "description": "Query ledger data." }
After
{
"name": "find_unpaid_invoices",
"description": "Use when the user asks who owes money, which invoices are overdue, or wants a receivables summary. Do not use for paid invoices, payroll, or expense reports."
}
A user types "who still owes us from March?" The first description matches nothing — "ledger" and "query" are engineer words. The second matches on three separate tokens the user actually said. When a host shortlists tools, it typically does so by comparing the user's request against these strings, then handing the survivors to the model. Poorly worded tools don't lose by a little; they never enter the room.
Three more details carry weight. Schemas with enums and required fields stop the model guessing. Parameter names that read like English (customer_name, not cn) reduce malformed calls. And error strings are instructions: "invoice_id not found — call list_invoices first" teaches the model how to recover, while "400 Bad Request" teaches it to give up and answer from memory.
Step-by-step: metadata that survives selection
Here's the sequence we hand to teams shipping a server this quarter.
Name in the user's vocabulary. Verb plus object, phrased the way someone would ask: find_unpaid_invoices, schedule_followup, check_shipping_status. Skip your product's prefix. The model already knows which server it's in.
Write the description as a routing decision. Two sentences: when to use it, when to leave it alone. The negative case matters as much as the positive one when five of your tools sound alike.
Constrain the schema. Enums over free text, explicit required arrays, and one example payload in the tool's docstring. Ambiguity costs you tokens and correctness at the same time.
Make failures teach. Every error message should name the next valid call.
Publish a page a crawler can parse. Your server's docs need a stable URL, a first paragraph that says what the server does in plain language, and markup search engines understand. Google's structured-data documentation explains how markup earns eligibility for rich treatment in results, and schema.org supplies the vocabulary — SoftwareApplication for the server, APIReference or HowTo for the install path. That's the difference between a page a model can quote and a page it skips.
Register everywhere you're permitted. The reference org, community directories, your own changelog. Registration is cheap; skipping it is free invisibility.
Answer engines cite pages, not servers
This is the part teams miss. Perplexity and ChatGPT don't footnote an MCP handshake. They footnote a web page. When someone asks an answer engine "how do I connect my CRM to Claude," the citation will be a docs page, a comparison post, or a README — something a crawler could read and a model could paraphrase.
So treat documentation as the distribution channel. A worked example: a team's MCP server docs lived in a gist with a two-line description and a broken image. Six weeks after they moved it to a canonical URL with a capabilities table, an install command, a dated changelog, and structured markup — plus an llms.txt file pointing crawlers at the pages that matter — their server started appearing in answer-engine responses to setup questions. No ads, no directory placement. A machine-readable page.
On llms.txt specifically: there is no public adoption data, so treat it as cheap insurance rather than a ranking lever. It costs twenty minutes.
The corollary is decay. The protocol moves — spec revisions, authentication changes, new transport options — and a docs page written against last year's version quietly stops being the page a model trusts. Detecting that drift and refreshing the affected pages is a calendar task, not a launch task.
Measuring visibility you can't buy
You will never see a host's logs. You can't count tool calls inside ChatGPT. Accept that and measure the layer you can reach: are the pages describing your tools being retrieved, quoted, and cited when people ask relevant questions? Answer-engine citation tracking answers that directly, by watching which URLs show up in responses across engines and prompts you care about. Pair it with a broader AI-visibility audit to find out whether your docs are even eligible — indexed, parseable, and written in the language of the question. If a page fails at retrieval, no amount of server quality rescues it.
Two honest limits. First, no vendor publishes tool-selection telemetry, so you're inferring from public surfaces. Second, rephrasing a description and watching citations move is correlation, not proof. Run it as a loop anyway; it's the only feedback signal you get.
FAQ
Is there an official MCP marketplace?
No. Anthropic open-sourced the protocol and maintains a GitHub organization with reference implementations, but there's no central store with submission review and a checkout page. Discovery is spread across registries, host connector directories, and the open web. That's a feature of the protocol's design, not a gap someone forgot to fill.
Does listing my server in a registry make ChatGPT use it?
No. A listing helps with gate one — existence. Whether a host loads your server depends on its own connector policies, and whether the model calls it depends on your tool metadata. Registration is necessary and nowhere near sufficient.
How many MCP servers exist?
There is no public, audited count. Directory totals are self-reported and change weekly, so any number you see quoted should be treated as a snapshot of a listing page rather than a census.
Do I need llms.txt to be found by AI?
No, and no major engine has confirmed it as a ranking input. It's a low-cost way to hand crawlers a curated map of your most useful pages, which is worth doing, but it won't compensate for documentation a model can't parse.
Can MCP work help my regular SEO?
Indirectly, and for a boring reason: the disciplines overlap. Clear names, accurate descriptions, structured markup, stable URLs, and a changelog that reflects reality are the same things that make pages quotable by answer engines. Tagging tool descriptions is prompt engineering; writing the docs page is publishing.
Next step
Your server's visibility is decided by text you control, sitting on pages you can inspect today. Start by finding out which of those pages an answer engine will actually retrieve: Run a free GEO audit of your site.
Top comments (0)