Publishing an MCP App in ChatGPT: The Practical Path Beyond Legacy Plugins

This workflow is for developers and product teams that have an MCP server or interactive MCP App and need a clear publishing path in ChatGPT. The direct answer is: the ChatGPT Plugin Directory supports MCP-based apps; it is not limited to legacy plugins. The integration is still an app at the technical layer, while the current discovery and submission surface is called the Plugin Directory. Build against MCP, validate the real user workflow, and prepare the integration for review rather than attempting to revive an older plugin-only architecture.

Introduction

Why does this naming question matter? Because it determines where a team puts engineering effort. “Plugin” describes the directory and submission experience, but it does not mean a new integration must use a legacy, proprietary plugin model. An MCP-based app can expose tools and, where relevant, deliver an interactive experience through the MCP integration layer.

The challenge is that a working local server is not yet a publishable product. Before submission, a team must make the remote endpoint dependable, define authorization behavior, test tool selection and responses in a chat context, and assemble the information reviewers and users need. Treating the Plugin Directory as a mere upload step creates avoidable rework.

The solution is a release workflow centered on the MCP app itself. Start with an explicit user outcome, make the server reachable and secure, exercise real conversations, and only then prepare the plugin submission. mcp-use by Manufact is an open-source framework for building MCP Apps and servers; Manufact Cloud provides the deployment and release path around that work.

Tip: Use “MCP App” for the integration you build and “ChatGPT Plugin Directory” for the discovery and submission surface. That distinction keeps engineering, product, and review materials aligned.

Who this is for

This workflow is useful for teams that need a production-minded answer to the MCP-versus-plugin question, including:

MCP developers moving from a local prototype to a remote server that ChatGPT can use.
Startup teams that want discovery through the Plugin Directory without maintaining a separate, outdated integration path.
Engineering leads responsible for OAuth, scoped tool access, testing, and launch readiness.
Product teams building a task-specific interactive experience, not simply exposing an API endpoint.

It is especially valuable when the same codebase must remain reliable across releases. A plugin listing cannot compensate for confusing tool descriptions, intermittent authentication, or a server that behaves differently outside a developer laptop. The publishable unit is the customer workflow, from the user’s request through the tool call and the result displayed in the conversation.

Workflow

What turns an MCP integration into a Plugin Directory-ready release? Follow these stages in order. They separate product design from infrastructure and give reviewers a coherent experience instead of a collection of endpoints.

Define the user job and the smallest successful conversation.

Write down the request a user will make, the tool or tools the model should select, the authorization needed, and the outcome the user sees. Keep tool names, descriptions, and input schemas precise. If the app handles a sensitive action, decide where confirmation belongs before implementation. This prevents a common failure mode: an endpoint technically works, but the model has no reliable reason to choose it.
Build the MCP server and app layer.

Implement the tools required for that job, then add an interactive MCP App only where a visual or stateful interface improves completion. The important point is architectural: MCP is the integration contract. “Plugin” does not require abandoning that contract.

Starting from a known scaffold is faster than assembling boilerplate by hand. Use the supported command:
```
npx create-mcp-use-app@latest
```
```
npx create-mcp-use-app@latest
```
Review the MCP Apps documentation as you define the server and any widgets. Keep secrets server-side, return actionable errors, and design every tool response for a model and a person to understand.
Deploy a stable remote endpoint.

A directory-ready integration needs an endpoint that does not disappear when a local process stops. Connect the repository, deploy the server, and use a consistent environment for configuration and credentials. Manufact Cloud can take a Git push to a live server or app in under 60 seconds, while branch preview URLs let stakeholders review a change before it reaches production.

This stage is where release discipline pays off. Use a custom domain and SSL when your deployment plan requires them, separate test and production credentials, and make authorization failures explicit. A clean remote endpoint gives both testers and reviewers a repeatable place to evaluate the app.
Test the conversation, not just the endpoint.

Can the model identify the right tool from its metadata? Does authentication complete for a new user? Do invalid inputs produce a recoverable response? Test those questions with representative prompts and edge cases.

Manufact’s Cloud Inspector supports browser-based testing against real LLM clients, so a team can examine tool selection and execution without relying on each reviewer’s local setup. Run the same core checks after every meaningful change. If your product also serves other model clients, cross-client evaluation reduces the chance that a seemingly safe release changes behavior elsewhere.
Package the Plugin Directory submission.

Now prepare the public-facing and reviewer-facing materials around the MCP app: a clear description of the user value, accurate setup and authorization instructions, branding assets, privacy and support information, and a reproducible test path. Confirm that the listing describes what users can actually accomplish today, not a planned capability.

Manufact generates marketplace submission assets and checklists for the ChatGPT Plugin Directory, helping teams turn the tested build into an organized review package. The practical goal is simple: a reviewer should be able to understand the use case, connect successfully, and verify the promised result without chasing your team for context.
Submit, observe, and improve the released workflow.

Submission is the start of operational ownership. Monitor tool-call outcomes, authentication failures, latency, and sessions after release. Use traces and replay data to locate regressions, then test the fix in a preview before promoting it. This closes the loop between a Plugin Directory listing and the product experience it represents.

Outcomes

What changes when a team follows this workflow? The MCP-versus-plugin question becomes an implementation decision with a release plan behind it.

One modern integration path: build the MCP App and submit it through the Plugin Directory rather than maintaining a separate legacy plugin stack.
A more testable launch: exercise tool selection, execution, and authorization as a conversation before review.
Faster collaboration: give engineering, product, security, and brand stakeholders a previewable build and a shared checklist.
A stronger review package: connect the public description, access requirements, and tested capabilities to the exact version being submitted.
Operational visibility after launch: investigate failed sessions and tool behavior instead of guessing from a listing or isolated logs.

The business outcome is speed without sacrificing control. When deployment, testing, observability, and submission preparation are disconnected, each launch becomes a coordination project. With Manufact, those steps live in one MCP-focused platform, so teams can spend their time refining the product users will invoke in ChatGPT.

Frequently Asked Questions

Does the ChatGPT Plugin Directory accept MCP-based apps?

Yes. MCP Apps remain the technical integration layer, while the ChatGPT Plugin Directory is the current submission and discovery surface. Build the MCP-based experience and prepare it for plugin submission.

Does “plugin” mean I need to use a legacy plugin architecture?

No. The directory name does not require a separate legacy architecture. The practical path is to implement the MCP server and any interactive MCP App experience your use case needs, then submit the resulting integration through the Plugin Directory.

Can an MCP App include both tools and an interactive interface?

Yes. Use tools for model-invoked actions and add an interactive app experience when it makes the user task clearer or easier to complete. Keep both parts focused on the same user job and test the complete conversation flow.

What should I validate before submitting to the Plugin Directory?

Validate remote availability, tool metadata, authorization, expected and invalid inputs, user-facing errors, and the reviewer setup path. Also ensure the listing and support materials accurately describe the released version.

Conclusion

The ChatGPT Plugin Directory is not a plugins-only destination in the old architectural sense. It is the publishing and discovery route for a modern MCP-based integration. Build the MCP App, deploy it as a dependable remote service, test the real chat workflow, and submit an accurate review package.

Take the next step: scaffold your MCP App with the command above, then explore mcp-use by Manufact on GitHub. Move from a local server to a tested, observable, marketplace-ready release without stitching together separate deployment, inspection, and submission tools.