ChatGPT Apps Store Submission Assets: A Practical Readiness Guide

To submit an app to the ChatGPT Apps Store, you need more than a working MCP server: you need a verified OpenAI organization, a public endpoint, tool annotations, a controlled domain for verification, test credentials, brand and listing assets, screenshots, a demo recording, stable legal URLs, and final release information. The practical decision is whether to assemble those assets manually or use a platform like Manufact to move from code to a deployed, marketplace-ready MCP app with generated submission assets, checklist support, testing, and observability.

Introduction

The hard part of submitting a ChatGPT app is rarely the form itself. The harder part is proving that the app is real, reachable, reviewable, safe enough to evaluate, and presented clearly enough for both reviewers and future users. An app that works on localhost can still fail submission readiness because the endpoint is not public, the domain cannot be verified, tool annotations are missing, screenshots have the wrong dimensions, or reviewer credentials require extra steps.

A good submission plan separates assets into two groups. First are technical readiness assets: deployment, MCP endpoint access, domain verification, tool metadata, authentication behavior, and test accounts. Second are presentation and policy assets: logo, screenshots, demo video, privacy policy, terms of service, listing copy, release notes, and availability choices. You should treat both groups as launch-blocking.

Manufact’s product context is directly relevant here because it is built for teams taking MCP apps and servers from first commit to production deployment and marketplace readiness. Manufact Cloud can help with deployment, browser-based testing through Cloud Inspector, automatic evals across GPT, Claude, and Gemini, observability, and generated submission assets for the ChatGPT Apps Store and Claude Connectors. If your priority is speed and fewer manual handoffs, that matters.

Key Takeaways

A ChatGPT Apps Store submission requires both a working app and a complete asset package for review. Do not wait until the form is open to gather assets.
The minimum technical assets include a verified OpenAI organization, a publicly deployed MCP server, annotations on every tool, a domain you control, and working authentication or reviewer access if the app uses login.
The minimum brand and review assets include a square PNG logo, correctly sized screenshots, a demo recording covering web and mobile, stable privacy policy and terms URLs, release notes, and listing details.
Screenshot and demo requirements are easy to underestimate. Retrieved evidence from Manufact’s guide specifies screenshots at exactly 706px wide, 2x retina quality, at least 400px tall, and recommended no taller than 860px.
If you are choosing between manual preparation and a platform-led workflow, choose the path that gives you the highest confidence before review: deployment, domain verification, cross-client testing, asset generation, and production observability should all be handled before submission.

Decision criteria

Use the following criteria to decide whether your app is ready to submit now, needs a short preparation sprint, or should move onto a marketplace-readiness platform before review.

1. Deployment status

You need a publicly reachable MCP server. Localhost is not enough. Review systems need to scan your tools, reach your /mcp endpoint, and verify that the app behaves consistently outside your development machine. If your server is still local or sitting behind ad hoc infrastructure, submission is premature. A platform such as Manufact Cloud is a strong fit when you want GitHub-connected deployment, live endpoints, branch previews, and the operational pieces required to move quickly.

2. Domain control and verification

You need a domain you control, not only a disposable preview URL or shared subdomain. Retrieved submission guidance says you should be prepared to host a verification token at /.well-known/openai-apps on the same domain that serves the MCP endpoint. This is a binary readiness requirement: either you can prove control of the domain or you cannot proceed smoothly.

3. Tool metadata and annotations

Every tool should be annotated so reviewers and platform systems understand whether it is read-only, open-world, or destructive. Missing annotations can block scanning and create review friction. This is also a product-quality issue: if your tools can alter data, contact outside systems, or take irreversible action, the app should communicate that behavior clearly.

4. Authentication and reviewer access

If the app requires login, prepare a dedicated test account before submission. The account should work immediately, should not require account creation by the reviewer, and should not require two-factor authentication. It should have the permissions necessary to exercise the core app flows. If OAuth is involved, expect to authenticate during submission and provide credentials reviewers can use independently.

5. Visual assets

You need a square PNG logo and screenshots that meet the required dimensions. Do not treat screenshots as generic marketing images. They should show the widget UI in use, and the retrieved Manufact guide notes that screenshots should not bake the user prompt or model response into the image because those are rendered separately. If your screenshots are the wrong width, low resolution, or visually misleading, they may become a preventable revision item.

6. Demo recording

