MCP Distribution · ChatGPT
The largest audience of the three, and the strictest reviewer. OpenAI checks that your tools do what they say, that your listing matches your verified identity, and that a reviewer can sign in and run everything. Most rejections are mechanical, which means most are preventable.
The shape of it
OpenAI's process has a technical gate and an editorial one, and they fail differently. The technical gate is domain verification plus a tool scan: you prove you control the host, the portal reads your tools off the live server, and you annotate them. The editorial gate is a human reviewer checking that the app is what the listing claims, using credentials you supply.
Teams tend to plan for the first and get caught by the second. The scan is quick. Assembling a demo account a stranger can use, and eight test cases that describe real behaviour including refusals, is the part that takes a week nobody scheduled.
As of August 2026, Node8's research counted 2,305 listings in the ChatGPT directory. The State of ChatGPT Apps covers what got listed, who publishes it, and how concentrated the categories are.
Before the portal
Publishers complete verification in organization settings before submitting. Reviewers use that identity to confirm the submission matches the name, website, support contact, privacy policy and terms in your public listing. A mismatch between the verified entity and the listing is a rejection, not a query.
Submitters need Apps Management write access in their OpenAI Platform organization role. Owners already have it. Everyone else needs granting explicitly, and this is worth doing before the day you plan to submit.
Streamable HTTP transport, typically at a URL ending in /mcp. Temporary tunnels and local endpoints do not qualify: the endpoint has to stay reachable throughout review and domain verification. Private servers need a public HTTPS proxy in front of them.
Verification means serving an exact token at https://your-host/.well-known/openai-apps-challenge. Whoever can deploy to that host needs to be available. If your MCP host is a subdomain, the challenge base can be that host or a parent of it.
For authenticated servers you supply a login and password for a fully featured demo account. OpenAI rejects apps that require additional login steps such as a new account sign-up or two-factor through an inaccessible account. A reviewer who cannot get in cannot approve you.
Three of them: readOnlyHint for fetch and lookup, destructiveHint for irreversible changes, openWorldHint for tools that reach the public internet. Reviewers check that names, descriptions, schemas and annotations match actual behaviour, so an inaccurate annotation is worse than a missing one.
The portal
In the submission portal, choose Create plugin and then With MCP. The tabs run in this order, and the MCP tab is where the domain challenge and the tool scan happen.
The public listing: name, descriptions, developer identity, logo, category, and public website, support, privacy and terms URLs.
URL type (Universal for a fixed endpoint, Template for workspace-specific URLs and OpenAI-approved only), the production server URL, authentication, reviewer demo credentials, a content security policy naming the exact domains your UI fetches from, the domain-verification token, then Scan Tools.
Set readOnlyHint, openWorldHint and destructiveHint on every discovered tool.
Upload skills, or let them import from MCP when you scan tools.
Starter prompts showing the highest-value workflows: specific enough to show when to use the app, general enough to adapt.
At least five positive test cases and three negative ones. Positives need the prompt, expected behaviour, result shape and test data. Negatives explain why the app should refuse.
Countries and regions where the app is available.
Release notes, attestations, then Submit for Review.
The Testing tab is the one to start early. Five positive cases and three negative ones is not a large number, but negatives require deciding what your app should refuse to do, and that is a product question rather than a form field. Doing it properly also improves the tool descriptions, since the cases where an app should decline are usually the cases where its scope was vague.
Review
Reviewers validate that tool names, descriptions, schemas and annotations match actual behaviour, that responses do not carry unnecessary personal data, auth secrets, debug payloads or internal identifiers, and that the listing aligns with the verified publisher identity. Test cases are executed using the demo credentials you supplied.
Trial or demo versions that are not stable enough to review
Incorrect or missing action labels on tools
Misleading descriptions, or designs that copy an existing app
Collecting data the app does not need, including speculative "just in case" fields
Unofficial third-party connectors published without the underlying vendor’s authorization
Overly generic names, particularly single-word dictionary terms
Prohibited categories: adult content, weapons, gambling, drugs
Iframes, which draw extra manual review and are often not approved
If your OAuth implementation supports workspace domain restrictions, reviewers additionally confirm that the authorization server advertises a UserInfo endpoint returning the user's email claim with email_verified set to true. That is an easy thing to discover late and an easy thing to add early.
FAQ
When the portal detects an MCP submission it issues a challenge. You serve that exact token at https://your-host/.well-known/openai-apps-challenge. The endpoint must return only that plugin’s token: not JSON, not a list, not several tokens from one URL. If multiple plugins share a hostname, do not overwrite an existing token unless the plugin that owns it no longer needs it.
The most common causes are mechanical rather than editorial: annotations that do not match what a tool really does, a demo account a reviewer cannot sign into, tool responses leaking internal identifiers or debug payloads, or a listing whose website and support details do not match the verified publisher identity. Rejections come back with a reason. Fix, rescan the server if the MCP changed, and submit a new version through the same portal.
OpenAI does not publish a service level and states that timelines may vary as it builds and scales the review process. Treat the wait as unknown. The portal tracks status, and the practical move is to keep the endpoint and demo credentials stable throughout rather than iterating on the server while a review is open.
It is strongly advised, and it saves a review cycle. Connect the server to ChatGPT in developer mode and work through direct requests, indirect ones, edge cases and out-of-scope requests. MCP Inspector covers the local pass. Your five positive and three negative test cases fall out of that work rather than being invented at submission time.
Approval does not publish anything. You choose when to publish from the portal, and on publication the plugin appears in the directory shared by ChatGPT and Codex. Later metadata changes follow the same loop: scan the server, submit a new version for review, publish the approved version.
The app is built on an MCP server, so the server is the substance and the listing is the distribution. The same server can back a Claude connector and a Microsoft 365 agent connector. What differs is the review process and the presentation layer, which is why building for one surface and distributing to the rest is the usual sequence.
The other surfaces
Anthropic's portal needs a Team or Enterprise organization before you can submit at all, and treats a missing privacy policy as an immediate rejection.
Microsoft is a manifest change rather than a portal form, with five authentication modes and a choice between static tool definitions and runtime discovery.
Node8 builds the MCP server, gets the annotations, authentication and test cases right the first time, and takes it through review. Most first connectors ship in eight to twelve weeks.