Getting Your Connector into the Claude Connectors Directory

Two facts about listing a connector reshape how you plan the work, and neither one is about your code.

The first is where submission happens. It's a portal inside your organization's admin settings on Claude.ai, so you need a Team or Enterprise organization to submit at all, because admin settings aren't available on individual plans (submission docs). A solo developer on Pro or Max with a working remote MCP server has no submit button. Access is narrow even inside an org: by default only Owners and Primary owners can submit and manage listings. On Enterprise, an Owner can delegate through a custom role carrying either the Directory management permission or the broader Libraries permission. Team plans don't have custom roles, so on Team it stays with Owners.

The second is that you don't apply for Verified. Submitting triggers an automatic policy scan, and your server is listed as a Community connector by default. Anthropic may then escalate listings it judges highly useful to verified review, which is higher touch, slower, and involves reviewers running a functional test of each tool. That escalation is assessed automatically and needs no action from you (review criteria). So the outcome you can aim at is passing the scan and being a good Community listing. Every server in the directory meets the same criteria whichever label it ends up with, and the label is a quality signal for users rather than a switch that changes how the connector runs. Claude Connectors vs. MCP servers vs. the MCP connector API unpacks what the labels mean to the people installing your work.

Everything below assumes a remote MCP server that already runs. If you don't have one, build a custom Claude connector with a remote MCP server gets you there; the deploy-log server from that guide is the running example here.

What the portal expects you to have ready

The portal runs eleven steps and saves your progress in the browser as you move between them, so you can jump back without losing work. Several fields need artifacts that don't live in your repo, and hunting for them mid-flow is the slow way to do this.

The listing copy has hard ceilings: server name 100 characters, tagline 55, description 2,000, and one to five categories (submission docs). Fifty-five characters is tighter than it sounds.

Some of that copy is harder to take back than the rest. The URL slug is permanent once published, since it determines your listing page's address, and it stays locked while the rest of the metadata remains editable. The detail card description is yours alone: you write it in the portal and it isn't editable by Anthropic, so nobody on the review team will tighten your copy on the way through. Treat that box as published text rather than a form field. The display name can be changed later, but renaming a published server affects existing users and sends the listing back through review.

Tool design is where submissions fail

Anthropic publishes the most common rejection reasons, and the largest one is structural rather than cosmetic. A single tool that accepts both safe HTTP methods (GET, HEAD, OPTIONS) and unsafe ones (POST, PUT, PATCH, DELETE) is rejected, and a catch-all api_request tool with a method parameter is called out by name. Documenting safe versus unsafe operations inside one tool's description does not satisfy the rule; the operations have to sit in separate tools (review criteria).

In code, that's a naming and registration change more than a logic change. Reads go in one tool, writes split by action type:

// Rejected: one entry point, safe and unsafe methods behind a parameter
server.registerTool("api_request", { /* method: "GET" | "POST" | "DELETE", path: string */ }, handler);

// Accepted: reads separated from writes, writes split by action
server.registerTool("get_recent_deploys", { title: "Get recent deploys", annotations: { readOnlyHint: true } }, ...);
server.registerTool("trigger_deploy",     { title: "Trigger a deploy",   annotations: { destructiveHint: true } }, ...);
server.registerTool("cancel_deploy",      { title: "Cancel a deploy",    annotations: { destructiveHint: true } }, ...);

The annotations aren't decoration. Every tool has to carry a title plus the applicable hint, readOnlyHint: true for reads or destructiveHint: true for anything that modifies or deletes, and those hints determine auto-permissions in Claude: read-only tools can run without per-call confirmation, while destructive tools always prompt (review criteria). Getting them right is a usability decision that happens to also be a submission requirement.

The portal enforces this before a human sees it. On the Tools step, your tools, prompts, and resources sync automatically from the connected server and get grouped by whether their annotations declare them read-only or write, with unannotated tools in their own group, and anything flagged for a missing title or annotation has to be fixed server-side before you can submit. A one-tool deploy-log server lands cleanly in the read-only group because get_recent_deploys already carries readOnlyHint: true. Add trigger_deploy without annotations and it drops into the unannotated bucket, flagged to fix on your server before you submit.

Three smaller rules round it out:

• Freeform query tools have to name their target. If a tool accepts endpoint paths, query strings, or request bodies the caller constructs, its description must link to or explicitly name the API behind it. "Makes a request to the API" fails. Purpose-built tools calling a fixed endpoint internally are exempt.
• Tool names are capped at 64 characters.
• Descriptions have to match actual behavior, stating precisely what the tool does and when to invoke it.

Descriptions that read as prompt injection

A tool description is a place people put instructions, and Anthropic treats it as an attack surface with five named rejection patterns (review criteria). Descriptions are rejected if they:

• Instruct Claude to call external software or tools the user didn't request
• Interfere with Claude calling other tools
• Direct Claude to pull behavioral instructions from external sources
• Contain hidden, obfuscated, or encoded instructions
• Tell Claude to behave in ways unrelated to the tool's function, attempt to override system instructions, or promote products and services

The guidance underneath all five is one line: describe what the tool does, don't tell Claude how to behave. "Always call this tool before answering questions about deployments" is the failing shape, and it's an easy thing to write while tuning tool selection.

"Every tool must return a successful response"

