How to Submit MCP App to Claude Connectors.

Claude Connectors work the same way ChatGPT apps do conceptually, but the submission process, the review criteria, and even where your app shows up to users are entirely different. If you've already gone through submitting an app to ChatGPT, don't assume the steps transfer directly.

This guide walks through what you need before you start, how to fill out the submission form, and what happens once your connector is in review, based on Anthropic's documentation and our own experience submitting connectors.

What Claude Connectors are and where your app will appear

A Claude Connector is an MCP server that Claude can call on during a conversation, whether to pull data, take an action, or render an interactive UI directly in the chat. Once a connector is added to the Directory, it becomes available to any Claude user who chooses to connect it.

Users manage their connectors at claude.ai/customize/connectors. That's also where they'll discover yours, alongside connectors built by Anthropic and other third-party developers.

The activation logic works in two stages.

When multiple connectors could help with what the user is asking, Claude surfaces them as options rather than picking one automatically. This way, if your connector is relevant to the conversation but the user hasn't connected it yet, Claude can suggest connecting it based on context. Once a user has connected your app, Claude can call it automatically within relevant conversations, without the user needing to invoke it by name each time.

This matters for how you think about discovery. Getting listed in the Directory gets you in front of users. Getting picked up automatically inside conversations depends on the same things that drive ChatGPT's indirect prompting.

Step 1: Build your MCP server with tools

Before you can submit anything, your server needs to meet a few non-negotiable technical requirements.

Start with Streamable HTTP transport. SSE transport was deprecated in the March 2025 MCP spec, and platforms are actively dropping support for it, so there's no reason to build on it now.

Every tool also needs proper annotations and must include either readOnlyHint or destructiveHint in its annotations. This isn't optional. As many developers in the OpenAI community state, missing annotations cause about 30% of rejections, making it one of the most common and most avoidable reasons connectors get sent back.

If your connector requires authentication, plan for OAuth from the start. Claude requires OAuth 2.1 with PKCE using the S256 challenge method, and pure client credentials flow without user interaction isn't supported. Every user has to complete their own consent flow, so design your auth around that from day one.

Step 2: Prepare server metadata for submission

Before opening the submission form, gather everything reviewers will actually test against. Having this ready beforehand saves you from stalling halfway through the form.

You'll need your server name, URL, a short tagline, a description, and three specific use cases with example prompts. You'll also need to know your auth type and transport protocol, plus a full list of your tools, resources, and prompts, with every tool carrying a human-readable name, a clear description, and the required safety annotations.

Documentation and policy details matter just as much as the technical setup. Reviewers expect public documentation, or private review docs that will be public by launch, along with a stable privacy policy URL. If your connector requires authentication, prepare test account credentials and clear setup instructions, detailed enough that a reviewer can walk through your server end to end without guessing at any step.

Step 3: Fill the submission form

Submission happens through the portal in your claude.ai admin settings if you're on a Team or Enterprise plan. If you're not, you'll submit through a Google Form instead, with largely the same information requested.

Let’s take a look at what each part covers, so you can prepare everything before you open it.

1. Server basics. Name, tagline, server URL, connector type (remote, desktop, or MCP App), and your primary use cases in 2-3 sentences, plus three specific example prompts showing how the connector gets used.
2. Connection details. Transport protocol, which must be Streamable HTTP, your auth type, read or write capabilities, and confirmation that your OAuth callback URLs are registered.
3. Tools and resources. Every tool listed with a human-readable title, confirmation that annotations are in place, confirmation that read and write tools are kept separate, and tool names within the character limit.
4. Documentation. A public docs URL works as a single help page or blog post if that's all you have, plus your setup and auth steps. If your docs aren't public yet, you can share a private staging link with the review team instead.
5. Privacy and compliance. Your privacy policy URL and a data handling summary covering what you collect, how long you keep it, and who you share it with.
6. Test account and branding. Login credentials for a test account with realistic sample data, plus your server logo and favicon. If you're submitting an MCP App, you'll also need three to five PNG screenshots, each at least 1000px wide.

Once everything above is filled in, you'll confirm seven policy acknowledgments covering the directory guidelines, API usage, financial transactions, AI media generation, prompt injection, conversation data, and public documentation.

A final review screen shows any quality warnings, such as unusually short answers, before you submit. Your progress saves automatically within a browser session, so you can step away and pick up where you left off.

Step 4: What to expect after you submit

Once you submit, your status and any reviewer feedback appear in the submissions dashboard. Beyond that, there's not much public information on timelines, and the process is still new enough that even developers going through it don't have a clear picture yet.

From our own experience, we submitted three connectors and, after about a month, received only a notification that we'd been added to the review queue, with no decision yet at the time of writing. We also don't yet know whether rejections come with specific, actionable feedback or just a simple approved or rejected status.

If you're planning your own submission, it's worth setting expectations accordingly. The review process is manual, so build in time, and don't assume a fast turnaround.

What we do know is what triggers rejection in the first place. Missing tool annotations we’ve covered at the start of the article are one reason. Beyond that, reviewers will reject submissions for missing or incomplete privacy policies, for any connector that fails their policy checks, or for tools that don't behave the way their descriptions claim.

Until more developers share their experience publicly, the safest approach is to treat your first submission like a dry run. Get the technical and documentation requirements right, expect the queue to move slowly, and don't make assumptions about feedback you might not get.

Concluding thoughts

Submitting to the Claude Connectors Directory rewards patience more than speed. The technical requirements are well documented and straightforward to meet. What's still uncertain is everything that happens after you hit submit, and that uncertainty is itself useful information. Build your connector assuming no one will hold your hand through review, and you'll be in a better position than developers who expect a fast process.

There's also a quieter advantage to going through this now. The same MCP server you build for Claude works across other hosts too, including ChatGPT, Goose, VS Code, and any future platform that implements the MCP App standard. The work you put into clear tool descriptions, proper annotations, and solid documentation can be reused.