Plugin Creator

View saved version →

---
name: create-plugin
description: Create local or cloud plugins. Use when the user asks to build an app, tool, integration, or reusable workflow within ChatGPT or Codex. Covers custom MCP apps, skills, tools that connect agents to websites and services, and extensions for custom app views, file handling, and referencing app data in chat.
---

# Create a plugin

Default to a **cloud plugin built and hosted with Sites MCP**. Choose
its skills, tools, interactive views, and Extensions to fit the user's task.

For changes to an existing plugin, use
[update-plugin](../update-plugin/SKILL.md).

## Choose the capabilities

| Building block | What it provides |
| --- | --- |
| Skills | Reusable instructions, domain knowledge, workflows, and supporting files. |
| MCP tools | Access to data and actions, usable directly in chat. |
| MCP Apps | Interactive views for working with the plugin's data and actions. |
| Extensions | Integration with host surfaces such as navigation, files, settings, and the composer. |

### Extensions

Extensions provide deeper integration with ChatGPT and Codex. When the plugin's
skills, tools, and views do not fully support a workflow, consider an Extension
that enables or improves it. For example:

| User workflow | Implementation docs |
| --- | --- |
| View or edit a CSV, drawing, or other file | [File handlers](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md#file-extension-handlers) and [authorized file access](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md#filesystem-access) |
| Attach selected rows, objects, or app state to a message | [Model context lifecycle](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md#model-context-lifecycle) |
| Reference app content with `@` | [Extensions spec](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md) and installed SDK support for composer mentions |
| Share or reopen a location in the app | [Deep links](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md#deep-links) |
| Open from navigation or alongside a conversation | [Entrypoints](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md#entrypoints) |
| Configure the plugin within the host | [Settings entrypoints](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md#entrypoints) |
| Show a workspace fullscreen or a confirmation inline | [Display preferences](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md#preferred-model-display-mode) |
| Match the host's appearance | [App styling](https://github.com/openai/mcp-extensions/blob/main/typescript/README.md#styling) |
| Collect structured input with visual selections | [Extensions spec](https://github.com/openai/mcp-extensions/blob/main/docs/spec.md) and installed SDK support for rich forms |

Use the [Extensions guide](references/extensions.md) for integration examples and
SDK choices. For general tools and interactive views, use the
[MCP specification](https://modelcontextprotocol.io/specification/latest) and
[MCP Apps specification](https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/draft/apps.mdx).
Read the relevant documentation for the installed SDK version and check the
Extensions spec's current host-support guidance.

## Build a cloud plugin by default

Follow the available `sites-mcp` skill and [Sites MCP guide](references/sites-mcp.md)
through building, publishing, and connection. Publishing provisions the Site's
App and canonical private plugin; reuse that plugin.

Use this path unless the request gives a reason for another approach:

- **Skills only:** for reusable instructions or a workflow that needs no new
  server or app, create a plugin containing skills and supporting files. Follow
  [Plugin packages](references/plugin-packages.md) for installation and saving
  to the user's account.
- **Existing MCP server:** connect the plugin to that server, preserving its
  hosting and authentication. Follow [Server access](references/server-access.md)
  and [Plugin packages](references/plugin-packages.md).
- **Local plugin:** choose a local plugin when the user provides existing local
  plugin or app files to build from, asks to run locally, or needs direct access
  to local files, processes, or hardware. Reuse the requested codebase and runtime;
  follow [Local plugins](references/local-plugins.md). Preserve an existing app's
  source and hosting unless the user asks to change them.

## Finish

Follow the chosen guide through verification and connection. Use local Codex
logs to investigate desktop failures when available.

To share inside a Workspace, go to **Plugins → Created by you → select plugin → Share**. You need to also share the Site if the Plugin is Site-hosted

To prepare a plugin for submission to the public directory, follow
[prepare-plugin-submission](../prepare-plugin-submission/SKILL.md) before the
final package handoff. Guide the user through review and publication metadata,
even when they only want a ZIP for later submission. Upload only when requested.
Sharing within a workspace does not require public submission.

Referenced files: 8

View saved version →

---
name: prepare-plugin-submission
description: Guide a user through preparing an existing plugin for public submission, including review and publication metadata, listing, examples, demo, and reviewer access. Use when the user wants to get ready to submit, create a submission-ready ZIP, submit, or publicly release a plugin.
---

# Prepare a plugin submission

Prepare an existing plugin for public review, including a ZIP prepared for later
submission. Ordinary private creation, updates, and source exports without
submission intent do not need this workflow. Use
[create-plugin](../create-plugin/SKILL.md) or [update-plugin](../update-plugin/SKILL.md)
first if implementation is unfinished.

Start from the actual source, listing, and supplied materials. Ask only for
missing publisher information, intended behavior, or access; do not invent
URLs, evidence, or attestations. When dashboard work is requested, use the intended
organization and publisher. Preserve the plugin's identity, original source,
and audience; prepare public uploads in a separate copy. Preserve private app
bindings in the original source and Portal-generated bindings in finalized
releases, not in the author-supplied public upload. A Sites-generated plugin
needs a submission path supporting its canonical App ownership, not a duplicate
private plugin.

## Guide the preparation

A request to get ready to submit starts this workflow; it does not require an
upload. Preparing the source and ZIP must not depend on dashboard or browser
access. Keep working within the user's chosen tools and delivery scope.

Guide the user in this order: collect listing and publication details, prepare the demo and other review materials, finalize the ZIP, then upload, connect, and test in the submission portal as the final setup step. Do not lead with portal upload or leave the user with an undifferentiated list of unresolved requirements. Ask the next concrete preparation question and help complete its answer before moving to the portal.

Read the relevant reference before each stage:

- [Package and listing](references/listing.md): public-upload restrictions,
  listing fields, all four required URLs, and icon creation and verification.
- [Review materials](references/review-materials.md): cases, demos, reviewer
  access, and review/publication metadata. Read the publication mappings for
  skills-only plugins too, including release notes, countries, and translations.

1. Inspect the source, tools, metadata, and previous answers. Draft the listing,
   applicable review cases, and release notes from supported behavior. Show
   drafts for correction while continuing preparation.
2. Collect missing listing and publication facts in small groups. Ask for the intended verified individual or business identity, supported countries (or an explicit choice of all available countries), and whether the plugin involves payments or purchases; if it does, ask what users buy and where payment occurs. Reuse prior answers, explain the required fields in plain language, and resolve missing listing URLs and policy coverage. Do not invent a publisher, infer country targeting from a domain, or infer commerce behavior from the publisher's other products.
3. Help create the icon and demo before directing the user to the submission portal. For the demo, provide specific prompts and the results to show, guide recording and reviewer-accessible hosting, then verify the actual recording link. Follow the recording reference for an existing development connection or an authentication dependency. Never present a script as a recorded demo, an unrun case as tested, or drafted policy text as a published policy.
4. Write supported values into the package as work progresses. Use the references' field mappings for `extensions.com.openai.interface`, `review`, and `publication`; keep multiple servers' cases on their respective servers. Separate review notes do not replace metadata. Leave unknown fields absent and track gaps; do not invent declarations or URLs, or insert empty objects or lists that clear saved values.
5. Rebuild and inspect the final ZIP and its metadata. Return it with what is complete and the specific preparation item still needing input, if any. An incomplete ZIP is not ready to submit. If the user switches to ZIP-only, retain metadata and continue helping with missing materials; only the online action leaves scope.
6. Once preparation is complete, guide the final portal setup: upload the ZIP as a draft when requested, connect the actual MCP server through OAuth where needed, and run the review cases against the saved version. Verify imported metadata and resolve portal requirements before an authorized submission. Keep submission for review and publication separate from this setup step.

Skills-only plugins need no MCP cases, demo, or reviewer credentials. For each
app needing initial public review, draft five positive and three negative cases
from its actual behavior; existing reviewed dependencies need an eligible version.
Supply reviewer credentials and login instructions only through secure dashboard
fields, never public listing fields or the ZIP.

## Check readiness before handoff

Inspect the contents of the final ZIP, not only the working files. Check the
listing fields and lengths, all four verified listing URLs, icon references and
files, and applicable review cases, recording URL, release notes, commerce
details, and country targeting. Check case counts and required fields as well
as test quality. Run target package/submission validation when available and
fix every issue that can be addressed in the ZIP before calling it ready.

Report package readiness separately from remaining dashboard requirements:
reviewer credentials, connection/authentication setup, domain and developer
verification, required scans, and attestations. A valid ZIP cannot complete
those steps or guarantee review approval. When an upload is requested, inspect
the exact saved version's metadata and review-information issues, verify the
imported values, and resolve any remaining errors within scope. Do not equate
upload success with submission readiness.

## Online actions and draft updates

Read [submission lifecycle](references/submission-lifecycle.md) before uploading,
submitting, publishing, or updating a saved draft. Proceed only within the user's
request and existing authorization, using the intended organization and publisher.
For ZIP-only requests, return the archive and gaps without creating a private plugin.

An upload creates a draft; submission for review and publishing an approved release
are separate actions. Have the authorized developer complete legal/policy
attestations. Reupload replaces the full bundle and resets attestations; inspect
the saved draft and the reference's field-preservation rules before replacing it.
Changes after review starts may require cancelling review; explain that effect
and obtain authorization before doing so.

Report the outcome actually completed: archive prepared, draft uploaded,
submitted for review, or approved release published. Include missing materials,
unverified checks, and the actual review state.

Referenced files: 3

View saved version →

---
name: update-plugin
description: Inspect, edit, or extend custom plugins the user owns or has permission to edit. Use when the user asks to change a plugin's instructions, skills, tools, app UI, Extensions, metadata, assets, or configuration, or asks about a previous version.
---

# Update a plugin

Start from the selected plugin and its current source. Preserve its identity,
data, hosting, and audience while making the requested change. A question about
the plugin or its history does not by itself call for an edit.

## Find the source that owns the change

| Plugin or change | Workflow |
| --- | --- |
| A Site's website, MCP tools, or Extensions | Edit the existing Site source and use [Sites MCP](../create-plugin/references/sites-mcp.md). Keep its project, App, and plugin IDs. |
| A local plugin | Edit the selected directory and follow [local plugins](../create-plugin/references/local-plugins.md) to reload it when requested. |
| A separately hosted MCP server or app | Change its server/UI repository and use its existing deployment process. Update the plugin package only if its files or connection configuration also change. |
| A standalone plugin saved through Plugin Creator | Follow [account plugin updates](references/account-updates.md) to retrieve source and publish an eligible update. |
| A Git-synced or otherwise managed plugin | Change its owning source and use that release process. The archive editor cannot update every installed plugin. |

Read the [Extensions reference](../create-plugin/references/extensions.md) when
changing host integration. Use [package format](../create-plugin/references/plugin-packages.md)
when changing manifests, skills, or packaged assets. Inspect existing files
before replacing them; reuse the implementation where it still fits.

For an account plugin, use its verified backend ID and existing scope, not a
similarly named result or the active account's scope. Prefer the source tools
for text edits. Download an archive only for history or content those tools
cannot return. The account reference covers ownership, partial-file updates,
and release-conflict handling.

## Apply and verify

Honor requests to save source without deploying. For a shared plugin, make
the effect on other users clear before publishing and obtain authorization
if the conversation has not already provided it. Keep sharing and permissions
unchanged unless the user requests otherwise through a supported workflow.

Test the behavior affected by the change. For an MCP App, verify its tools and
UI in the intended ChatGPT or Codex host when available. Return the plugin link
or source changes, a brief account of what changed, and any unverified behavior.
Use [prepare-plugin-submission](../prepare-plugin-submission/SKILL.md) for a
requested public submission, not for an ordinary private update.

Referenced files: 2