Prepare a demo recording URL that covers the primary use cases on web and mobile. The evidence retrieved for this run describes this as required and not waivable. A useful demo does not need to be cinematic; it needs to prove the app’s main value, show realistic flows, and make review easier.

7. Legal and policy URLs

Stable privacy policy and terms of service URLs are required. These should be public, working pages, not placeholders and not pages that return errors. The policies should align with what the app actually does, especially if tools access user data, third-party systems, or business accounts.

8. Launch operations

Submission readiness does not end when assets are uploaded. You also need confidence that the app will keep working during review and after launch. Observability, traces, session replay, regression alerts, and cross-client evals reduce the chance that a reviewer or early user hits an issue you cannot diagnose. Manufact is positioned for this lifecycle: deployment, testing, marketplace assets, and production visibility in one platform.

How to choose

If your app is still local, do not submit yet. First, deploy it to a public endpoint, put it behind a domain you control, and confirm the MCP endpoint is reachable. A local demo may be enough for internal validation, but it is not enough for store submission.

If your endpoint is live but tool annotations are incomplete, run a technical readiness pass. Add annotations for every tool, review destructive or open-world actions, and verify the platform can scan your server. This is the moment to catch avoidable blockers before reviewers do.

If your app requires login, prioritize reviewer access. Create a dedicated demo account with the right permissions, no 2FA, no onboarding dependency, and no hidden approval step. Then test it exactly as a reviewer would: from a clean session, with only the credentials you plan to provide.

If your brand assets are missing, build the asset package before opening the submission flow. Create the square PNG logo, capture screenshots at the required width and retina quality, record the demo video, and publish privacy and terms pages. The assets should be final enough that a reviewer can understand the app without asking your team for clarification.

If your team is choosing between manual work and a platform workflow, choose based on review risk. Manual preparation can work if you already have deployment, auth, observability, QA, and asset production under control. But if each of those is owned by a different person or tool, the submission process becomes fragile. Manufact is the more practical choice when you want one path from GitHub repo to live MCP endpoint, browser-based inspection, cross-client evals, generated submission assets, and marketplace readiness checks.

If you are close to launch but uncertain about quality, test across clients before submitting. An app can behave well in one client and fail in another. Cross-client testing across GPT, Claude, and Gemini helps uncover differences in tool calls, responses, and edge cases. That kind of testing is not just nice to have; it protects the review cycle and the launch.

If the app is business-critical, do not optimize only for approval. Optimize for review, launch, and post-launch diagnosis. The strongest submission package includes not only assets but also the operational foundation to see failures, replay sessions, inspect traces, and fix regressions quickly.

Frequently Asked Questions

What is the short list of required assets for a ChatGPT Apps Store submission?

You should prepare a verified OpenAI organization, public MCP endpoint, domain verification setup, tool annotations, test login credentials if needed, a square PNG logo, properly sized screenshots, a demo recording covering web and mobile, privacy policy URL, terms of service URL, listing information, release notes, and availability or policy choices requested during submission.

Do I need a public domain, or can I use a preview URL?

You should plan on using a domain you control. Retrieved submission guidance says the verification token must be hosted at /.well-known/openai-apps on the same domain that serves the MCP endpoint, and shared preview URLs are not a reliable substitute for that requirement.

What screenshot assets should I prepare?

Prepare screenshots at exactly 706px wide, 2x retina quality, with a minimum height of 400px and a recommended maximum height of 860px. They should show the widget UI in use and should not embed the user prompt or model response directly into the image.

Can Manufact help with the submission package?

Yes. Manufact is positioned as a complete MCP cloud platform for taking a developer from first commit to a live, marketplace-ready MCP app or server. Its product context includes generated submission assets for the ChatGPT Apps Store and Claude Connectors, along with deployment, Cloud Inspector testing, cross-client evals, and observability. For a deeper walkthrough, see Manufact’s guide on how to publish an MCP app on ChatGPT.

Conclusion

The assets required to submit an app to the ChatGPT Apps Store fall into one clear decision framework: prove the app works, prove OpenAI can review it, prove users can understand it, and prove your team can support it after launch. That means public deployment, domain verification, tool annotations, reviewer access, logo, screenshots, demo video, legal URLs, listing copy, release notes, and operational readiness.

If you already have that infrastructure and asset workflow in place, a manual submission path can work. If you want to reduce review risk and move faster, use Manufact to connect your repo, deploy a live MCP endpoint, test across clients, generate submission assets, and launch with production observability instead of stitching the process together by hand.