Primary navigation

Plugin guidelines

Requirements for MCP servers and optional UI in published plugins.

These guidelines cover the MCP server and optional UI in a plugin. For the complete submission flow, including skills, portal steps, review, approval, and publishing, see Submit plugins.

Overview

The plugin ecosystem is built on trust. People come to ChatGPT and Codex expecting experiences that are safe, useful, and respectful of their privacy. Developers expect a fair and transparent process. These developer guidelines set the policies every builder is expected to review and follow.

Before getting into specifics, review the optional UI guidelines for interaction, layout, and design patterns that help plugin UI feel intuitive, trustworthy, and consistent within ChatGPT.

You can also read the principles in what makes a great experience in ChatGPT.

The guidelines below outline the minimum standard a published plugin must meet to remain available in the universal directory shared by ChatGPT and Codex. Plugins that demonstrate strong real-world utility and high user satisfaction may be eligible for enhanced distribution opportunities, such as directory placement or proactive suggestions.

Plugin fundamentals

Purpose and originality

Plugins should serve a clear purpose and reliably do what they promise. In particular, they should provide functionality or workflows that are not natively supported by the products’ built-in capabilities and that meaningfully help satisfy common user intents expressed in conversation.

Only use intellectual property that you own or have permission to use. Do not engage in misleading or copycat designs, impersonation, spam, or static frames with no meaningful interaction. Plugins should not imply that they are made or endorsed by OpenAI.

Quality and reliability

Plugins must behave predictably and reliably. Results should be accurate and relevant to user input. Errors, including unexpected ones, must be handled with clear messaging or fallback behaviors.

Before submitting a plugin, thoroughly test its MCP server, tools, and optional UI across a wide range of scenarios. Plugins should be stable, responsive, and complete. Trial or demo plugins will not be accepted.

Plugin name, description, and optional screenshots

Plugin names and descriptions must be clear, accurate, and straightforward. Avoid overly generic names, especially single-word dictionary terms that aren’t explicitly tied to your brand. Screenshots are optional for plugins with UI. Don’t submit screenshots for plugins without UI. If you include screenshots, they must accurately represent the plugin’s functionality and comply with the required dimensions.

Tools

MCP tools tell ChatGPT and Codex how to use your server’s capabilities. Clear, accurate tool definitions make the plugin safer, easier for the model to understand, and easier for users to trust.

Clear and accurate tool names

Tool names should be human-readable, specific, and descriptive of what the tool actually does.

  • Tool names must be unique within your MCP server.
  • Use plain language that directly reflects the action, ideally as a verb (for example, get_order_status).
  • Avoid misleading, overly promotional, or comparative language (for example, pick_me, best, official).

Descriptions that match behavior

Each tool must include a description that explains its purpose explicitly and accurately.

  • The description should describe what the tool does.
  • Descriptions must not favor or disparage other plugins or services or attempt to influence the model to select them over another plugin’s tools.
  • Descriptions must not recommend overly broad triggering beyond the explicit user intent and purpose the plugin fulfills.
  • If a tool’s behavior is unclear or incomplete from its description, the plugin may be rejected.

Correct annotation

Tool annotations must be correctly set so that the model and users understand whether an action is safe or requires extra caution.

  • You should label a tool with the readOnlyHint annotation if it only retrieves or lists data and does not change anything outside the conversation.
  • Write or destructive tools (for example, creating, updating, deleting, posting, sending) must be explicitly marked using the readOnlyHint and destructiveHint.
  • Tools that interact with external systems, accounts, public platforms, or create publicly-visible content must be explicitly labeled using the openWorldHint annotation.
  • Incorrect or missing action labels are a common cause of rejection. Double-check that the readOnlyHint, openWorldHint, and destructiveHint annotations are correctly set, and provide a detailed justification for each when submitting the plugin.

Minimal and purpose-driven inputs

Tools should request the minimum information necessary to complete their task.

  • Input fields must be directly related to the tool’s stated purpose.
  • Do not request the full conversation history, raw chat transcripts, or broad contextual fields “just in case.” A tool may request a brief, task-specific user intent field only when it meaningfully improves execution and does not expand data collection beyond what is reasonably necessary to respond to the user’s request and for the purposes described in your privacy policy.
  • If needed, rely on the coarse geographic location shared by the system. Do not request precise user location data (for example, GPS coordinates or addresses).

Predictable, auditable behavior

Tools should behave exactly as their names, descriptions, and inputs indicate.

  • Side effects should never be hidden or implicit.
  • If a tool sends data outside the current environment (for example, posting content, sending messages), this must be clear from the tool definition.
  • Tools should be safe to retry where possible, or explicitly indicate when retries may cause repeated effects.

