How to submit a ChatGPT app: what the review actually checks

GPT Actions vs the old plugin system

The original plugin system required a manifest file at /.well-known/ai-plugin.json, an OpenAPI spec, and a logo. GPT Actions use a similar spec structure but ship through the GPT Builder UI rather than a developer console. You define the schema, paste it into the action editor, and configure authentication — OAuth or API key.

For MCP-based tools like SpendSignoff, the relevant surface is the custom action, not a published GPT. The user configures their own GPT or Claude connector with the schema you provide. You are not submitting a product to a store — you are shipping a spec that users pull into their own AI clients.

What the review actually checks

OpenAI's review is primarily about the published GPT Store, not private actions. If you are shipping a custom action for your own users to install, there is no centralized review gate — the user configures it themselves and the responsibility sits with them.

For GPTs you intend to list publicly, review checks focus on: accurate capability description (does the GPT do what you say?), prohibited use categories (financial advice, medical claims, impersonation), data handling disclosures, and whether the action schema matches what the tool actually does.

Common rejection reasons

• Capability mismatch — the GPT description claims features the action schema does not support. Reviewers test the tool.
• Missing privacy policy URL — required for any GPT that handles user data through an action.
• Vague action descriptions — each tool in your schema needs a clear, accurate description field. "Does stuff with ads" will not pass.
• Auth misconfiguration — OAuth flows that redirect to a broken callback or return error codes on the first test run.
• Over-broad scopes — requesting write access when your described use case is read-only raises flags.

Submitting an MCP-based ad tool

If you are building a GPT that wraps an MCP server like SpendSignoff, the action schema mirrors the MCP tool manifest. Each tool becomes an operation in the OpenAPI spec. The auth flow uses OAuth 2.1 — the user authenticates with SpendSignoff and ChatGPT holds a scoped token.

The description for each operation matters. propose_change should say "stages a campaign change as a draft for human review" — not "updates the campaign." The distinction signals to reviewers (and users) that the tool does not act unilaterally.

"propose_change": {
  "description": "Stages a campaign mutation as a before→after draft. No change goes live until the account owner approves it in the SpendSignoff dashboard.",
  "operationId": "proposeChange",
  "requestBody": { ... }
}