# Publish an MCP Server to ChatGPT: Directory Submission How to get an MCP-based app listed in the ChatGPT directory: identity verification, the .well-known domain challenge, tool annotations, the eight-step portal, required test cases, and why submissions get rejected. Source: https://node8.ai/mcp-platforms/chatgpt/ --- [MCP Distribution](https://node8.ai/mcp-platforms/) · ChatGPT # Publishing an MCP server to 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. Talk through a submission [Why submissions fail](#rejections) The shape of it ## Two gates, not one 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](https://node8.ai/state-of-chatgpt-apps) covers what got listed, who publishes it, and how concentrated the categories are. Before the portal ## Six things to settle first ### Verified identity, individual or business 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. ### Apps Management set to Write 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. ### A stable public HTTPS endpoint 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. ### Control of the DNS for the challenge 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. ### A demo account a reviewer can actually use 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. ### Tool annotations on every tool 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 ## Create plugin, with MCP 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. ### 1\. Info The public listing: name, descriptions, developer identity, logo, category, and public website, support, privacy and terms URLs. ### 2\. MCP 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. ### 3\. Tool annotations Set readOnlyHint, openWorldHint and destructiveHint on every discovered tool. ### 4\. Skills Upload skills, or let them import from MCP when you scan tools. ### 5\. Prompts Starter prompts showing the highest-value workflows: specific enough to show when to use the app, general enough to adapt. ### 6\. Testing 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. ### 7\. Global Countries and regions where the app is available. ### 8\. Submit 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 ## What reviewers check, and what fails 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 ## ChatGPT submission questions What does domain verification actually involve? 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. Why was our ChatGPT submission rejected? 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. How long does OpenAI review take? 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. Do we have to test in developer mode first? 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. What happens after approval? 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. Is a ChatGPT app the same as an MCP server? 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 ## Same server, different reviewers ### [Publishing to Claude](https://node8.ai/mcp-platforms/claude/) 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. ### [Publishing to Microsoft 365 Copilot](https://node8.ai/mcp-platforms/copilot/) Microsoft is a manifest change rather than a portal form, with five authentication modes and a choice between static tool definitions and runtime discovery. [Compare all four surfaces](https://node8.ai/mcp-platforms/) [ChatGPT app development](https://node8.ai/chatgpt-app-development) [Every listed ChatGPT app](https://node8.ai/ai-connectors/chatgpt/) ## Want the submission handled, not explained? 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. [ChatGPT app development](https://node8.ai/chatgpt-app-development) Book a strategy session