How to Publish a ChatGPT App Built on MCP: The 9-Step Runbook We Used

This is the 9-step runbook we used to publish a ChatGPT app built on MCP - from local server to live in the ChatGPT store. If you are building a tool that connects ChatGPT to external services and want to ship it properly, this is what the process actually looks like.

This guide assumes you are a technical founder or developer who has already built something and wants to get it in front of users through the ChatGPT store. It does not assume you have done this before.

Step 1: Deploy Your MCP Endpoint Before You Do Anything Else

MCP (Model Context Protocol) is OpenAI's standard for connecting external tools to ChatGPT. Before you configure anything in the ChatGPT builder, your server needs to be live at a public URL and responding correctly. Everything else in this process depends on that being true first.

For Content Agents, our MCP server exposes seven tools that ChatGPT can call: check_ai_readiness, generate_llms_txt, write_seo_brief, plan_content, score_headline, extract_brand_voice, and check_social_preview. Each tool has a name, a description ChatGPT reads to decide when to call it, and a defined input/output schema.

Once your server is deployed, verify it is responding with this curl command:

curl -X POST https://your-mcp-server.com/tools/list \
  -H "Content-Type: application/json" \
  -d '{}'

You should get back a JSON list of your tools. If you get an error or an empty response, stop. Do not move to step 2 until this returns the correct payload.

What this means in practice

• Run the tools/list curl command and confirm every tool appears with the correct name and description.

• Test a live tool call with a real input - not a mock - before moving forward.

• If your server is behind authentication, make sure it accepts OpenAI's requests. Misconfigured auth is the most common reason MCP servers appear broken in later steps.

• Use structured logging from the start. You will want to see exactly what ChatGPT sends when something goes wrong.

Step 2: Test in ChatGPT Developer Mode Before Submitting

The ChatGPT builder lets you test your MCP integration before submitting to the store. Use it. Testing in developer mode shows you what ChatGPT actually does with your tools - which ones it calls, what inputs it sends, and whether the responses make sense to a user.

We ran two sets of test cases: positive cases that should work, and negative cases that should fail gracefully. Both matter. A tool that crashes on bad input is a rejected submission.

Positive case example: "Can ChatGPT read my website stripe.com?" - this should trigger check_ai_readiness and return a structured assessment. Negative case example: passing a malformed URL to the same tool - the handler should return a clear error message, not a 500.

Watch the server logs while you run these tests. ChatGPT's behavior in the builder is very close to production behavior. If a tool is never called during testing, the description is probably not clear enough for ChatGPT to know when to use it.

What this means in practice

• Write out your positive and negative test cases before you open the builder. Having them written down keeps you systematic.

• If ChatGPT calls the wrong tool, rewrite the tool description - not the code. The description is what ChatGPT reads to decide which tool fits the request.

• Error responses from your handlers should be plain English. ChatGPT surfaces them directly to users.

• Do not submit until every test case behaves as expected. Reviewer testing is not forgiving of obvious failures.

Step 3: Verify Your Organisation as a Business in the OpenAI Developer Portal

OpenAI requires business verification before you can publish to the ChatGPT store. This is not optional and it takes time - account for it in your timeline. The process involves submitting business documentation through the OpenAI developer portal, and approval is not instant.

Start this step early. We made the mistake of treating it as a formality and it added days to our timeline. The verification portal asks for legal entity name, registered address, and supporting documents. Have these ready before you begin.

Once verified, your organisation gains access to the store submission flow. Unverified accounts can still build and test apps, but the submission button stays locked.

What this means in practice

• Check your organisation's verification status in the OpenAI developer portal before you start building. If it is not verified, start the process now.

• Keep your legal entity documents accessible - registered company name, address, and any government-issued business registration.

• If you are a solo founder operating as an individual, check OpenAI's current policy on individual publishers. Requirements can change.

Step 4: Upload Your MCP Configuration to OpenAI

Once your organisation is verified, you upload your MCP server configuration - the schema that tells OpenAI what your app can do, where the server lives, and how to authenticate calls to it. This is separate from the ChatGPT builder configuration. Think of it as registering your server with OpenAI at the platform level.

The configuration includes your server URL, your tool definitions, and any authentication headers OpenAI should include when calling your server. Double-check the tool schemas here against what your server actually returns. A mismatch between the registered schema and the live server behavior is a common rejection reason.

For Content Agents, our seven tools are registered with explicit input validation rules. ChatGPT will not call a tool with inputs that do not match the schema. This is a feature, not a constraint - it means your handlers can trust the inputs they receive.

What this means in practice

• Validate your schema JSON before uploading. A syntax error here fails silently in some cases and loudly in others.

• Every tool description should explain when to use the tool, not just what it does. ChatGPT decides based on context.

