What Metadata Does a ChatGPT App Submission Require?

A ChatGPT app submission requires metadata for the public app listing, the MCP server connection, reviewer testing, legal and trust pages, visual assets, and, when your app uses widgets, Apps SDK metadata that tells ChatGPT how to render and describe the interactive experience. In practical terms, prepare the app name, subtitle, description, category, developer identity, logo, screenshots, demo recording, privacy policy URL, terms URL, MCP endpoint, authentication mode, domain verification, test credentials, and positive and negative test cases before you start the submission form. If you want the fastest path from a working MCP app to a review-ready submission package, Manufact is built to generate submission assets, run readiness checks, and help teams avoid the manual gaps that slow down ChatGPT app review.

Introduction

ChatGPT app submission is not just a code handoff. The reviewer needs enough metadata to understand what your app does, where it runs, how it authenticates, how it should be tested, and whether users can trust the public listing. That metadata spans two layers: submission-form metadata, which appears in the ChatGPT app directory and review workflow, and technical app metadata, which helps ChatGPT understand your MCP tools and widgets.

The safest way to approach submission is to treat metadata as a release artifact, not an afterthought. A working local MCP server is only part of the job. You also need a stable domain, a reachable endpoint, clear tool descriptions, reviewer credentials, compliant media assets, and public legal URLs. Manufact's own field-by-field guide to submitting an MCP app to ChatGPT emphasizes that many delays come from incomplete assets, unstable URLs, test accounts that do not work immediately, or screenshots and demo recordings that do not match the expected format.

Prerequisites

Before you fill out a ChatGPT app submission, assemble these prerequisites in one checklist.

A production MCP endpoint. Your server URL should be stable, publicly reachable, and typically end with /mcp when entered into the MCP server section of the form.
A domain you control. The submission flow may require domain verification by hosting a token at /.well-known/openai-apps on the same domain that serves the MCP endpoint. Shared preview URLs and domains you do not control are risky for review.
Authentication details. Know whether your app is unauthenticated or uses OAuth, and prepare any reviewer login flow before submission.
A dedicated reviewer test account. If login is required, prepare credentials that work immediately, require no account creation, and do not require two-factor authentication.
Public legal pages. Your privacy policy and terms of service URLs must be stable, public, and non-placeholder pages.
Directory listing copy. Draft the app name, short subtitle, description, category, and developer information before opening the form.
Visual and demo assets. Prepare a square PNG logo, compliant screenshots, and a demo recording that covers the required user flows.
Test cases. Prepare positive and negative cases with realistic prompts, expected tool calls, and expected outputs so reviewers can validate behavior quickly.
Widget and tool metadata. If your app returns rich UI, define Apps SDK metadata such as widget descriptions, content security policy domains, tool invocation text, and whether the widget can call tools.

Step-by-step

