How to list your MCP server in Claude Connectors Directory

If you want your MCP server inside Claude, you submit it to the Claude Connectors Directory, Anthropic reviews it, and if it passes, that listing is the credential. There’s no separate badge to buy. For a third-party SaaS connector, getting accepted into the directory is the “verified by Anthropic” status, full stop.

So the work isn’t “how do I get noticed.” The work is “have I built the thing they review, the way they review it.” Most rejections aren’t about quality of idea. They’re about a checklist item you skipped.

Let me walk through what actually gets a server in, and what gets it bounced.

What “listed in Claude” actually means

Anthropic runs one of the few true public pipelines in this whole space: you submit, a human reviews, and accepted connectors appear in a directory real users browse. The Claude Connectors Directory is, in Anthropic’s words, connectors “built and maintained by third-party developers using the Model Context Protocol,” and Claude “can work with your tools, databases, and applications” through them. That review step is the differentiator. Anyone can spin up an MCP server. Not everyone clears the bar to sit in Claude’s directory.

This matters more than a vanity listing. Once a connector is in the directory, a Claude user can turn it on without your sales team in the loop. The connector is the distribution. And because Anthropic screens entry, the listing carries a trust signal a random GitHub repo never will.

One thing to be clear about, because people conflate them. The directory listing is the verified status for a SaaS connector. The separate “Anthropic Verified” badge you may have read about belongs to the Claude Code plugins program, a different surface with its own two-tier review. If you’re shipping a remote connector for your product, the directory is your target. Don’t chase a badge that isn’t meant for you.

Build to the strict bar once

Here’s the move that saves you three rounds of rejection: build to the strictest common requirements before you submit anywhere, Anthropic included. Most major programs share the same spine, so clearing it once clears most of every vendor’s bar.

The spine looks like this. A remote, cloud-hosted server on a public HTTPS endpoint rather than a local desktop build. Streamable HTTP as the transport, because the old standalone SSE transport is deprecated and gets rejected. OAuth 2.0 with a real user-consent flow. Every tool annotated. A public privacy policy that’s actually live by your submission date. A demo account with realistic sample data and setup notes a reviewer can follow without your help.

Build that package once and every later submission gets cheaper.

Why front-load all of it? Because each vendor review is slow and opaque, and a single missing item sends you back to the end of the queue. Fixing the privacy policy after a rejection costs you a week you didn’t need to spend. The reusable package is the whole game here. This is also where workflow infrastructure earns its place in an AI stack: an agent that can call your tools still needs a defined process to follow, or it just makes expensive mistakes faster. If you want the deeper background on the protocol itself, our explainer on what MCP is covers the architecture, and the cluster hub on AI and the future of work collects the rest.

Inside Anthropic’s review

Now the specifics, straight from Anthropic’s own submission docs. Anthropic requires that “all tools must include a title and the applicable readOnlyHint or destructiveHint,” that you “use OAuth 2.0 for authenticated services,” that connections use HTTPS, and that you “provide clear setup and usage instructions.” The annotation rule is precise. The review criteria spell it out: readOnlyHint: true for read-only tools, destructiveHint: true for tools that modify or delete data. A reviewer needs to see, at a glance, which of your tools can change a customer’s account.

Authentication is where most of the real engineering time goes. A correctly built remote MCP server doesn’t just accept any caller. When an unauthenticated client knocks, it answers with a 401 and a WWW-Authenticate header that points the client at your OAuth metadata. Here’s that handshake against a production server:

That 401 isn’t a failure. It’s the OAuth discovery dance working as intended: the client reads the challenge, fetches the server’s .well-known metadata, registers, and walks the user through consent. A reviewer’s test client does exactly this, which is why a clean OAuth flow plus a working demo login isn’t optional. The transport and tokens are where servers stall. The tool logic rarely is.

A couple of practical guidelines round it out. Anthropic asks you to keep tool responses reasonably sized for the task, and not to return a full database dump when a summary was requested. Submission happens through the portal in Claude.ai admin settings, with a public form as the alternate route. Anthropic warns that “review times vary with queue volume,” so don’t promise your team a date.

How do you keep from getting rejected?

Lead with the two causes behind most rejections, because they’re the cheap ones to fix and the ones reviewers check first.

First, the privacy policy. Anthropic states plainly that “missing or incomplete privacy policies result in immediate rejection.” Not a note, not a request for changes. A rejection. Your policy needs to cover what data the connector touches, why, who sees it, how long you keep it, and what control the user has. Write it, host it on a public URL, and confirm it loads before you submit.

Second, the annotations. A tool without a title or with the wrong hint is the single most common rejection cause across these programs. Go tool by tool and mark each one for what it really does. Is it read-only? Does it delete things? Reviewers reward accuracy, not optimism.

Honesty in the labels is the whole trick here.

Beyond those two, expect the review to be slow and quiet. You won’t get a running commentary. Build the demo account so a stranger can log in and see your tools do something real, write setup steps that assume no prior knowledge of your product, and then wait. We operate a production MCP server, and the part that consistently eats the most time isn’t the tools, it’s the OAuth discovery and consent plumbing. Budget for that.

If you want to see the shape of a mature server before you build yours, our walkthrough of Tallyfy’s MCP server shows how tools get scoped to a defined process, and the Tallyfy AI overview covers how an agent stays inside guardrails once it’s connected. The pattern that survives review is the boring one: a small set of accurately-labeled tools, real auth, and a process behind them.

The first concrete step isn’t the form. It’s standing up a reviewer demo account with sample data and publishing your privacy policy at a live URL. Do those two things, label every tool for what it does, and the submission becomes a formality instead of a coin flip. If ChatGPT is also on your roadmap, submitting an app there reuses almost the same package, with a different bar to clear first.