Shipping an MCP Server to the Claude and ChatGPT Directories: What Review Actually Checks

Building an MCP server is a weekend. Getting it listed where users can find it is a different project, with its own requirements, its own failure modes, and a queue you do not control.

July 2026 rearranged both destinations. On July 9, OpenAI folded its app directory into a Plugins Directory shared by ChatGPT and Codex, repackaging every existing app as a plugin. Anthropic split its Connectors Directory into two tiers: submissions pass an automated policy scan and list as Community, and Anthropic escalates a subset to Verified review, where a human runs a functional test of every tool.

On both sides, review tests your metadata and your honesty far more than your code. Almost every documented rejection traces to something the submitter could have fixed in an afternoon, had they read the criteria before writing the tools instead of after. This is a working guide to both processes as of July 29, 2026. If you are still deciding how to architect the server, the deployment advice in our MCP enterprise guide and the transport changes in the 2026-07-28 stateless spec come first.

What You Are Submitting To

Anthropic runs a second directory for plugins, surfaced in Claude Code as the official claude-plugins-official marketplace and in Cowork as the plugin directory. It has its own rules, most importantly that the plugin repo must be public on GitHub. Closed source is accepted for connectors but not for plugins.

The update models are opposites, and that difference should shape your release plan. Once an Anthropic plugin is published, pushes to your GitHub repo are mirrored by CI with automated screening on each update, and you never touch the form again. An approved OpenAI listing carries a reviewed metadata snapshot, so changing a tool means rescanning the server, submitting a new version for review, and publishing the approved version. Adding one tool to an OpenAI plugin is a release event with a queue in front of it. Scope your first version accordingly instead of shipping something thin you intend to expand next week.

The Exam Both Reviewers Give

Most of what gets checked is identical across the two directories, so one pass of preparation covers both.

Annotate every tool, correctly. Anthropic requires a title plus either readOnlyHint: true or destructiveHint: true. OpenAI requires all three of readOnlyHint, openWorldHint (true when the tool changes state visible to the public internet), and destructiveHint. These are not documentation. In Claude they drive auto-permissions: read-only tools run without a per-call confirmation, destructive tools always prompt. OpenAI names incorrect or missing action labels as a common cause of rejection. A write tool labeled read-only to reduce user friction is the fastest way to be removed after approval.

Split read from write. Anthropic rejects any tool accepting both safe HTTP methods (GET, HEAD, OPTIONS) and unsafe ones (POST, PUT, PATCH, DELETE). The catch-all api_request tool with a method parameter, a common shortcut in internal servers, fails automatically. Splitting writes further by action type (create, update, delete) is the preferred shape, and explaining the distinction in the description does not satisfy the rule.

Describe tools narrowly and accurately. The description must state what the tool does, when to invoke it, and must match actual behavior. A tool accepting freeform paths or request bodies must name or link the target API; "makes a request to the API" fails on both sides. OpenAI adds that descriptions may not be promotional or comparative, and may not push the model toward triggering more broadly than the user's explicit intent.

Do not write instructions to the model. Anthropic rejects descriptions that tell Claude to call other software, interfere with Claude calling other tools, pull behavior from external sources, contain hidden or encoded instructions, or attempt to override system instructions. Their phrasing is the whole rule: describe what the tool does, do not tell the model how to behave. Every one of those patterns is also a prompt injection primitive, which is why the automated scan looks for them.

Publish a real privacy policy. Anthropic states that a missing or incomplete privacy policy is an immediate rejection, and requires coverage of collection, use and storage, third-party sharing, retention, and contact information. OpenAI requires the same substance, reviewable before installation.

Minimize what you take and what you return. Anthropic bars querying Claude's memory, chat history, conversation summaries, or user files. OpenAI bars full conversation history and raw transcripts as inputs, and bars servers from reconstructing the chat log. On responses, OpenAI expects you to strip diagnostics, telemetry, and internal identifiers such as session IDs, trace IDs, and timestamps. Both prohibit payment card data, health data, government IDs, and credentials, and both want coarse location at most.

Call your own APIs. Anthropic requires first-party APIs or ones you legitimately proxy, and expects the server domain to match your service. OpenAI is blunter: unofficial connectors to third-party services are rejected, as is scraping or integrating with third-party APIs without authorization. If your server wraps someone else's product, you need their permission before you need a listing.

Give reviewers a working account. Both require credentials for a fully populated account. OpenAI adds a constraint that trips up security-conscious teams: reviewer credentials must work without MFA, SMS, email confirmation, or private-network access.