• If you update your server later, update the registered schema to match. A stale schema causes tool calls to fail.

Step 5: Verify Your Domain via the /.well-known/ Path

OpenAI requires you to prove you own the domain your MCP server runs on. The verification method is a token file served at a specific path: /.well-known/openai-apps-challenge. OpenAI provides the token string in the developer portal and checks that it is accessible at that URL.

This is a one-time step per domain. Serve the token as plain text, not JSON. Some hosting platforms redirect /.well-known/ paths by default - check your routing configuration if the verification check fails.

Once domain verification passes, it does not need to be repeated unless you move to a different domain. Keep the file in place even after verification. Removing it can cause issues during re-review if OpenAI rechecks the domain later.

What this means in practice

• Confirm the token file is accessible with a browser or curl before triggering the verification check in the portal.

• The file must return a 200 status code. A redirect (301 or 302) fails verification even if the destination serves the correct content.

• Add the token file to your deployment pipeline so it survives future deploys. Losing it mid-review is an avoidable problem.

Step 6: Fill Out the Store Listing Details

The store listing is what users and reviewers see before they install your app. A weak listing is a rejection risk and a conversion killer. Spend real time on this. The description, use cases, and icon all affect whether a user trusts the app enough to try it.

Your description should do two things: explain what the app does in one sentence, then list three to five specific use cases. Reviewers check that the app actually does what the description claims. Users read it to decide if it is relevant to their problem. Write for both audiences.

For Content Agents, the listing describes what each major tool does and who it is for. We kept the language concrete - no claims about being "the best" or "the only" tool. Reviewers flag superlatives. Users distrust them.

What this means in practice

• One sentence description: state the job the app does, not the technology it uses.

• List use cases that match your actual test cases from step 2. Consistency between the listing and the live app matters.

• Your icon should be square, clean, and recognizable at small sizes. The store displays it small. Test it at 64x64 pixels.

• Category selection affects discoverability. Pick the most specific category that fits, not the broadest.

Step 7: Write Your Privacy Page Before the Review Clock Starts

The ChatGPT store requires a public privacy policy linked from your listing. OpenAI reviewers check it. Users read it when they are deciding whether to trust your app with their data. A missing or vague privacy policy is an automatic rejection.

Your privacy page needs to disclose: what data your app collects, how it is stored, how long it is retained, and who it is shared with. If your MCP server logs tool call inputs and outputs - and it should, for debugging - say so. If you do not sell data to third parties, say that explicitly.

You do not need a lawyer for a basic privacy policy, but you do need to be honest. Template generators exist and are fine as a starting point. Edit them to reflect what your app actually does - a template that says you collect email addresses when your app does not is worse than writing from scratch.

What this means in practice

• The privacy policy must be on a public URL that does not require a login to access. Reviewers will not create an account to read it.

• Cover server logs explicitly. Reviewers know MCP servers log data and will look for this disclosure.

• Include a contact email for privacy requests. This is a legal requirement in many jurisdictions and a reviewer checkpoint.

Step 8: Prepare and Submit Your Review Pack

Before you hit submit, assemble everything the reviewer will need to test your app. This includes a test account for any external service your app connects to, step-by-step instructions for reproducing the core use cases, and notes on anything unusual about your setup.

We submitted a short document with three things: the primary use case with exact prompts to try, credentials for a sandbox account in our system, and a note explaining why one tool requires an authenticated session. Reviewers are not developers. They are testing compliance, not debugging code. Make it easy for them.

The submission form in the ChatGPT builder has a notes field. Use it. A reviewer who understands your app approves it faster than one who has to guess how it works.

What this means in practice

• Include exact prompts that trigger each major tool. Do not assume the reviewer will discover them.

• If your app requires external credentials to function, provide a sandbox account. Do not provide production credentials.

• Review OpenAI's usage policies before submitting. Rejections for policy violations take longer to resolve than technical rejections.

• Expect the first review to take up to 48 hours. Plan your launch date around that, not around the submission date.

Step 9: Launch, Log Everything, and Iterate Fast

Once the app is live, your job shifts from building to operating. Users will find edge cases you did not anticipate. Tool calls will fail in ways that worked fine in testing. Monitoring is not optional - it is how you keep the app working.

Set up structured logging on your MCP server from day one. Every tool call should log the tool name, the input, the output, and the latency. When something breaks, logs are the only way to understand what happened. Add UTM tracking to any links your app surfaces - utm_source=chatgpt - so you can separate ChatGPT-driven traffic in your analytics from other sources.

Watch retention, not installs. Five hundred installs with fifty active users after two weeks is a signal to investigate, not celebrate. Check your logs for error patterns. Check your description against what users are actually trying to do. The gap between those two things is usually where retention dies.

For more on how AI agents read and assess your site - which affects how well tools like