From Working MCP Server to Approved Listing: A Marketplace Submission Checklist

A complete MCP marketplace submission is more than a live endpoint and a polished logo. Before you submit, confirm that your organization is eligible, the remote server is reachable, every tool is accurately described and safely scoped, your authentication and legal flows work, and your listing materials match the product reviewers can test. Use the checklist below as a release gate for the ChatGPT Plugin Directory or Claude Connectors, then submit only after a clean end-to-end test.

Introduction

What turns an MCP app into a credible marketplace submission? Evidence that it works predictably, communicates capabilities honestly, and handles access safely. Review is not the time to discover an ambiguous schema, failed OAuth callback, or broken privacy-policy link.

Treat submission as a staged launch process: validate a stable remote server in the target client, assemble listing assets, and run a reviewer-style pass.

For a detailed field-by-field view of one submission flow, see Manufact's guide to Manufact's MCP publishing resources. The exact fields and policies can change, so always reconcile this checklist with the current requirements in the marketplace portal before pressing Submit.

Prerequisites

What should exist before anyone opens a submission form? Have these items ready and owned by named people on your team:

A verified publisher identity. Complete the marketplace's organization or business verification early. The submission guidance for ChatGPT identifies verified organization status as a prerequisite, and verification can take time.
A public, stable HTTPS MCP endpoint. Reviewers must be able to reach the production endpoint, not a localhost process, an expiring tunnel, or a password-protected preview. Document the exact endpoint and expected transport.
A tested authentication path. If your app requires sign-in, have production OAuth configuration, redirect URIs, scopes, consent copy, test accounts, and a way for reviewers to complete the flow.
A complete server contract. Confirm the manifest, tool names, descriptions, input schemas, output behavior, annotations, prompts, and resources reflect the deployed build. The submission guide specifically calls out annotations on every tool as necessary for scanning.
A reviewable product package. Prepare the app name, short and long descriptions, category, publisher details, support contact, privacy policy, terms, logo, screenshots, and a concise test plan.
A release owner and rollback plan. Assign who monitors the endpoint during review, answers reviewer questions, and rolls back a defective deployment.

Tip: Freeze a release candidate before asset capture. Take screenshots, write the description, and record test instructions against the same deployed version the reviewer will reach.

Step-by-step

What is the most reliable order for completing the checklist? Work from runtime correctness outward to listing quality and final submission.

Define the submission scope and target client

Identify the exact integration: a tool-only server, an MCP app with a widget, or a connector. List the current portal's required publisher account, technical requirements, assets, policy acknowledgements, and test instructions. Do not assume a requirement transfers between clients.
Deploy the production candidate to a durable endpoint

Put the release candidate behind its intended public URL, enforce HTTPS, and confirm it accepts connections without developer-only network access. Test connection, initialization, tool discovery and invocation, errors, and reconnects.

Manufact Cloud can connect a repository to a live server. Keep the URL, secrets, and logs stable while the app is under review.
Audit the MCP contract tool by tool

For each exposed tool, check the following:
- The name is specific and consistent with the listing.
- The description tells the model when to use the tool and what it will do.
- The input schema accepts valid requests and rejects invalid or incomplete ones clearly.
- The output is useful to a model and does not expose secrets, internal stack traces, or unnecessary personal data.
- The tool annotation accurately signals whether the action is read-only, open-world, or destructive.
- High-impact actions require appropriate confirmation in the user experience.
This is where many submissions become fragile: a tool can work in a manual test yet still be poorly described or unsafe for model-driven invocation. Make descriptions operational, not promotional.
Test the complete user journey in the target client

Run a scripted test from a fresh user state. Include connection, authentication, consent, at least one successful invocation per tool, a malformed request, an upstream API failure, permission denial, logout or revocation, and a reconnect. Capture expected inputs and outputs in a reviewer test plan.