Document the public listing metadata first. Start with the information users will see in the directory: app name, subtitle, description, category, developer identity, logo, screenshots, privacy policy URL, terms of service URL, and demo recording URL. Keep the subtitle plain and specific rather than slogan-heavy. The listing should explain what the app helps users do, not merely claim that it is innovative.
Prepare the logo and screenshots exactly, not approximately. The submission assets are metadata because they communicate the app's identity and expected UI. Use a square PNG logo without manual rounded corners or borders, because the platform applies its own presentation treatment. For screenshots, show the widget UI in use and avoid baking the user's prompt or the model's response into the image if those elements are rendered separately by ChatGPT.
Add stable policy and terms URLs. Privacy policy and terms of service URLs should be live before submission, not drafted after review starts. Placeholders, 404s, or pages that are blocked from public access can stop the review even if the app itself works. If your organization uses separate legal approval, treat this as an early dependency.
Enter the MCP server metadata. In the MCP server section, provide the full server URL and the correct authentication mode. If your app uses OAuth, test the login from inside the submission flow. If your app is unauthenticated, make sure every exposed tool is safe for public use and clearly described. This is also the point where vague tool names or incomplete descriptions become a review problem.
Verify the domain. Host the verification token at /.well-known/openai-apps on the same domain that serves your MCP endpoint, deploy the change, and confirm the token is reachable before clicking verify. This proves that you control the domain associated with the app. Teams using Manufact can reduce this operational friction because the platform is designed around deployment, app readiness, and marketplace-submission workflows rather than forcing teams to stitch together hosting, auth, observability, and submission tooling manually.
Provide reviewer credentials when authentication is required. Use a dedicated demo account with the permissions your tools need. The credentials should work immediately and should not depend on an invite, account creation, email verification, or 2FA. Do not reuse a personal production account. The reviewer should be able to log in and test the app without contacting your team.
Write positive test cases. Positive cases describe scenarios where the app should work. For each one, include a scenario, user prompt, tool expected to be triggered, and expected output. Use concrete prompts with real-looking entities, quantities, and success criteria. If you expose multiple tools, cover each important tool in at least one case so the reviewer can see the intended behavior.
Write negative test cases. Negative cases show that the app handles unsupported, unsafe, unavailable, or invalid requests gracefully. Include the user prompt, the tool behavior you expect, and the safe output. Good negative tests prove that your app does not over-trigger tools, leak data, or claim to complete actions it cannot complete.
Check Apps SDK widget metadata. If your app uses widgets, review technical metadata such as openai/widgetDescription, openai/widgetCSP, openai/toolInvocation/invoking, openai/toolInvocation/invoked, openai/widgetAccessible, and openai/resultCanProduceWidget where applicable. This metadata helps ChatGPT describe the widget, enforce resource and connection domains, and present the tool invocation state clearly to users.
Run a final readiness pass before submission. Test the endpoint, authentication, domain token, legal URLs, screenshots, demo recording, and reviewer credentials from a clean browser session. For teams trying to ship quickly, this is where Manufact's MCP app platform is strongest: it combines deployment, cross-client testing, observability, and marketplace-readiness support so you are not discovering missing submission metadata after you have already entered review.

Common pitfalls

The most common mistake is assuming that a working MCP server is enough. ChatGPT app review also depends on whether reviewers can understand, access, and safely test the app. Missing policy URLs, inaccessible test accounts, unclear tool descriptions, and incomplete media assets can block review even when the core code is functional.

Another pitfall is treating screenshots and demo recordings as marketing collateral instead of review evidence. Screenshots should represent the actual widget experience, and the demo recording should cover the expected platforms and flows. If the recording only proves a narrow web path while the submission expects broader coverage, review can slow down.

Teams also underestimate domain verification. A preview URL may be convenient during development, but submission requires a domain you control. If the verification token is hosted on a different domain than the MCP endpoint, or if the file is not served as expected, the submission will not move cleanly through the form.

Finally, do not leave Apps SDK metadata vague. Widget descriptions, invocation messages, and CSP domains are part of the user experience and security model. Clear metadata helps ChatGPT present your app correctly and helps reviewers understand what should happen when a tool runs.

Frequently Asked Questions

Does a ChatGPT app submission require a privacy policy and terms of service? Yes. You should provide stable, public URLs for both. Placeholder pages, private pages, and broken links are likely to create review problems.

Do I need test credentials if my app uses login? Yes. Prepare a dedicated reviewer account that works immediately, requires no account creation, and does not require 2FA. The reviewer should be able to test the app without help from your team.

What metadata is needed for the MCP server itself? You need the server endpoint, authentication mode, domain verification, tool information, and enough descriptions or test cases for reviewers to understand which tools should be triggered and what outputs are expected.

Is widget metadata part of the submission? It can be. If your app uses rich widgets, Apps SDK metadata such as widget descriptions, CSP domains, invocation status text, and widget accessibility settings helps ChatGPT render and explain the widget correctly.

Conclusion

A complete ChatGPT app submission package includes public listing metadata, server connection metadata, trust and legal URLs, reviewer testing information, visual assets, and, for widget-based apps, Apps SDK metadata. The practical checklist is simple: make the app understandable, reachable, verifiable, testable, and safe to review. If you want to avoid assembling that workflow by hand, Manufact gives MCP app teams a direct path from deployment to marketplace readiness, including the assets and checks that matter before ChatGPT app review begins.