--- title: "How to Publish a ChatGPT App Built on MCP: The 9-Step Runbook We Used" author: "Roey Granot" category: "Under the Hood" date: 2026-10-01T11:52:57.302Z canonical: "https://contentagents.dev/blog/how-to-publish-a-chatgpt-app" --- # How to Publish a ChatGPT App Built on MCP: The 9-Step Runbook We Used ![Developer desk at dusk with two glowing monitors showing terminal output](https://hsppuvezyxmkpzkgfkho.supabase.co/storage/v1/object/public/media/enrichment/024a6468-4c4c-4195-b8c2-21b4170617d4/c350e603-ef9c-4249-b3f5-7fd71674676c/ed67bffa-e9c9-4a22-bee0-25cd7d888b57.jpg) Publishing a ChatGPT app built on MCP (Model Context Protocol) has more moving parts than most developers expect. This runbook covers every step from server validation to post-launch monitoring, written for developers who have already built an MCP server and want to get it into OpenAI's marketplace without unnecessary back-and-forth. ## Step 1: Validate Your MCP Server Meets OpenAI's Requirements Your MCP server must expose a working protocol before you touch the publishing pipeline. Validation is not a formality - OpenAI's automated tests run against your endpoint during review, and a server that fails those tests gets rejected without human escalation. Catching failures here costs you an afternoon. Catching them at submission costs you a week. A common pattern: a team builds an MCP server, tests it manually with happy-path requests, and submits to OpenAI. The rejection comes back flagged for missing error handling. The server was returning 200 OK on malformed input instead of a structured error response. The trigger was OpenAI's automated test suite sending edge-case requests the team had never tried. The fix was adding proper error handling and resubmitting - but that added five days to the timeline. OpenAI's automated tests check five things. Protocol compliance means your server speaks MCP correctly - correct headers, correct message format, correct response structure. Timeout behavior means your server responds within the documented window; requests that hang get flagged. Authentication method means your server correctly validates or rejects credentials. Rate limiting means your server handles burst traffic without falling over. Error response format means your errors return structured JSON with the right fields, not bare HTTP error codes. ### What this means in practice - Run MCP Inspector against your server before anything else - it catches protocol compliance issues in under five minutes. - Use curl to send malformed requests manually and verify your error responses match OpenAI's expected format. - Simulate timeout conditions by adding artificial delay to your server and confirming it handles the case gracefully. - Test authentication rejection explicitly - send a request with a bad token and confirm the server returns the right error code. - Document every check you ran and what the output was. You'll want this when responding to review feedback. ## Step 2: Set Up Your OpenAI Developer Account and API Keys You need an OpenAI developer account, billing enabled, and a scoped API key before you can touch the publishing dashboard. Account setup is the foundation - without it, you cannot submit, monitor, or update your app. Getting this wrong early creates access problems that surface at the worst moments. The account hierarchy matters: organization at the top, projects underneath, API keys scoped to each project. Scoped keys are not bureaucracy - they're blast radius control. If one key leaks, you revoke that key. Your other projects keep running. A single organization-wide key means a single leak can take down everything. A developer uses a personal API key for testing, works fast, commits the key to a public GitHub repo by accident. GitHub's secret scanning catches it and OpenAI auto-revokes the key within minutes. The trigger is the public commit. The consequence is the developer has to rotate the key mid-development, update every environment that was using it, and audit logs to confirm no unauthorized usage. The fix takes two hours. The prevention takes two minutes. ### What this means in practice - Create a dedicated project in your OpenAI organization for this app - do not use your personal or default project. - Generate a scoped API key for the project. Never use your organization master key. - Store keys in environment variables or a secrets manager. Never hardcode them. Never commit them. - Verify billing is active and set a spending limit before testing. Runaway requests during development can generate unexpected charges. - Enable usage alerts in the OpenAI dashboard so you see anomalies before they become problems. ## Step 3: Build and Test Your MCP Server Locally ![](https://hsppuvezyxmkpzkgfkho.supabase.co/storage/v1/object/public/media/enrichment/024a6468-4c4c-4195-b8c2-21b4170617d4/c350e603-ef9c-4249-b3f5-7fd71674676c/9f6afdda-9750-47a5-a964-ca35bec37d2b.png) Testing your MCP server locally before submission catches the majority of integration bugs in an environment where fixing them takes minutes, not days. Local testing is not optional - it's the difference between a clean first submission and a feedback loop that stretches across weeks. The local testing loop is straightforward. Run your server, connect a test client, send sample requests, inspect the responses, fix what's broken, repeat. Keep each iteration tight - the goal is to exhaust your error cases before OpenAI's tests do. A team builds an MCP server for a database query tool. They test it with ten sample queries covering their most common use cases. One query type - a nested filter - returns malformed JSON. The bug was a missing serialization step. They catch it locally, fix it in an hour, and run the full test suite again before touching the submission form. That's the process working correctly. ### What this means in practice - Use Postman or a dedicated MCP test harness to send structured requests against your local server. - Build a set of sample requests that cover your happy path, edge cases, and known failure modes. - Log every response during local testing - structured logs make it easier to spot patterns in failures. - Test with concurrent requests, not just sequential ones. Race conditions rarely show up in single-threaded tests. - Run your local test suite as a pre-commit hook so it's impossible to push broken server code. ## Step 4: Write Clear Documentation for Your MCP Server Your documentation must explain what your server does, how to authenticate, what inputs it accepts, and what outputs it returns - before OpenAI's reviewers ask. Good docs accelerate approval. Vague docs generate feedback rounds that each cost three to five days. MCP server documentation needs six things: a purpose statement (one sentence on what the server does), supported methods, input schemas with field types and constraints, output schemas with example payloads, error codes with descriptions, and authentication flow. Each section should be scannable in under thirty seconds. A team submits with docs that say "handles queries." Review comes back asking for schema clarification. They rewrite with full input/output schemas and example payloads. The second submission goes through. The rewrite took four hours. Writing it correctly the first time would have taken the same four hours and saved a week of waiting. ### What this means in practice - Structure your docs as README plus API reference. The README covers purpose and authentication. The API reference covers every method with examples. - Host your docs somewhere stable - GitHub Pages or a dedicated docs site. Notion works but check that the link is publicly accessible. - Include at least one complete worked example per method: input, expected output, and error case. - Version your docs. When you update your server, update the docs in the same commit. - Have someone who didn't build the server read the docs before you submit. If they have questions, OpenAI's reviewers will have the same questions. ## Step 5: Deploy Your MCP Server to a Stable Endpoint Before diving into the runbook steps, seeing the full build process in action can sharpen your mental model of how the pieces fit together. Ahmed Mukhtar walks through constructing an app directly inside ChatGPT using the OpenAI Apps SDK and MCP UI, which maps closely to the architecture this article assumes you already have in place. Watching it alongside the runbook is especially helpful if you're still getting comfortable with how the SDK and MCP layer interact before you push to publish. Your MCP server must run on a public URL that stays online through OpenAI's review tests and beyond. Stable means 99.9% uptime minimum, not "usually up." Review tests hit your endpoint on their schedule, not yours - a server that's down when the test runs is a submission that fails. For most teams, the practical choice is a managed cloud platform with a fixed endpoint. AWS (Elastic Beanstalk or ECS), Google Cloud Run, and Railway all work. Docker containers on any of these give you reproducible deployments. Avoid free-tier platforms with auto-sleep behavior - they're the single most common cause of review failures that weren't actually bugs. A team deploys to a free-tier platform. OpenAI's review tests hit the endpoint while the platform is spinning up from a cold start. The requests time out. The submission is rejected for timeout behavior - but the server code was fine. They move to a paid tier with no auto-sleep, redeploy, resubmit. The delay cost them ten days for a problem that had nothing to do with their code. ### What this means in practice - Use a platform with a persistent process - no auto-sleep, no cold starts. Pay for the tier that guarantees it. - Set up a health check endpoint that returns 200 OK with a response time under 500ms. OpenAI's tests will use it. - Configure uptime monitoring with Uptime Robot or Better Uptime. Get alerted within one minute of downtime. - Test your deployment by hitting the public endpoint from outside your network before submitting. - Set up deployment rollback so a bad update doesn't take down your live server during review. ## Step 6: Create Your App Listing on the OpenAI Platform Your app listing is how users find and install your MCP server. A weak listing means low adoption even after approval. The copy, icon, and category you choose determine whether users click through or scroll past - and they matter more than most developers expect. A listing needs five things: a short description (one sentence, specific), a long description (two to three sentences on what the server does and who it's for), a square icon at 512px minimum, a category that matches your use case, and working links to your docs, support channel, and privacy policy. Every field has to be filled. Missing fields block submission. A team publishes with the description "database tool." Adoption is low for two weeks. They rewrite to "Query your PostgreSQL database in plain English - get results back in under two seconds." Install rate improves materially. The description change took thirty minutes. The lesson is that specificity beats generality every time. ### What this means in practice - Write your short description as a specific outcome, not a feature: "what does the user get" not "what does the server do." - Test how your listing reads on a small screen. Mobile users see the short description only. - Use an icon that's readable at 64px - many listing views shrink it significantly. - Check that your privacy policy URL actually loads. A dead link here blocks submission. - Pick the most specific category available. Broad categories increase competition; specific ones increase relevance. ## Step 7: Submit Your App for OpenAI Review You submit your app through OpenAI's developer dashboard. Review typically takes three to seven business days for a first submission. Automated tests run within hours. Human review follows. Knowing the sequence helps you interpret feedback correctly when it arrives. Before you hit submit, run through the checklist: all listing fields filled, docs link returning a 200, server endpoint responding under 500ms, icon uploaded at correct dimensions, and terms accepted. A failed checklist item blocks submission before it reaches review. A team submits. OpenAI's automated tests find the server doesn't handle concurrent requests correctly - under load, two simultaneous requests produce conflicting state and one returns a corrupted response. The rejection comes with a specific error trace. The fix is adding request isolation. They fix it locally, verify with a concurrency test, and resubmit. ### What this means in practice - Screenshot your submission confirmation. You'll want the submission ID if you need to follow up. - Check your developer dashboard daily during review. Status updates appear there first. - Do not push changes to your server endpoint during review. If the endpoint changes, the tests that are already running against it may fail. - When feedback arrives, read the full message before responding. Automated feedback often includes error traces that point directly to the failing code path. - Respond to feedback within 48 hours. Slow responses extend the review cycle. ## Step 8: Address Review Feedback and Resubmit if Needed ![](https://hsppuvezyxmkpzkgfkho.supabase.co/storage/v1/object/public/media/enrichment/024a6468-4c4c-4195-b8c2-21b4170617d4/c350e603-ef9c-4249-b3f5-7fd71674676c/da9df47c-7e6f-4486-926a-61a41fbd12cf.png) Most first submissions get feedback. OpenAI might ask for better error handling, clearer documentation, or a security fix. This is normal - treat it as a structured code review, not a rejection. Every feedback item is fixable. Feedback falls into three categories. Security covers authentication gaps, rate limiting failures, and input validation. Functionality covers edge cases your server doesn't handle - malformed input, concurrent requests, timeout behavior. Documentation covers missing schemas, unclear examples, or absent error codes. Each category has a known fix pattern. A team gets feedback that their server doesn't validate input, leaving it open to injection attacks. They add input validation with a sanitization library, update their docs to describe the validation logic, test the fix locally with adversarial inputs, and draft a resubmission message that explains exactly what changed and why. The second submission is approved. ### What this means in practice - Map each piece of feedback to a specific file and line before you start fixing. Don't guess at the scope. - Fix everything in the feedback before resubmitting. Partial fixes generate a second feedback round. Test every fix locally against the specific scenario described in the feedback. ## FAQ ### How long does OpenAI take to review a ChatGPT MCP app submission? Review typically takes three to seven business days for a first submission. Automated tests run within hours of submission, and human review follows after that. If your submission receives feedback, responding within 48 hours helps avoid extending the review cycle further. ### Why do MCP server submissions get rejected for timeout errors even when the server code is fine? A common cause is deploying to a free-tier platform with auto-sleep behavior. When OpenAI's review tests hit your endpoint during a cold start, requests time out and the submission is flagged for timeout behavior - even though the underlying server code has no bugs. The fix is using a paid hosting tier with a persistent process and no auto-sleep, such as AWS, Google Cloud Run, or Railway. ### What does OpenAI's automated test suite actually check during MCP app review? The automated tests check five things: protocol compliance (correct headers, message format, and response structure), timeout behavior (your server responds within the documented window), authentication method (credentials are correctly validated or rejected), rate limiting (the server handles burst traffic without failing), and error response format (errors return structured JSON with the right fields, not bare HTTP error codes). ### What should MCP server documentation include to avoid feedback rounds during review? Your documentation needs six things: a one-sentence purpose statement, a list of supported methods, input schemas with field types and constraints, output schemas with example payloads, error codes with descriptions, and the authentication flow. Structure it as a README covering purpose and authentication plus a separate API reference covering every method with worked examples. Each section should be scannable in under thirty seconds. ### How should you handle API keys when building and publishing an MCP app on OpenAI? Create a dedicated project in your OpenAI organization for the app and generate a scoped API key for that project only - never use your organization master key. Store keys in environment variables or a secrets manager and never hardcode or commit them. Also set a spending limit and enable usage alerts in the OpenAI dashboard before you start testing, so unexpected charges or anomalies are visible early. --- Source: https://contentagents.dev/blog/how-to-publish-a-chatgpt-app