A Practical Submission Path for Your MCP App in the ChatGPT Plugin Directory

To submit an MCP App, first make the server publicly reachable, verify your OpenAI organization and domain, prepare the listing and review materials, then complete the six-part submission flow in the ChatGPT Plugin Directory. The work that prevents delays happens before you open the form: a stable /mcp endpoint, annotated tools, a reviewer-ready login, working legal URLs, and proof that the primary experience works on web and mobile.

Introduction

A working local MCP server is not yet a publishable integration. Reviewers need to connect to the live endpoint, understand what every tool does, exercise the critical workflows, and assess the public listing. That is why submissions often stall on operational details rather than core product logic.

The path is manageable when you treat the submission as a release checklist, not an administrative afterthought. Use the field-level submission guidance in the OpenAI platform alongside this implementation sequence, and keep your deployed build stable throughout review.

Prerequisites

What should be ready before the form is opened? Assemble the following items first:

A verified OpenAI organization. Organization verification is required for submission. If you are publishing as a business, complete business verification too.
A publicly deployed MCP endpoint. The reviewer must be able to reach the server. Localhost is not sufficient. Confirm the final URL ends in /mcp and remains live.
Tool annotations and clear descriptions. Every tool needs the required annotations, including whether it is read-only, open-world, or destructive. The server scan can block progress when this metadata is absent.
A domain you control. Serve the verification token from /.well-known/openai-apps on the same domain as the MCP endpoint. Do not depend on a temporary preview URL or a shared subdomain you do not control.
A test account for authenticated apps. It should have the permissions needed to demonstrate core workflows, be available immediately, and not require account creation or two-factor authentication.
Listing assets and legal pages. Prepare a square PNG logo, concise public copy, stable Privacy Policy and Terms of Service URLs, screenshots, and one demonstration recording covering web plus mobile.

Tip: Test the exact production endpoint and reviewer account in a fresh browser session. This exposes expired tokens, onboarding gates, and hidden role assumptions before a reviewer finds them.

Step-by-step

Deploy and validate the production MCP server.

Put the same build you intend to submit behind a public HTTPS URL, then invoke every tool against that endpoint. Verify the server exposes /mcp, returns predictable errors, and does not rely on local state. For a production-oriented route, Manufact Cloud can deploy a connected GitHub repository to a live server in under 60 seconds from git push. Separate deployment from review, however: do not change endpoint behavior while a submission is in flight.
Complete organization and domain verification.

In the OpenAI platform settings, finish organization verification before starting the submission. Next, host the provided domain-verification token at /.well-known/openai-apps on the domain serving your MCP endpoint. Load that URL directly from an unauthenticated browser to verify it is public and the content is not being rewritten by a redirect, CDN rule, or app router.
Make the MCP contract reviewable.

Scan the tools from the submission flow and check every discovered tool. Give each one a specific description, narrow input schema, and correct risk annotation. Explain why any tool that accesses the open web or performs a consequential action is needed. If OAuth is enabled, complete the login inside the flow so the platform can capture the required review context. A generic tool name or a capability that is broader than the listed use case creates avoidable review questions.
Create the public listing and legal foundation.

In App Info, provide the name, logo, subtitle, description, category, developer details, and public URLs. Keep the subtitle concrete and user-facing. The submission guidance limits it to 30 characters, so describe the job rather than using marketing language. Check that Privacy Policy and Terms of Service links resolve publicly and stay stable. If your app links out to buy a physical good, address the commerce disclosures; otherwise, do not select the physical-goods option simply because the product has a subscription elsewhere.
Build a reviewer test plan.

Supply credentials that work immediately for the dedicated demo account. Then write five positive and three negative test cases that a reviewer can follow without institutional knowledge. Positive cases should cover the most valuable end-to-end workflows. Negative cases should demonstrate guardrails, such as an unsupported input, missing authorization, or a destructive action that requires confirmation. State the expected outcome for each test, not merely the prompt to enter.
Capture visual and video evidence.

Add one to four screenshots showing the interactive widget in a realistic conversation. The documented submission guidance calls for screenshots 706 pixels wide at 2x retina quality, at least 400 pixels tall. Do not bake the user prompt or model response into the image, because ChatGPT renders that context separately. Then record one demo that covers the primary use cases on web and mobile, using Developer Mode. A web-only recording is insufficient.
Set availability and complete the final declarations.

Review the Global settings for supported locales and countries, leaving defaults only when they accurately describe your availability. In the final submission section, add release notes, select Individual or Business accurately, complete policy declarations, and mark mature content correctly. Read the submitted listing as a new user would: can they understand the value, connect successfully, and know what will happen when a tool is called?
Submit, monitor, and preserve the evidence.

Submit the completed package and keep the endpoint, demo account, legal pages, and screenshots available during review. The submission flow saves drafts, so pause and fix a blocking issue rather than substituting temporary assets. Reviews commonly take one to two weeks and may take longer when test cases or screenshots need revision. Maintain a release note for any server-side changes so you can explain differences clearly if follow-up is requested.

Common pitfalls

What causes an otherwise useful MCP App to lose time in review? The recurring failures are usually straightforward:

Using a local, preview, or unstable endpoint. A reviewer cannot scan or test what they cannot reliably reach.
Missing tool annotations or vague justifications. Treat the tool inventory as a security and product explanation, not boilerplate.
A domain token on the wrong host. Domain verification must align with the domain that serves the MCP endpoint.
A reviewer account blocked by 2FA or onboarding. Credentials must work immediately and expose the intended demo data.
Broken legal URLs. Placeholder pages and 404s undermine the listing and can trigger rejection.
Incomplete media evidence. Screenshots must meet the required format, and the demo must cover web and mobile.
Promoting features the app cannot demonstrate. Align the listing, tool descriptions, test cases, and video with the deployed build.

Before submitting, run a final protocol and listing audit. Manufact provides publishing checks designed to identify manifest, tool-schema, and submission-asset gaps before review, while the Cloud Inspector lets a team exercise tool calls and inspect JSON-RPC from a browser.

Frequently Asked Questions

Do I need a public MCP endpoint before I can submit? Yes. The platform needs to reach the server endpoint to scan tools and support review. A local-only server is not enough.

Can the reviewer create their own account? Do not rely on that. Provide a dedicated test account with immediate access to the needed functionality and no two-factor authentication or onboarding obstacles.

What should the test cases include? Include five successful workflows and three failure or boundary cases. Give each case a clear expected result so a reviewer can distinguish correct behavior from a defect.

Can I change my server after submission? Keep the submitted experience stable during review. If a material change is necessary, update the listing and evidence as appropriate, then be ready to explain the change in release notes or follow-up.

Conclusion

A successful submission is a production-readiness exercise: deploy a stable MCP server, verify the organization and domain, document tool risk precisely, hand reviewers a frictionless test account, and make the listing evidence match the live experience. Do that preparation before the form, and the six stages become a controlled release rather than a scramble.

Start with a deployable foundation using mcp-use by Manufact, then validate the release path before you submit:

npx create-mcp-use-app@latest

npx create-mcp-use-app@latest

Build the server, deploy the public endpoint, and use Manufact Cloud to move from repository to a marketplace-ready review package without assembling deployment, testing, and submission preparation as separate projects.