Getting accepted into the Claude connectors directory: the full submission

An MCP server listed nowhere is a server nobody installs. This is the part technical teams underestimate most: distribution work is separate from build work, and it has its own requirements.

The Claude connectors directory is the most visible channel, and the most demanding. Here is what a submission that passes contains, in the order to assemble it.

One caveat: the exact criteria evolve. What follows describes the shape of a submission, not an official list. Always check Anthropic's current documentation before submitting.

1. The server has to be current before anything else

Do not submit a server you are going to rewrite three weeks later.

The sensible order is: migrate to the current revision, harden, then submit. A server two revisions behind is immediately visible, and the fix delays all of your distribution.

Concretely, before opening the submission: conformant transport, mandatory headers, corrected error code, verified OAuth chain.

2. The authentication chain

This is the most frequent rejection point, and the most expensive to fix under pressure.

What needs to be in place:

• A complete, clean OAuth flow, with iss parameter validation
• Scopes that mean something, not one token that opens every tool
• Per-client revocation, visible to the user, not just a "disconnect everything" button
• Authentication error handling that tells the user clearly what is happening

The simple test: connect your server from a fresh account, with nothing prepared, and count the obscure steps you go through. That journey is what gets evaluated.

3. The privacy policy

It has to be accurate, not generic. A downloaded template with the names swapped is obvious in three lines.

What it must state precisely:

• Which data your server receives through tool calls
• What you do with it and how long you keep it
• Who it is passed to, including model providers if you run inference yourself
• Where it is hosted
• How a user requests deletion

The model provider point is new for many teams. Now that sampling is deprecated, a server that needs a model calls a provider itself, which creates an outbound flow of user data that has to be documented.

4. Tool descriptions

Descriptions are not internal documentation. They are read by the model, often visible to the user, and they are part of the evaluation.

What gets looked at:

• Each tool does one thing and its name says so
• The description explains when to use the tool, not just what it does
• Destructive tools are annotated as such, read-only ones too
• No infrastructure leaking through descriptions or error messages

A server with forty badly named tools reads worse than one with twelve clear ones, even if it does more.

5. The visual presentation

A directory listing is a product page. You need a name, one sentence saying what it does for the user, a clean icon, and something showing the product in action.

If your server exposes an interface through MCP Apps, show it. A preview rendered in the chat beats three paragraphs.

The description sentence deserves real work. It decides installation, not your tool list.

6. Infrastructure hardening

Before submitting, run the list:

• Payload size limit
• Per-tool rate limiting, now possible at the HTTP layer
• A write log the user can consult
• Clean behaviour on quota exhaustion, with a non-retryable error
• Monitoring and alerting on authentication rejections

This block is not only defensive. It is what you show when someone asks why they should trust you.

The order that saves time

1. Migration and protocol conformance
2. OAuth chain and revocation
3. Infrastructure hardening
4. Tool and description cleanup
5. Privacy policy rewritten from all of the above
6. Visual presentation
7. Submission

The privacy policy sits fifth for a reason: it has to describe what your server actually does. Writing it before hardening means writing it twice.

FAQ

How long does a submission take?

The submission itself, a few days. What takes time is the corrections the preparation reveals. Two to four weeks for a server that has never been prepared.

Is it worth it for a small product?

The visibility is real. But the deeper benefit is that preparing forces a level of quality you would otherwise have kept postponing. Even rejected, you come out with a better server.

Do I need a domain and a legal entity?

At minimum a credible public presence: domain, product page, contact, legal notices. A server with no verifiable identity does not pass.

The full submission, assembled for you

Claude directory submission: €1,200. I assemble the whole thing, list what blocks before submission, and hand the server back ready. I have done the exercise on my own products.

Interested? Talk about the directory submission →

Related reading

• MCP Apps: a real interface in the chat, without an iframe
• Where to list your MCP server in 2026
• The 8 flaws found in almost every production MCP server