Use your server
Listing readiness
Public MCP directories turn servers away for roughly the same handful of reasons. The Readiness tab calls your live server and tells you which of those reasons currently apply to it.
Where you submit
Four places take submissions today, and they want different things, so each one gets its own card and its own verdict. Being ready for the registry says very little about being ready for Claude.
- Anthropic's Connectors directory is what a Claude user browses to add your server, across Claude.ai, Desktop, mobile and Claude Code. You submit from your organisation's admin settings inside Claude.ai. Most listings land as community connectors, and Anthropic reviews a subset of those in more depth.
- Apps in ChatGPT run on the Apps SDK, which is MCP plus a UI layer. You submit through the plugin flow and hand over your production
/mcpURL. Worth saying, because the wording still trips people up: this has nothing to do with the 2023 plugin store OpenAI retired. - The official MCP registry is the protocol's own catalogue, maintained by the Model Context Protocol project. Publishing to it is a CLI step (
mcp-publisher) rather than a web form. - cursor.directory collects rules, plugins and MCP servers for the Cursor editor. It asks the least of the four, so that card is usually the first to go green.
What the checks read
Checks run against whatever is deployed right now, not against your repo. foro lists your tools over the same public endpoint an agent would use, so it sees what a reviewer sees. That call needs the project live; while it isn't, the tab says so rather than guessing.
Blockers and warnings
A blocker is a rule the listing states outright. Those are what the card counts, and zero of them is what "Ready to submit" means.
A warning is a quality problem nobody writes into their rules but reviewers notice anyway: two tools a model can't tell apart, a parameter with nothing explaining it. You can submit with warnings open. Agents will pick your tools wrong more often than they should.
Where a finding has one obvious place it gets fixed, it links there.
What gets checked
The endpoint. Claude and ChatGPT both want OAuth 2.1. A server left public, or on the shared bearer token every project starts with, is a blocker for those two and irrelevant to the other two. See authentication for the modes a project can switch to.
Your workspace URLs. A privacy policy and a support URL, both required by Claude and ChatGPT. They're workspace-wide, so setting them once clears the finding on every project you have.
Write annotations. A tool that looks like it writes something and declares nothing about it is a blocker for Claude. A readOnlyHint or a destructiveHint settles it; without one, foro and the reviewer are both going off the name.
Descriptions. No description blocks everywhere. Under 40 characters, or a description that only restates the tool name, is a warning, as is a parameter with no description. Tools that read alike get flagged as a pair.
Schema size. Every tool schema is loaded into the model's context before a single call happens, so past 10,000 tokens the tab warns. No directory publishes a threshold. That number is ours, and it's there for the agent rather than the reviewer. See tokens.
Fixing a finding
Two of them are settings here. Auth mode sits on the project's settings page, the privacy and support URLs on your workspace's, and both take effect when you save.
The rest live in your server's source, since that is what declares them. A tool's description is its docstring or its description argument, a parameter's description sits on the parameter, and a write annotation is readOnlyHint or destructiveHint in the tool's annotations. Edit, push, redeploy. The tab reads the running server, so a finding clears on the deploy that fixes it.
The Playground is where you check the fix landed. It shows each tool as your deployed server declares it, descriptions, parameters and annotations included. It only displays that declaration, so there's nothing to edit there.
Two warnings have no single line to change. Ambiguous tools are two or more a model can't tell apart, which means renaming or merging them. A schema overrun is the total across every tool, so it comes down by trimming schemas or splitting tools across servers.
What it can't tell you
This isn't an approval. The tab reads what your server declares: names, descriptions, schemas, annotations, auth mode. It never calls a tool, so it has nothing to say about whether your tools work, return what they claim, or handle data the way a reviewer will ask about.
Directory rules also change without notice, and a rejection can come down to a person reading your server and deciding against it. Clearing every blocker removes the reasons foro knows about. You still submit on each directory's own form.