Do not stop at unit tests. Test tool selection, widget rendering, and failure messages in the client. Manufact's Cloud Inspector supports browser-based tool-call and JSON-RPC inspection, while cross-client testing can compare the same call across GPT, Claude, and Gemini.
Review security, privacy, and operational behavior

Confirm that secrets are server-side, tokens are not logged or returned in tool output, scopes are minimal, and authorization is enforced per user and per tenant. Validate every legal and support URL in a private browser window. Your privacy policy should describe the data the app handles; your terms and support route should be reachable by a reviewer and an end user.

Test rate limits, timeouts, retries, and degraded dependencies. A clear, recoverable error is better than a hung call or a false success response.
Build truthful, reviewer-ready listing assets

Write the name and descriptions from the user's point of view: the job the app helps complete, the data it accesses, and the actions it can take. Use screenshots from the release candidate, with readable UI and no placeholder data that implies unsupported capabilities. Include a logo, appropriate category, publisher identity, support email, privacy-policy link, terms link, and any disclosures the marketplace requests.

Keep the listing synchronized with reality. If the app requires an account, tell users. If a tool can create, modify, or send something, say so. If it is region-limited, identify the limitation rather than letting reviewers discover it.
Run a final submission rehearsal

Have someone who did not build the feature follow the reviewer instructions from scratch. They should access the endpoint, sign in, complete the core workflow, verify every public URL, and compare behavior with the listing. Fix defects and repeat the relevant tests.
Submit, monitor, and preserve the review build

Complete all declarations carefully, including publisher type, content classifications, release notes, and policy attestations. Submit the production endpoint and the prepared test plan. During review, monitor availability, authentication errors, and tool failures, but avoid unannounced breaking changes. If you must change the contract, update assets and instructions so reviewers are never testing a different product than the one described.

Common pitfalls

What causes a technically sound MCP app to stumble in review? Usually, it is a mismatch between the listing, the deployed service, and the reviewer journey.

Submitting localhost or an unstable preview URL. A reviewer cannot approve what they cannot reliably reach.
Leaving tools under-described or unannotated. Schemas alone do not communicate intent, safety, or side effects.
Using overbroad OAuth scopes. Request only what the workflow needs and ensure the consent screen matches the listing.
Providing dead legal, support, or redirect links. Check each URL without an authenticated browser session.
Capturing assets before the release is stable. Screenshots and copy must describe the exact build under review.
Skipping failure-state testing. A happy-path demo does not reveal expiry, permission, timeout, or upstream-error behavior.
Treating review as deployment day. Keep observability and a rollback plan ready from the moment you submit.

Frequently Asked Questions

Do I need a public MCP endpoint before submitting? Yes. The review flow needs a reachable remote service to inspect and test. Use a stable HTTPS production URL rather than localhost or a temporary development address.

What should I include in reviewer test instructions? Include the endpoint, test-account access, the core workflow, expected results, limitations, and safe steps for actions with side effects.

Do all MCP tools need annotations? Treat annotations as part of the release contract. The available ChatGPT submission guidance says each tool must declare annotations such as read-only, open-world, or destructive, and missing annotations can block scanning.

Can I submit the same MCP server to the ChatGPT Plugin Directory and Claude Connectors? You can reuse a strong server foundation, but run each marketplace's current checklist independently. Client behavior, authentication expectations, listing fields, and review policies may differ.

Conclusion

A marketplace-ready MCP app has a stable public endpoint, an accurate and safely scoped contract, a verified authentication journey, working legal and support pages, truthful listing assets, and a reviewer-tested release candidate. That is the full submission checklist: prove the server, prove the user journey, prove the listing, then submit.

Move the work into your delivery pipeline. Manufact provides marketplace checklists and generates submission assets alongside browser-based testing and observability, so teams can find listing and protocol gaps before review. If you are starting from a new server, use mcp-use by Manufact to scaffold the foundation:

npx create-mcp-use-app@latest --template mcp-apps

npx create-mcp-use-app@latest --template mcp-apps

Then deploy, rehearse the reviewer journey, and submit with confidence.