Where Anthropic Differs

The first surprise is organizational. Remote MCP server submissions happen in a portal inside claude.ai admin settings, and admin settings do not exist on individual plans, so you need a Team or Enterprise organization to submit a connector. On Enterprise an Owner can delegate through a custom role carrying the Directory management or Libraries permission; on Team it stays with Owners. Individual developers have two other paths: the desktop extension form, which has no org gate, or Console at platform.claude.com for plugin submissions. Budget for this before your launch date.

The portal walks eleven steps, and two deserve preparation. The Listing step sets your public metadata, including name up to 100 characters, tagline up to 55, description up to 2,000, categories, URLs, icon, and the listing slug, which is permanent once published. The Compliance step requires seven separate acknowledgments covering directory guidelines, first-party API usage, financial transactions, AI media generation, prompt injection, conversation data collection, and public documentation. Read them, because they are the policy you are agreeing to enforce on yourself later.

Two categories are not accepted regardless of quality: connectors that transfer money, cryptocurrency, or other financial assets, and connectors that generate images, video, or audio through AI models. Design tools producing diagrams, charts, or UI mockups are fine.

If your server opens external links through ui/open-link, declare your allowed link URIs so those destinations skip the confirmation prompt. List only origins and schemes you own, since third-party entries are removed during review, and note that subdomains are not implied. MCP Apps add an asset spec precise enough to fail on: three to five PNG screenshots, at least 1000 pixels wide, cropped to the app response with the prompt excluded from the image and supplied separately as text. No video, no GIF.

The two-tier outcome changes when you should submit. Your server lists as Community once it clears the automated scan, and Anthropic escalates listings it judges highly useful to Verified on its own initiative. You cannot apply for the checkmark. The automated criteria are what stand between you and distribution today; the functional review is a later bar you earn through usage.

Where OpenAI Differs

OpenAI front-loads identity and testing. The publisher account must clear individual or business verification, and the submitting user needs Apps Management write access on the organization role. Neither is instant, and both are prerequisites rather than parallel work.

The MCP tab takes your server URL as either a Universal URL, which covers most cases, or a Template URL using placeholder syntax for per-tenant endpoints. Template URLs require OpenAI's approval, so raise that early if each customer gets their own hostname. Domain verification is a token you host at a generated well-known URL.

The Testing tab is where a rushed submission shows. You supply at least five positive test cases, each documenting the prompt, the tool it should trigger, the result shape, and any test data, and three negative cases documenting a scenario your plugin should refuse or handle with a safe fallback, plus the reasoning. Writing the negative cases is the useful part, because it forces you to decide what your server does when asked to do something adjacent to its purpose but outside it, which is exactly what a reviewer will try.

OpenAI's content rules are stricter in commerce and presentation. Commerce is limited to physical goods, with digital products, subscriptions, tokens, credits, and freemium upsells all out, and checkout must be external on your own domain. Advertising is prohibited. Content must suit general audiences including users aged 13 to 17. Trial or demo plugins are not accepted, and neither is functionality the product already provides natively. Plugins declaring frameDomains receive extra manual review and are often not approved for broad distribution, so treat an iframe as a last resort rather than a default rendering strategy.

Approval and publication are separate here. Passing review does not list you; you publish from the portal when ready, which gives you launch timing that Anthropic's flow does not.

Authentication Is Where the Weeks Go

Anthropic's own documentation calls authentication the most common source of partner questions, and their troubleshooting guide reads like a list of afternoons other people have lost.

Pure machine-to-machine client_credentials, with no user in the loop, is not supported. Every connection requires user consent. If you need a stable registered client without dynamic registration, the supported route is Anthropic-held client credentials: you send a client ID and secret to the review team, Anthropic stores them against your directory entry, and users still pass through your consent screen.

For a directory listing, prefer Client ID Metadata Documents or Anthropic-held credentials over Dynamic Client Registration. DCR works out of the box, but it registers a new client on every fresh connection, which at directory volume produces an enormous number of registered clients on your authorization server. If you choose CIMD, Claude selects it only when your authorization server metadata advertises both "client_id_metadata_document_supported": true and "none" in token_endpoint_auth_methods_supported. Miss either and it silently falls back to DCR.

The discovery handshake has one shape that works reliably: return a 401 with a WWW-Authenticate: Bearer resource_metadata="..." header pointing at your protected resource metadata. The header is ignored on a 200. Your metadata's resource field must match the server URL exactly as the user enters it, path included, and if authorization_servers lists several entries, Claude uses the first and does not fall back.