Carefully designed tools help reduce surprises, protect users, and speed up the review process.

Authentication and permissions

If your MCP server requires authentication, the flow must be transparent and explicit. Users must be informed of all requested permissions, and those requests must be limited to what is necessary for the plugin to function.

Test credentials

When submitting a plugin with an authenticated MCP server, provide a login and password for a fully featured demo account that includes sample data. Plugins that require additional login steps, such as a new account sign-up or 2FA through an inaccessible account, will be rejected.

Commerce and monetization

Currently, plugins may conduct commerce only for physical goods. Selling digital products or services—including subscriptions, digital content, tokens, or credits—is not allowed, whether offered directly or indirectly (for example, through freemium upsells).

In addition, plugins may not be used to sell, promote, facilitate, or meaningfully enable the following goods or services:

Prohibited goods

  • Adult content & sexual services
    • Pornography, explicit sexual media, live-cam services, adult subscriptions
    • Sex toys, sex dolls, BDSM gear, fetish products
  • Gambling
    • Real-money gambling services, casino credits, sportsbook wagers, crypto-casino tokens
  • Illegal or regulated drugs
    • Marijuana/THC products, psilocybin, illegal substances
    • CBD products exceeding legal THC limits
  • Drug paraphernalia
    • Bongs, dab rigs, drug-use scales, cannabis grow equipment marketed for drugs
  • Prescription & age-restricted medications
    • Prescription-only drugs (for example, insulin, antibiotics, Ozempic, opioids)
    • Age-restricted Rx products (for example, testosterone, HGH, fertility hormones)
  • Illicit goods
    • Counterfeit or replica products
    • Stolen goods or items without clear provenance
    • Financial-fraud tools (skimmers, fake POS devices)
    • Piracy tools or cracked software
    • Wildlife or environmental contraband (ivory, endangered species products)
  • Malware, spyware & surveillance
    • Malware, ransomware, keyloggers, stalkerware
    • Covert surveillance devices (spy cameras, IMSI catchers, hidden trackers)
  • Tobacco & nicotine
    • Tobacco products
    • Nicotine products (vapes, e-liquids, nicotine pouches)
  • Weapons & harmful materials
    • Firearms, ammunition, firearm parts
    • Explosives, fireworks, bomb-making materials
    • Illegal or age-restricted weapons (switchblades, brass knuckles, crossbows where banned)
    • Self-defense weapons (pepper spray, stun guns, tasers)
    • Extremist merchandise or propaganda

Prohibited fraudulent, deceptive, or high-risk services

  • Fake IDs, forged documents, or document falsification services
  • Debt relief, credit repair, or credit-score manipulation schemes
  • Unregulated, deceptive, or abusive financial services
  • Lending, advance-fee, or credit-building schemes designed to exploit users
  • Crypto or NFT offerings involving speculation, consumer deception, or financial abuse
  • Execution of money transfers, crypto transfers, or investment trades
  • Government-service abuse, impersonation, or benefit manipulation
  • Identity theft, impersonation, or identity-monitoring services that enable misuse
  • Certain legal or quasi-legal services that facilitate fraud, evasion, or misrepresentation
  • Negative-option billing, telemarketing, or consent-bypass schemes
  • High-chargeback, fraud-prone, or abusive travel services

Checkout

Plugins should use external checkout, directing users to complete purchases on your own domain.

Instant Checkout, which is currently in beta, is currently available only to select marketplace partners and may expand to additional marketplaces and retailers over time.

Until then, standard external checkout is the required approach. No other third-party checkout solutions may be embedded or hosted within the plugin UI. To learn more, see our docs on Agentic Commerce.

Advertising

Plugins must not serve advertisements and must not exist primarily as an advertising vehicle. Every plugin must deliver clear, legitimate functionality that provides standalone value to users.

Safety

Usage policies

Do not engage in or facilitate activities prohibited under OpenAI usage policies. Plugins must avoid high-risk behaviors that could expose users to harm, fraud, or misuse.

Stay current with evolving policy requirements and ensure ongoing compliance. Previously approved plugins that are later found in violation may be removed.

Appropriateness

Plugins must be suitable for general audiences, including users aged 13–17. Plugins may not explicitly target children under 13. Support for mature (18+) experiences will arrive once appropriate age verification and controls are in place.

Respect user intent

Provide experiences that directly address the user’s request. Do not insert unrelated content, attempt to redirect the interaction, or collect data beyond what is reasonably necessary to fulfill the user’s request and what is consistent with your privacy policy.

