On this page
Updated September 2026
To list an MCP server in the OpenAI Plugins Directory, deploy it at a stable public HTTPS endpoint, verify the publishing identity, give the submitter Apps Management write access, prepare the listing and policy materials, scan the server in a With MCP submission, add tool safety annotations and reproducible tests, submit it for review, then publish the approved version.
That is the short answer. The work that determines approval happens before the final button: the tool surface must be understandable, the data boundary must match the privacy policy, side effects must be labeled honestly, and a reviewer must be able to reproduce the core workflows without knowing your product.
Let Codex prepare the submission
OpenAI documents a built-in Plugin Creator skill ↗. Invoke $plugin-creator in Codex or @plugin-creator in ChatGPT Work. It scaffolds a plugin package and can create a local marketplace entry for testing. Ask Codex to prepare the submission materials alongside that package.
Run this prompt in your plugin repository:
Use $plugin-creator to prepare this repository for an OpenAI Plugins Directory submission.
Inspect the existing plugin and MCP server first. Check the current official OpenAI packaging and submission docs, preserve any supported package format already in use, and validate the package.
Create submission-readiness.md with draft listing copy, public policy and support URLs, starter prompts, tool safety annotations with justifications, reviewer setup, and a demo-recording checklist. For a remote MCP submission, prepare exactly five positive tests and three negative tests.
Run the checks you can. Mark unrun tests and missing information clearly. Ask me only for information you cannot determine from the repository. Do not invent policies, credentials, test results, or approval status.
Finish with the prepared files and a short list of what I still need to do in the submission portal. Do not enter credentials, submit for review, or publish anything.The skill currently generates a supported .codex-plugin/plugin.json compatibility scaffold. OpenAI recommends root plugin.json and mcp.json for new manually authored portable packages. Do not force an existing supported package into the compatibility layout.
The submission document above is our suggested Codex task, not an automatic submission feature of the skill. Review the generated files, resolve blockers, then complete publisher verification, required credentials, attestations, and submission in the portal. Approval and publication remain separate steps. If the skill is unavailable, use the official packaging instructions and the manual checklist below.
First, use the current terminology
OpenAI now uses plugin as the package distributed to ChatGPT and Codex. A plugin can contain:
- skills only
- a remote MCP server only
- a remote MCP server plus skills
Published packages appear in the universal Plugins Directory shared by ChatGPT and Codex. This is not the legacy ChatGPT plugin flow. It is also not the same as connecting a private MCP server in developer mode.
| If you are shipping | Submission path | Public endpoint required? |
|---|---|---|
| Reusable instructions and local assets | Skills only | No remote MCP endpoint |
| Live tools or data through MCP | With MCP | Yes, normally a stable public HTTPS endpoint |
| Instructions plus live MCP capabilities | With MCP plus skills | Yes |
| Internal or workspace-only integration | Development or private distribution | Not a public directory submission |
Choose the smallest package that delivers the user job. Adding an MCP server to a workflow that only needs instructions creates authentication, privacy, reliability, and review work without adding user value.
What you need before opening the submission portal
Prepare these items first, then open the OpenAI submission portal ↗ in the publishing organization.
| Area | What to prepare |
|---|---|
| Access | OpenAI Platform organization, Apps Management write permission, correct project |
| Publisher | Verified individual or business identity matching the public brand |
| Listing | Name, short description, long description, category, icon, website, support, privacy, and terms URLs |
| MCP | Stable production HTTPS URL, authentication design, domain verification access, accurate server and tool metadata |
| Safety | Correct read, open-world, and destructive annotations with short justifications |
| Skills | Final validated skill bundle or server-imported skills, if applicable |
| Prompts | Up to three realistic starter prompts that demonstrate distinct high-value jobs |
| Review | Exactly five positive and three negative tests, fixtures, demo account, and a short demo recording for an MCP submission |
| Launch | Country availability, release notes, support owner, and rollback plan |
For remote MCP submissions, the website, support, privacy, and terms URLs are required. For skills-only ZIP uploads, the final validator makes those four listing URLs optional. Any URLs you supply should already work and identify the same publisher.
The seven portal stages at a glance
| Stage | Decision you are documenting |
|---|---|
| Info | What the plugin is, who publishes it, and where users get support and policy information |
| MCP | Which production server is being reviewed, how it authenticates, and what its scanned tools actually do |
| Skills | Which reusable procedures belong in the reviewed package |
| Prompts | Which user jobs best demonstrate the product |
| Testing | How a reviewer proves useful behavior and safe refusal |
| Global | Where the product and its legal and support model are ready |
| Submit | What changed, whether every attestation is true, and whether the review package is complete |
Treat each stage as a product decision. If the Info page describes a narrow research assistant but the MCP scan exposes unrelated administrative writes, the problem is the product boundary, not the wording in the form.
Current final-submission limits
OpenAI's final directory validation is stricter than an initial package upload. As of September 2026, the public error reference lists these limits:
| Field | Final directory rule |
|---|---|
| Package name | 64 characters maximum, starts with an ASCII letter or digit, then ASCII letters, digits, underscores, or hyphens |
| Version | Semantic version, 64 characters maximum |
| Display name | Required, one line, 30 characters maximum |
| Short description | Required, one line, 30 characters maximum |
| Long description | Required, 4,000 characters maximum |
| Developer name | Required, one line, 80 characters maximum |
| Capabilities | Up to 20, each one line and 120 characters maximum |
| Starter prompts | Up to 3, unique, one line, 128 characters maximum, no MCP server @mention |
| Public URLs | HTTPS, 1,024 characters maximum at final submission |
Write to these final limits from the beginning. A package can pass upload validation and still fail the directory's tighter checks.
Step 1: make the MCP server reviewable
The public submission path expects a production server, not a localhost tunnel used for a demo. Verify the endpoint from a clean network and account before submitting.
OpenAI's remote MCP preparation guidance ↗ specifies a public HTTPS endpoint using Streamable HTTP. Implement OAuth 2.1 if the plugin accesses private user data or acts on the user's behalf.
Check all of the following:
- The URL uses HTTPS and remains stable across review.
- Authentication works for a newly created user.
- Reviewer credentials do not require MFA, SMS, email confirmation, VPN, or an employee-only network.
- Every listed tool can be called with the documented input.
- Failure responses are useful and do not leak stack traces, secrets, internal identifiers, or unrelated customer data.
- Any custom UI loads from the exact domains allowed by its content security policy.
- Rate limits allow the reviewer to complete every submitted test.
Most submissions should choose a Universal MCP URL, which means the same fixed endpoint works across users and organizations. The Template URL option is for limited, approved cases where each customer has a distinct tenant or workspace endpoint. Do not select it only because your endpoint contains a path variable.
If the portal asks you to prove control of the domain, it provides a challenge token. Host the exact token at the documented well-known path on the MCP host or an allowed parent origin, confirm it is publicly reachable over HTTPS, then run verification again. Treat the token shown in your own portal as private operational data until you intentionally serve it for the challenge.
Step 2: complete the Info section
The listing should explain one coherent job in language a user can understand before installation.
Name and subtitle
Use the customer-facing product or workflow name. Avoid names or tool descriptions that claim to be "official," "best," or otherwise try to influence model selection. The listing and model-readable metadata must earn selection by being accurate.
Long description
A useful long description answers:
- Who is this for?
- What jobs can it complete?
- Which systems or data does it access?
- Which actions can change external state?
- What setup or account is required?
- What should the user not expect it to do?
Write it as a product contract, not a collection of keywords. This also makes the text easier for search engines and language models to cite accurately.
Icon and brand assets
Use a production-ready square icon that remains legible at small sizes. OpenAI's package checks accept common raster formats and SVG, enforce square geometry, and validate practical size limits. Preview light and dark contexts rather than assuming one asset works in both.
Public policy pages
The privacy policy needs to explain at least the categories of personal data collected, purposes of use, recipient categories, retention periods, and user controls. The website, support, privacy, and terms pages should use HTTPS, identify the same publisher, and be accessible without sign-in.
Step 3: add and scan the MCP server
In the MCP stage, enter the production endpoint, configure authentication, add reviewer-ready credentials when needed, and select Scan Tools.
The scan imports the server's current tool names, titles, descriptions, schemas, security metadata, annotations, UI resources, server instructions, domains, and eligible static skills. Review the result as if you were seeing the product for the first time.
For every tool, ask:
- Does the name describe a single capability?
- Does the description state when the tool should and should not be used?
- Are required and optional inputs accurate?
- Is the result bounded and relevant to the user's request?
- Does the tool change state, send data, publish, overwrite, or delete anything?
- Would a reviewer understand the risk without reading the source code?
Fix incorrect metadata in the server, deploy it, and scan again. A justification typed into the portal does not override an inaccurate server annotation.
Step 4: label tool behavior honestly
OpenAI currently checks three MCP annotations on every submitted tool.
| Annotation | Set it to true when | Common mistake |
|---|---|---|
readOnlyHint | The tool has no side effect and is safe to retry | Marking an action read-only because it usually only reads |
openWorldHint | The tool reaches the public internet or open-ended external entities | Marking public web search false because it does not write |
destructiveHint | A write can delete, overwrite, revoke, send, transact, or cause another hard-to-reverse effect | Looking only for a method named delete |
A message send is a write. Publishing content is a write. Pushing code is a write. Submitting a form is a write. A search across a bounded private workspace can be open-world false even though the service is hosted outside your infrastructure.
Use a one-sentence justification that describes the actual side effect and recovery model. If the tool can be safe in one mode and destructive in another, consider splitting it into clearer operations instead of hiding that distinction in an input flag.
Step 5: add skills only when they improve the workflow
A skill should teach the agent a repeatable procedure, including when it applies, which resources it uses, the expected sequence, and how to verify completion. It should not compensate for unclear MCP tools.
Keep the final tested file tree. Each skill needs a clear SKILL.md, plus any referenced scripts, templates, or assets. OpenAI scans the bundle for security and policy issues. MCP-imported skills are captured as a submission-time snapshot, so after changing one on the server you need to scan again and submit a new version.
For a skills-only upload, the ZIP must contain one unambiguous plugin root, a supported manifest, and at least one valid skill. The current validator caps the compressed archive at 100 MB, extracted content at 512 MiB, and entries at 5,000. Skills-only packages must not smuggle MCP configuration or custom-UI screenshots into that route. Use With MCP when the plugin depends on a remote server.
Step 6: write starter prompts that prove value
You can add up to three starter prompts. Use them to show distinct, representative jobs rather than three phrasings of the same request.
Good starter prompts:
- describe a real user goal
- contain enough context to start, but no hidden test instructions
- produce an observable result
- do not include an MCP server @mention or try to force tool selection
- remain useful after a user adapts the wording
A prompt such as "Summarize this account's open risks and the evidence behind each one" is stronger than "Use AcmePlugin to fetch account data." The first describes the job. The second advertises an implementation.
Step 7: build the review test matrix
For a remote MCP submission, prepare exactly five positive tests and three negative tests for final validation. The narrative submission guide says "at least five" in its Testing section, while the final validation reference requires exactly five. Follow the stricter remote-MCP validator. Treat the tests as product acceptance tests, not form filler.
| Test type | What the reviewer needs |
|---|---|
| Positive | User prompt, expected tool or skill behavior, expected result shape, reproducible fixture or account |
| Negative | Prompt or scenario, expected refusal, clarification, or safe fallback, and the reason the plugin should not complete it |
Your positive set should cover the primary workflow, a second meaningful workflow, a realistic edge case, an authenticated path, and a path involving a result a reviewer can verify. Your negative set should cover an unauthorized or out-of-scope request, missing critical information, and an unsafe or destructive action without the required confirmation.
Run every test from a clean account. Write expected behavior precisely enough that two reviewers would reach the same pass or fail decision. If the data changes constantly, create stable fixtures or explain the invariant that should remain true.
Step 8: review privacy and response minimization
The privacy policy and the server must agree. Inventory each input and output against the stated purpose.
Remove unnecessary:
- personal data
- authentication secrets
- debug payloads and stack traces
- internal IDs and telemetry metadata
- broad context collected "just in case"
- unrelated fields returned by an upstream API
Do not ask for full conversation history. A task-specific input can be appropriate when it is necessary to perform the request and covered by the disclosed purpose. Design schemas so minimization is the default rather than an instruction users must remember.
Step 9: choose availability and submit
Select only countries where the product, support process, and legal terms are ready. Then review the entire draft, add release notes, complete the attestations, and submit for review.
Useful release notes state:
- what the plugin does
- whether this is the first submission or an update
- what changed from the previous reviewed version
- anything needed to reproduce the tests
Submission does not publish the plugin. OpenAI reviews it first. After approval, the publisher chooses when to make the reviewed version public.
Common rejection and delay patterns
| Symptom | Likely cause | Fix before resubmitting |
|---|---|---|
| Reviewer cannot connect | Endpoint, auth, allowlist, or demo account is not truly external | Test from a clean network and account |
| Tools rescan differently | Production metadata changed during review | Freeze the release and rescan the final deployment |
| Safety annotation warning | Portal value and real server behavior disagree | Correct the server annotation and rescan |
| Positive test is inconclusive | Expected result is subjective or depends on hidden context | Use stable fixtures and an observable result |
| Negative test still acts | Confirmation, authorization, or refusal boundary is incomplete | Fix the behavior, not only the test prose |
| Privacy review fails | Responses contain undeclared or unnecessary data | Minimize output and update the policy where collection is necessary |
| UI fails | CSP omits a domain or the resource is not publicly reachable | Test in the actual host environment |
There is no guaranteed public review time. Build launch plans around readiness, not an assumed approval date. OpenAI also does not promise enhanced placement. Exact-name discovery and a direct directory link are the dependable starting points.
After publication: listing is not adoption
A directory listing answers "can users find and install this?" It does not answer "does the MCP server help them?"
After launch, track:
- unique users and repeat users
- use cases people attempt
- tools selected within each complete journey
- retries, loops, and abandoned workflows
- technical success separately from user outcome
- requests the tool surface cannot satisfy
- recurring product feedback and commercial signals
- changes after each server or metadata release
MCP adoption is not the same thing as MCP tool-call volume. High volume can represent valuable repeat use, but it can also represent poor tool selection or repeated retries.
Flowlines MCP observability instruments MCP servers with OpenTelemetry-compatible instrumentation and turns MCP interactions into complete behavioral sessions. Teams can see what users tried to do, how the agent used the tools, whether the journey succeeded, and which patterns repeat across users.
If you also distribute to Anthropic's ecosystem, use the companion Claude plugin marketplace submission guide. Use the MCP observability guide for the full monitoring model, MCP analytics for adoption and product questions, and the OpenTelemetry instrumentation guide for implementation. Developers using Claude Code or Codex can start with the Flowlines plugin.
Final OpenAI submission checklist
For a remote MCP plugin, including one that also bundles skills, check every item below. A skills-only ZIP does not need an MCP endpoint, tool scan, or the remote server's five-positive/three-negative test set.
- The plugin solves one clear user job.
- The Plugin Creator skill has prepared and validated the package, or the equivalent checks have been completed manually.
- The generated files and submission-readiness document have been reviewed by a human.
- The correct skills-only, MCP-only, or combined path is selected.
- The MCP endpoint is stable, public, and production-ready.
- The submitter has Apps Management write permission.
- The publisher identity is verified and matches the public pages.
- Website, support, privacy, and terms URLs work without sign-in.
- Tool names, descriptions, schemas, and results are accurate.
- Every tool has honest read-only, open-world, and destructive annotations.
- The final deployment has been rescanned.
- Starter prompts demonstrate distinct user jobs.
- Exactly five positive and three negative tests pass from a clean account.
- Reviewer credentials need no MFA or private network.
- Sensitive and unrelated data is absent from inputs and responses.
- Territory, release notes, and support ownership are ready.
- The team has a plan to measure use cases and outcomes after launch.
Primary sources
Frequently asked questions
How do I list an MCP server in the OpenAI Plugins Directory?
Deploy the server at a stable public HTTPS endpoint, prepare accurate listing and policy information, obtain Apps Management write access, verify the publisher identity, then create a With MCP submission in the OpenAI Platform. Scan the server, resolve metadata and safety issues, add reproducible tests, submit for review, and publish after approval.
Is the OpenAI Plugins Directory shared by ChatGPT and Codex?
Yes. OpenAI describes it as a universal Plugins Directory shared by ChatGPT and Codex. Skills-only, remote MCP-only, and combined skills-plus-MCP plugins can all appear there.
Can I submit a local MCP server to the public OpenAI directory?
Normally no. A public MCP submission requires a stable production HTTPS endpoint. Local and workspace-only integrations belong in development or private distribution flows unless OpenAI has provided a supported exception.
What permissions are required to submit an OpenAI plugin?
The submitter needs Apps Management write access in the publishing OpenAI Platform organization. Organization owners already have the relevant permissions. The public submission must also use a verified individual or business identity.
What test cases does OpenAI require for plugin review?
For a remote MCP submission, prepare exactly five positive test cases and three negative test cases for final validation. Each must be reproducible without private context, and authenticated tests need reviewer credentials that work without MFA, SMS, email confirmation, or private-network access.
Which MCP tool annotations does OpenAI review?
Every submitted MCP tool needs accurate readOnlyHint, openWorldHint, and destructiveHint values. The values must describe actual server behavior, and the submission should include a clear justification for each.
Does approval publish an OpenAI plugin immediately?
No. Submission starts the review. After approval, the developer chooses when to publish the approved version from the portal.
Can a submitted OpenAI plugin combine an MCP server and skills?
Yes. OpenAI accepts skills-only plugins, remote MCP-only plugins, and packages that combine a remote MCP server with uploaded or MCP-imported skills.
Can Codex prepare an OpenAI plugin submission?
Yes. Invoke $plugin-creator in Codex to scaffold the package, then ask Codex to prepare listing copy, tests, and reviewer instructions. Check its output against the current submission rules. Publisher verification, review, and publication remain separate steps.
How long does OpenAI plugin review take?
OpenAI does not publish a guaranteed review time. The official guide says timing can vary as the review process scales, so plan for at least one remediation cycle and do not anchor a launch to an assumed approval date.
How do I know whether people use my MCP server after it is listed?
Measure unique users, attempted use cases, complete sessions, retries, outcomes, unmet requests, and repeat adoption. Installations and tool-call volume do not reveal whether users achieved their goals.