Three infrastructure failures account for most "works locally but not in Claude" reports. First, hostname resolution: claude.ai connects from Anthropic's infrastructure over the public internet, and any resolved address that is not globally routable fails before a request is sent, so split-horizon DNS, dynamic DNS behind carrier-grade NAT, and AAAA-only hostnames all produce a connection error with nothing in your logs. Second, redirects: a registered URL that 301s to a different host loses the Authorization header per standard HTTP client behavior, and the failure surfaces as an authorization error rather than a redirect problem. Register the URL your server actually listens on, not the apex that canonicalizes to it. Third, your own edge: a WAF or rate limiter blocking Anthropic's published egress range produces 403s and 429s your application never sees, and the same range hits your authorization server, so an identity provider behind a different WAF breaks the flow even when the MCP server is reachable.

Watch the latency budget too. Claude waits ten seconds for discovery, registration, and token endpoints, and thirty for refresh. A token handler that occasionally stalls behind a downstream call produces intermittent connection failures that are miserable to diagnose from outside.

The Rejection List

Compressed, in the order we would check before submitting anything:

1. A catch-all tool mixing read and write behind a method parameter.
2. Missing or wrong annotations, especially a state-changing tool marked read-only.
3. A description that instructs the model rather than describing the tool.
4. A freeform query tool whose description does not name the API it queries.
5. A tool name longer than 64 characters.
6. Any tool returning a generic error on valid parameters. "Internal Server Error" with no detail fails, and reviewers do call every tool.
7. Responses that dump more data than the request warranted, or carry trace IDs, session IDs, and internal timestamps.
8. A missing, incomplete, or non-public privacy policy.
9. A test account that is empty, expired, or behind MFA the reviewer cannot pass.
10. Wrapping an API you do not own or have permission to proxy.
11. Money movement or AI media generation on the Anthropic side; digital goods, ads, or embedded checkout on the OpenAI side.
12. Documentation that does not exist yet. Anthropic requires public docs by your publish date, and a help-center article or blog post is enough.

How to Compress the Timeline

Neither company publishes a review SLA. Both say timelines vary with queue volume, and community reports on the Anthropic side describe waits measured in weeks. You cannot speed up the queue, so the only lever is how many times you enter it.

Treat the review criteria as a design document rather than a checklist. Tool decomposition, annotation, and description quality are architecture decisions, and retrofitting them after a rejection means reworking your tool surface, your tests, and your documentation at once.

Dry-run as a custom connector. Anthropic asks you to confirm you have run every tool through MCP Inspector or as a custom connector in Claude, and that path exercises the same authentication and networking stack the reviewer will hit, reproducing the DNS, redirect, WAF, and OAuth discovery behaviors behind most first-attempt failures. It costs an hour. The OpenAI equivalent is running your eight test cases in the product using the reviewer's demo account rather than your developer account.

Prepare the non-code assets in parallel with the build, because they gate submission just as hard as the server does: a public privacy policy, a public documentation page, a support contact, a logo, a populated demo account whose credentials work without MFA, listing copy inside the character limits, and screenshots to spec for MCP Apps. Every one of those is something a non-engineer can produce while the server is being written.

Submit to Anthropic as soon as you clear the automated criteria, since the Community listing is available immediately and usage is part of what triggers the escalation you are waiting for. And sequence your two submissions rather than firing them together, since a rejection reason from one directory usually applies to the other, and finding it once is cheaper than finding it twice in parallel queues.

What a Listing Actually Buys You

A directory entry makes your server discoverable and attaches a review label. It does not change what your server does. Anthropic is direct about this: the directory is a catalog, not a different kind of connector, any server can be added by URL as a custom connector without ever being listed, and once connected a Community connector behaves identically to a Verified one.

That matters for planning. If your users are a known set of enterprise customers, a custom connector with setup instructions may serve you better than a public listing and its ongoing obligations, which include maintaining security and functionality, responding to security issues promptly, and keeping descriptions accurate. If you want discovery by people who have never heard of you, the listing is the only route.

The teams that get through cleanly understood early that a directory submission is a product review, not a code review. The reviewer is not reading your implementation. They are checking whether your tools do what they claim, whether a user can tell a read from a write before approving it, and whether you asked for more than you needed. Build a server that would pass that reading, and the submission is paperwork.

Vindler builds production MCP servers and agent systems for companies in gaming, fintech, and enterprise software. If you are planning a connector and want the architecture and the submission path reviewed before you build, book a call.