Fair play

Plugins must not include descriptions, titles, tool annotations, or other model-readable fields, at either the tool or plugin level, that manipulate how the model selects or uses other plugins or their tools (for example, instructing the model to prefer one plugin over others) or interfere with fair discovery. All descriptions must accurately reflect the plugin’s value without disparaging alternatives.

Third-party content and integrations

  • Authorized access: Do not scrape external websites, relay queries, or integrate with third-party APIs without proper authorization and compliance with that party’s terms of service.
  • Unofficial connectors: We cannot approve plugins that primarily function as unofficial connectors to third-party services, including pass-through intermediary software layers.
  • Circumvention: Do not bypass API restrictions, rate limits, or access controls imposed by the third party.

Iframes and embedded pages

Plugins with UI can opt in to iframe usage by setting frameDomains in the resource CSP (_meta.ui.csp.frameDomains), but we strongly encourage you to build the UI without this pattern. If you choose to use frameDomains, be aware that:

  • It is only intended for cases where embedding a third-party experience is essential (for example, a notebook, IDE, or similar environment).
  • Those plugins receive extra manual review and are often not approved for broad distribution.
  • During development, any developer can test frameDomains in developer mode, but approval for public listing is limited to trusted scenarios.

Privacy

Privacy policy

Plugin submissions must include a clear, published privacy policy explaining, at minimum, the categories of personal data collected, the purposes of use, the categories of recipients, data retention timelines, and any controls offered to your users. Follow this policy at all times. Users can review your privacy policy before installing the plugin.

Data collection

  • Collection minimization: Gather only the minimum data required to perform the tool’s function. Inputs should be specific, narrowly scoped, and explicitly linked to the task. Avoid “just in case” fields or broad profile data. Design the input schema to limit data collection by default, rather than a funnel for optional context.
  • Response minimization: Tool responses must return only data that is directly relevant to the user’s request and the tool’s stated purpose. Do not include diagnostic, telemetry, or internal identifiers—such as session IDs, trace IDs, request IDs, timestamps, or logging metadata—unless they are strictly required to fulfill the user’s query.
  • Restricted data: Do not collect, solicit, or process the following categories of Restricted Data:
    • Information subject to Payment Card Information Data Security Standards (PCI DSS)
    • Protected health information (PHI)
    • Government identifiers (such as social security numbers)
    • Access credentials and authentication secrets (such as API keys, MFA/OTP codes, or passwords).
  • Regulated Sensitive Data: Do not collect personal data considered “sensitive” or “special category” in the jurisdiction in which the data is collected unless collection is strictly necessary to perform the tool’s stated function; the user has provided legally adequate consent; and the collection and use is explicitly and prominently disclosed at or before the point of collection.
  • Data boundaries:
    • Avoid requesting raw location fields (for example, city or coordinates) in your input schema. When location is needed, obtain it through the client’s controlled side channel (such as environment metadata or a referenced resource) so appropriate policy and consent controls can be applied. This reduces accidental PII capture, enforces least-privilege access, and keeps location handling auditable and revocable.
    • Your MCP server must not pull, reconstruct, or infer the full chat log from the client or elsewhere. Operate only on the explicit snippets and resources the client or model chooses to send. This separation can help prevent covert data expansion and keep analysis limited to intentionally shared content.

Transparency and user control

  • Data practices: Do not engage in surveillance, tracking, or behavioral profiling—including metadata collection such as timestamps, IP addresses, or query patterns—unless explicitly disclosed, narrowly scoped, subject to meaningful user control, and aligned with OpenAI’s usage policies.
  • Accurate action labels: Mark any tool that changes external state (create, modify, delete) as a write action. You should only mark a tool as a read-only action if it is side-effect-free and safe to retry. Destructive actions require clear labels and friction (for example, confirmation) so clients can enforce guardrails, approvals, confirmations, or prompts before execution.
  • Preventing data exfiltration: Any action that sends data outside the current boundary (for example, posting messages, sending emails, or uploading files) must be surfaced to the client as a write action so it can require user confirmation or run in preview mode. This reduces unintentional data leakage and aligns server behavior with client-side security expectations.

Developer verification

Verification

All plugin submissions must come from verified individuals or organizations. Inside the OpenAI Platform Dashboard general settings, we provide a way to confirm your identity and affiliation with any business you wish to publish on behalf of. Misrepresentation, hidden behavior, or attempts to game the system may result in removal from the program.

Support contact details

You must provide customer support contact details where end users can reach you for help. Keep this information accurate and up to date.