Publication rules and review

Lesson rewritten on November 3, 2026 based on OpenAI’s Plugin Guidelines and Remote MCP Server Review Requirements. The previous version described rules for a “ChatGPT Store” with technical thresholds and timelines that lacked sources. Sources: Plugin Guidelines · Review Requirements.

A common foundation for all plugins

OpenAI’s rules set the minimum bar a plugin must meet to remain in the directory shared by ChatGPT and Codex. These apply to everyone, including plugins built from skills; specific requirements for MCP servers, tools, and interfaces are added when the plugin contains them. Plugins that demonstrate high real-world utility and strong user satisfaction may benefit from enhanced distribution—such as featuring or proactive suggestions—but few qualify upon publication, and you cannot request this status.

Purpose and originality. A plugin must serve a clear objective, deliver on its promises, and provide functionality that products do not offer natively. Do not use intellectual property you do not own, do not imitate others, do not spam, do not create static pages without real interaction, and do not imply that your plugin is an official OpenAI product.

Quality. Behavior must be predictable and reliable, results must be accurate, and errors must be handled with clear messages. Trial or demonstration plugins are not accepted.

Name, description, and prompts. Use precise names—no isolated dictionary words unrelated to your brand, and no suffixes like “MCP,” “MCP Server,” or “Plugin” attached to a product name. Descriptions should explain functionality without comparisons, disparagement, unverifiable claims, or mentions of pricing, subscriptions, free trials, or promotions. The directory no longer displays screenshots; instead, it uses example prompts to help users get started.

Security and user respect

• Usage policies. Nothing prohibited by OpenAI’s usage policies is allowed; an approved plugin found in violation later can be removed.
• Audience. A plugin must be suitable for a general audience, including teenagers aged 13 to 17, and cannot explicitly target children under 13.
• User intent. Respond to the request without irrelevant content, without hijacking the conversation, and without collecting more data than necessary. Plugin or tool metadata must not seek secrets, order unauthorized transfers or actions, bypass platform safeguards, or conceal behavior—including encoded or masked instructions.
• Fair play. No field readable by the model should attempt to influence the selection of other plugins, such as asking the model to prefer yours.
• Third-party content. Do not scrape websites or call third-party APIs without authorization; do not use unofficial connectors to third-party services; do not bypass third-party limits or access controls.

Privacy

Every submission must include a published privacy policy that specifies, at minimum, the categories of personal data collected, their purposes, the categories of recipients, retention periods, and available control mechanisms. Collect only what is strictly necessary. Certain data is prohibited: information subject to PCI DSS standards, protected health information, official identifiers like social security numbers, and access credentials—API keys, one-time codes, passwords. Sensitive data under local law may only be collected if strictly necessary, with valid consent and visible notice at the time of collection. No undisclosed surveillance, tracking, or profiling is allowed.

Specific requirements for MCP tools

• Clear and unique names, preferably a verb describing the action (get_order_status), without promotional terms (best, official) or internal jargon.
• Descriptions that match behavior, non-empty, stating the purpose, when to use it, limitations, and side effects; a vague description alone can cause rejection.
• Independent tools. A tool must not invoke another plugin to do its work, and every operation callable by the model must be exposed as a distinct tool—no generic executor that discovers operations not submitted for review.
• Explicit annotations: readOnlyHint, destructiveHint, and openWorldHint with boolean values in each tool. Writing that sends a message, publishes, uploads, or starts processing is not read-only; deletion, overwriting, cancellation, revocation, or irreversible sending is destructive—and the ability to undo an action does not make it non-destructive. Annotation justifications are no longer required; an automated flag can be appealed.
• Minimal inputs. No conversation history, raw transcripts, or “just in case” fields; no precise location—rely on the approximate location provided by the system.
• Minimal responses, without diagnostics, telemetry, or internal identifiers (session, trace, request) unless strictly necessary.
• Predictable behavior: no hidden side effects, and tools that can be replayed safely, or that clearly signal that a retry would repeat the effect.

Authentication, interface, and testing

If the server requires login, the flow must be seamless and request only necessary permissions. An interface may embed pages from the registrable domain of its MCP server—a server on api.example.com can embed app.example.com—declared in _meta.ui.csp.frameDomains and justified during submission; two tenants on the same host count as different domains. The plugin must work reliably in ChatGPT on both desktop and mobile. For an authenticated server, provide a complete demo account with sample data: a plugin that requires registration or inaccessible two-factor authentication for reviewers will be rejected.

Before submitting

• Identity verification in your organization settings on the OpenAI platform: individual verification to publish under your name, business verification to publish under a trade name. Publishing under an unverified name results in rejection.
• Permissions: Organization owners can submit; other members need the application management right, assignable by an owner.
• Remote server on a public domain, with no local endpoints or test environments.
• Accurate and up-to-date support contact information.

How the review works

The submitted plugin enters a review queue; its status is visible in the dashboard, and every change is notified by email. OpenAI may conduct automated scans and manual reviews. Upon approval, you choose the publication time. In case of rejection or removal related to the server, tools, or interface, you receive a list of failed checks; fix them, then resubmit. To appeal, reply to the decision email with clear reasoning and new evidence.

Continuous review after publication

Your server metadata is a versioned API contract. Upon submission, OpenAI records what it discovers; after publication, it regularly queries your server and compares tools against those published:

• a deleted tool disappears from the published list as soon as the scan detects it;
• a new tool becomes available after passing automated checks;
• a modified tool retains its previous definition until the new one passes these checks.

Each tool is evaluated independently. Your server must therefore remain compatible with the live definition while an update is pending: OpenAI retains the definition, not a copy of your code.

Key takeaways

• A useful, reliable, original plugin, honest in name and description, without advertising
• Mandatory privacy policy, minimal collection, prohibited data (PCI, health, official IDs, secrets)
• Tools: clear names, compliant descriptions, explicit boolean annotations, minimal inputs and responses
• Verified identity, complete demo account, works on desktop and mobile
• After publication, tools are continuously re-analyzed, one by one