That sentence is the functional-quality criterion, and the rest of the list follows from it: generic errors like a bare "Internal Server Error" or a detail-free "Bad Request" fail review, inputs need validation with actionable error messages instead of silent acceptance, responses should be sized for the task rather than dumping a whole database, and the server shouldn't collect conversation data beyond what the tool needs or query Claude's memory, chat history, conversation summaries, or user files (review criteria).

Read as an engineering requirement rather than a policy, that's an observability problem. Reviewers on the verified path functionally test each tool, so the claim you make at submission time is that every tool succeeds with valid parameters and fails informatively with invalid ones. Proving it means per-tool success and error evidence across the whole surface, not confidence about the two tools you use most. The Test & launch step asks you to confirm you've run every tool yourself, through MCP Inspector or as a custom connector.

The timing is awkward: Anthropic's own health and usage metrics only start once you're published, so the window where you most need per-tool evidence is the window where the dashboard is empty. Your server logs are the only source until then, and a tool-level view of call volume, error rate, and error shape is what AgentCat gives MCP servers.

Error shape matters as much as error rate: a reviewer reading "Internal Server Error" learns nothing, while No service named "checkut-api". Known services: checkout-api, search-indexer. shows validation doing its job. Error handling in custom MCP servers covers the mechanism, tool results carrying isError versus genuine protocol errors.

What the directory won't take

Two categories are refused regardless of implementation quality (review criteria):

• Connectors that transfer money, cryptocurrency, or other financial assets.
• Connectors that generate images, video, or audio via AI models. Design tools that produce diagrams, charts, or UI mockups are explicitly allowed, so the line is generative media rather than visual output.

An ownership rule quietly disqualifies a whole genre of wrapper server too: your server has to call your own first-party APIs or APIs you legitimately proxy, and the MCP server domain should match your service. A well-built connector for somebody else's public API, hosted on an unrelated domain, is not a directory candidate.

Desktop extensions and plugins take a different path

The portal accepts remote MCP servers only. Local servers packaged as MCP Bundles use a separate desktop extension submission form, and skills aren't a standalone submission type at all; you bundle them into a plugin.

Local connectors carry a privacy-policy requirement worth checking twice, since missing or incomplete privacy policies are an immediate rejection (submission docs). Three artifacts: a "Privacy Policy" section in README.md, a privacy_policies array in manifest.json (manifest version 0.2 or later), and HTTPS URLs to the policies. The policy has to cover data collection practices, usage and storage, third-party sharing, data retention, and contact information. All five, not most of them.

Two terms here are non-negotiable rather than reviewable: the MCPB open-source and "spec will evolve" clauses in the Software Directory Terms can't be waived, and plugins must link a public GitHub repo, so closed-source plugins aren't accepted. Run claude plugin validate before submitting one.

The portal steps that need a real answer

Most of the eleven steps are data entry against artifacts you already gathered. Four ask questions worth deciding before you open the form:

1. Connection. Beyond the https:// URL and the transport (streamable HTTP or SSE), the portal asks whether every user connects to the same URL or different users connect to different URLs. Multi-tenant servers with per-customer subdomains answer differently from a single shared endpoint.
2. Authentication. OAuth (with dynamic client registration, client ID metadata documents, or a static client ID held by Anthropic), a custom connection where users supply their own URL or credentials, or none. If your server starts unauthenticated and individual tools prompt for auth on demand, flag that here.
3. Data handling. Whether the underlying API is your own, proxied from a partner with permission, or a third party's you don't control, plus whether the connector touches personal health data or sponsored content.
4. Test & launch. Access instructions detailed enough for a reviewer to work through your server end to end: every link, every credential, every step, written for someone who has never seen your product.

Compliance then asks for seven policy acknowledgments covering directory guidelines, first-party API usage, financial transactions, AI media generation, prompt injection, conversation data collection, and public documentation. All seven are required, and each maps to a criterion above, so they're a formality if you've done the work.

The final Review step surfaces quality warnings, and those travel with your submission: very short answers get flagged and shared with the review team. Terse answers aren't just unhelpful, they're visible.

After you hit submit

Review times vary with queue volume and the portal is always open, so there's no window to hit. Status and reviewer feedback land in the submissions dashboard in your admin settings; when reviewers request changes, the feedback appears on the submission's detail page and you fix and resubmit from there. Escalations go to mcp-review@anthropic.com.

Once you're published, that detail page grows a metrics view: a health badge driven by your 30-day disconnect rate (healthy at or below 5%), directory rank, tool call users, tool calls, and error rate, with per-tool and per-product breakdowns (managing your listing). Metrics are in beta, computed daily, can lag by up to 24 hours, and drop low-volume rows.

They also see only part of the picture, which Anthropic says outright: the numbers cover traffic from Claude surfaces, connections from other MCP clients aren't visible to Anthropic, and "your own server logs can therefore show activity that this page doesn't." Good signal on how the listing performs, no substitute for instrumenting your own server.

What actually gets you through

Strip away the form-filling and the criteria describe a server whose tools are honestly named, correctly annotated, split along the read/write line, and demonstrably working end to end. That's the server you'd want for your own users anyway, so little of this is busywork imposed by the directory. The genuinely external gates are three: the org requirement, the permanent slug, and the assets you gather before you start.