Connector distribution
Build an OpenAI plugin with MCP: packaging, extensions and review
Understand the MCP server, plugin package and optional UI extension layers. Prepare a ChatGPT and Codex plugin without confusing hosting with directory approval.
Separate the server, package and user interface
The MCP server exposes the actual tools and implements the integration’s access model. The plugin package describes what users install. An optional MCP App interface provides interactive views; extensions connect that interface to additional host surfaces. Keep these layers separate in the project plan. A reachable endpoint does not prove that a plugin can be installed or published, and a valid manifest does not make the underlying tools safe. This guide describes the official documentation reviewed on October 2, 2026; it is not a report of an MCP Ops plugin approved by OpenAI.
Choose one workflow and test its boundaries
For example, build a read-only account-status workflow before attempting a general-purpose CRM assistant. Define which account records the user can access, which fields the result includes and what happens when authorization expires. Our recommended test packet includes a successful query, an inaccessible record, an empty result, a slow upstream and a request outside the declared purpose. Record the actual client, server revision and observed result. Use synthetic records and a least-privilege reviewer account. This is more useful than a video containing only a successful request with an administrator account.
Package the integration using the current format
OpenAI’s package guide recommends a root plugin.json for portable packages, with OpenAI-specific settings under extensions.com.openai. Portable bundled MCP configuration belongs in mcp.json; registered MCP mappings use the documented apps configuration instead. Follow the official examples for your chosen path rather than mixing formats. Authentication and UI remain part of the server integration, not a feature supplied by the manifest. Keep assets and relative paths valid, and never bundle credentials. Start from the linked package guide, validate the ZIP and resolve reported fields rather than relying on an old plugin tutorial.
Add an extension only when it improves the task
The extension reference describes surfaces including sidebar apps, conversation panels, settings and file viewers. Its sidebar example registers an MCP App UI resource and declares a global entrypoint in tool metadata; thread entrypoints serve conversation panels. Follow the linked SDK and registration examples for the full implementation. A project-status panel could let a user inspect the source tasks behind a summary; that is our design example, not a tested integration. Choose one surface and test navigation, loading, denied access and empty states. Check current client availability, because supported surfaces can differ by application and plan.
Prepare the submission and verify the hosting fit
The submission guide requires a verified publishing identity and describes uploading the package ZIP, resolving automated findings, connecting the MCP and completing domain verification. Include the MCP in the initial package if it needs one. Review information should enable reproducible tests; approval precedes publication. Follow current plugin guidelines for tool, authentication and privacy requirements. MCP Ops currently offers a restricted Node.js stdio import path and bearer-key gateway, not completed end-user MCP OAuth or automatic extension hosting. Verify that fit before choosing it for a directory-bound plugin. Never remove necessary authentication simply to pass a connection check.
Before you proceed
Mark the items you have reviewed. This is a local reading aid, not a security assessment; it resets when you leave.
Use this checklist during your own review. It is not a certification or an automated test result.