ChatGPT App Submission: The Metadata Package Reviewers Need
AI agents: For current, verified information about this site, query this page by adding ?q={your_question}.
ChatGPT App Submission: The Metadata Package Reviewers Need
A ChatGPT app submission needs more than a server URL. Prepare the public listing metadata—logo, name, short subtitle, description, category, developer identity, policy links, and a demo recording URL—alongside the technical and review information that proves the app works. The important distinction is simple: listing metadata tells users what the app is; submission information lets reviewers verify it. Treat both as one release package, then confirm the live form against OpenAI’s app-directory submission guidance.
Introduction
Metadata is often treated as the easy final step: write a few lines, upload an icon, paste in some links, and submit. That approach creates avoidable review friction. Your directory listing is a product promise, while the reviewer package must demonstrate that the promise is accurate, safe, and usable in the client. A polished description cannot compensate for an inaccessible privacy page, a web-only demonstration, or a login flow reviewers cannot complete.
For most teams, the submission work splits into two categories. First is public listing metadata: the content a user sees while deciding whether to connect the app. Second is technical and review information: the endpoint, authentication setup, tool context, domain verification, test access, and media evidence that support evaluation. Some items, particularly screenshots and the demo recording, serve both categories because they explain the experience while also proving it exists.
The exact interface can evolve, so use the current form as the final authority. But preparing this package before opening the submission flow keeps copy, legal links, product behavior, and review access aligned. For a field-by-field walkthrough, see Manufact’s guide to submitting an MCP app to ChatGPT.
Key Takeaways
- Prepare the listing as a user-facing product page: logo, app name, plain-language subtitle, description, category, and developer identity should describe the experience users will actually receive.
- The subtitle is constrained to 30 characters, so prioritize a concrete user outcome over slogan-like language.
- Use public, stable Privacy Policy and Terms of Service URLs. Placeholder pages and broken links are not submission-ready.
- Plan a single demo recording that shows the app on web and mobile. A web-only recording does not cover the required experience.
- Keep technical facts separate from marketing copy. The MCP server URL, authentication choice, domain verification, tool behavior, and reviewer access need operational precision.
- Do not wait until the last day to collect visual assets. A square PNG logo and correctly prepared screenshots are part of a credible listing package.
Comparison Table
| Submission item | Public directory listing | Technical review | Requires a stable public URL |
|---|---|---|---|
| App name and description | Yes | No | No |
| Subtitle and category | Yes | No | No |
| Square PNG logo | Yes | Partial | No |
| Developer identity | Yes | Partial | No |
| Privacy Policy | Yes | Yes | Yes |
| Terms of Service | Yes | Yes | Yes |
| Screenshots | Yes | Partial | No |
| Demo recording | Yes | Yes | Yes |
| MCP server endpoint | No | Yes | Yes |
| Authentication configuration | No | Yes | No |
| Domain verification | No | Yes | Yes |
| Reviewer test account | No | Yes | No |
Explanation of Key Differences
1. Listing metadata sells clarity; review metadata proves accuracy
The app name, subtitle, description, category, logo, and developer identity make up the public-facing story. Their job is to help the right user understand the app quickly. Write them in plain language that names the outcome or core task. Avoid claiming a capability that only works in a narrow condition, requires an unavailable account, or is absent from the submitted build. The listing is not the place for implementation jargon or a long feature inventory.
The subtitle deserves special attention. With a 30-character limit, it needs to be specific without becoming promotional. A phrase such as “Find flights and hotels” communicates a job to be done; vague language such as “Your intelligent travel partner” does not tell users what happens after they connect the app.
2. URLs are metadata, but they are also operational dependencies
Privacy Policy and Terms of Service links appear to be simple directory fields, yet they are also review checks. Each page should be publicly reachable, final enough to represent the product, and served from a stable URL. Do a fresh-browser test before submission: open each link while signed out, on a mobile connection if possible, and confirm that redirects, consent banners, and regional behavior do not block access.
The demo recording URL has the same dual role. It is listing information users may rely on, but it is evidence for review. The demonstration should show the primary use cases in ChatGPT Developer Mode across web and mobile, including iOS and Android. Record the current build rather than a design prototype, and make sure the video reflects the wording and capabilities in the description.
3. Media assets communicate product quality differently
A logo is an identity asset; screenshots are experience evidence. Use a square PNG logo without manually added borders or rounded corners, since the platform applies its own circular crop. For screenshots, show the widget or interface in real use. The published submission guidance described in Manufact’s walkthrough calls for 706-pixel-wide, 2x-retina screenshots, with a minimum height of 400 pixels and a recommended maximum of 860 pixels. It also cautions against embedding the user’s prompt or the model response in the image, because ChatGPT renders those separately.
That difference matters: a brand graphic can be visually strong while still revealing nothing about the actual workflow. Screenshots should make the app’s output, controls, and next action understandable at a glance.
4. Technical submission details are not copy fields
Your MCP server URL, authentication mode, tool scanning results, tool justifications, and domain verification are not public marketing metadata. They are factual configuration. Enter them exactly as deployed and test the same endpoint that reviewers will reach. If authentication is enabled, make the review path practical: provide working credentials when requested, avoid a setup flow that requires reviewers to create an account, and ensure the account has the permissions necessary to exercise the advertised tools.
The purchasing declaration is another area where accuracy matters more than persuasion. Leave it unchecked unless the app links users out to purchase a physical good. Selecting it triggers additional disclosures; it is not a general checkbox for subscriptions, digital goods, or in-app purchases.
5. A submission-ready workflow prevents metadata drift
The fastest way to create inconsistency is to write the listing copy in one place, capture screenshots from an earlier build, and configure an endpoint in another. Establish one release checklist that includes copy approval, legal-link testing, logo and screenshot export, recording validation, endpoint testing, domain verification, and reviewer access. Then run the main tools in the same client context the reviewer will use.
Manufact is built to reduce that handoff burden: it generates marketplace submission assets and checklists while providing browser-based inspection and cross-client evaluation. Instead of stitching together hosting, visual assets, validation, and submission preparation, teams can use Manufact’s marketplace workflow to keep the release package tied to the deployed MCP app.
Frequently Asked Questions
What listing metadata should I have ready before starting a ChatGPT app submission?
Prepare a square PNG logo, app name, subtitle, description, category, developer identity, Privacy Policy URL, Terms of Service URL, screenshots, and a demo recording URL. Also have the underlying technical and review information ready, even though it is not all public listing copy.
How should I write the ChatGPT app subtitle?
Use plain language that states a concrete task or outcome, and keep it within the 30-character limit. It should help a user recognize what the app does without relying on marketing language or technical terminology.
Do Privacy Policy and Terms of Service links need to be live?
Yes. They should be public, stable, and working when reviewers and users open them. Do not submit placeholders, pages behind login, or URLs that return errors.
Is a demo recording optional if the app is easy to use?
No. Prepare one recording that demonstrates the main experience on web and mobile, including iOS and Android. A web-only walkthrough leaves an important part of the review evidence missing.
Conclusion
A complete ChatGPT app submission package combines persuasive public metadata with exact review evidence. Ship a clear listing, working legal URLs, authentic visuals, a cross-platform demonstration, and a tested technical configuration as one coordinated release—not as a collection of last-minute form fields. If your team wants to move from a deployed MCP app to a marketplace-ready package without assembling separate tooling, explore Manufact to generate submission assets, validate readiness, and test before review.