ChatGPT MCP Server Hosting Moves Deployment Into Sites, but Access Still Sets the Boundary

ChatGPT now supports a ChatGPT MCP server workflow that can build, host, and deploy tools through Sites, without requiring a separate hosting provider. The shift removes one of the largest practical barriers around the Model Context Protocol, or MCP, which lets AI clients invoke external tools through a shared interface.

A public post from Tibo Thibault highlighted the feature on October 1, 2026. OpenAI’s current documentation confirms the underlying workflow. A user can ask ChatGPT or Codex to add an MCP server to a Site, publish it, and install the resulting plugin.

That makes the announcement more consequential than another website builder update. Until now, a typical ChatGPT MCP server required code, an internet-accessible endpoint, deployment infrastructure, and a separate connection process. Sites brings several of those steps into one conversational environment.

The important contest is therefore not ChatGPT against another model. It is managed, prompt-driven deployment against the conventional self-hosted MCP route. OpenAI has shortened the path from an idea to an installed tool, but permissions, testing, and distribution still determine whether that tool is useful.

What Changed With ChatGPT MCP Server Hosting

ChatGPT Sites can now act as both the application surface and the host for MCP tools used through a plugin.

ChatGPT Sites is OpenAI’s environment for building and publishing interactive websites and lightweight applications. Users describe what they want, review a generated preview, request revisions, and deploy the result to a Site URL.

The new element is the ability to add server-side tools to that Site. OpenAI’s Sites guide says users can ask ChatGPT or Codex to add an MCP server to a new or existing Site. They must describe the information those tools can read and the changes they can make.

MCP is a protocol for exposing tools and data to compatible AI clients. The server describes available operations, their inputs, and their outputs. ChatGPT can then call those operations when a user makes a relevant request.

A Site owner might create a project dashboard, for example, then add tools for reading milestones and updating their status. Publishing the Site creates an associated plugin that exposes those tools inside supported ChatGPT and Codex conversations.

This sequence compresses several previously separate jobs:

• The user defines the desired workflow in a conversation.

• ChatGPT or Codex builds the Site and its MCP tools.

• The owner reviews the Site and tests its behavior.

• Publishing produces a live Site and its associated plugin.

• The user installs and connects that plugin.

• ChatGPT can invoke its tools in later conversations.

The Site remains more than a static interface. It can hold information, present an interactive view, and supply the operations exposed through MCP. OpenAI’s example describes a team handbook with tools for searching and accessing its contents.

That pattern also fits project trackers, internal directories, launch calendars, document finders, and operational dashboards. A team could combine the approach with a searchable knowledge base, provided its data and permissions are designed carefully.

The owner must publish the Site before the associated plugin appears. Adding or changing tools also requires another publication before those changes become available. A saved draft does not silently alter the live plugin.

OpenAI describes Sites as a public beta. It is available for ChatGPT workspaces, Plus accounts, and Pro accounts, although the rollout may not reach every account simultaneously. Workspace administrators can control creation and publication rights.

The deployment URL is a production URL. OpenAI advises creators to save a version and review changes before deployment. That distinction matters because conversational editing can feel informal even when the resulting software has live users.

The result is a notably shorter deployment path. It does not eliminate software operations, but it relocates many of them into a managed product and a conversational workflow.

Why Prompt-Driven Deployment Pressures the Self-Hosted Route

Sites turns MCP deployment from an infrastructure project into a product configuration task for many smaller workflows.

A conventional remote MCP deployment still requires a functioning server that ChatGPT can reach over the public internet. The developer must implement tools, expose an HTTPS endpoint, configure authentication, and keep the service available.

OpenAI’s MCP quickstart illustrates that route. Developers install an MCP software development kit, create a server, expose a /mcp endpoint, and connect the public URL through ChatGPT’s developer controls.

That remains the appropriate route when a team needs custom infrastructure, complex integrations, independent scaling, or control over the runtime. It also gives developers direct authority over deployment schedules, logs, networking, and data storage.

However, many internal tools do not begin with those requirements. They begin as narrow requests, such as searching a handbook, updating a milestone, or retrieving a project record. The infrastructure work can exceed the first version’s functional scope.

ChatGPT Sites targets that gap. A user can describe the Site, its data, and the operations that ChatGPT should perform. Codex can then generate the required tool layer and connect it to an installable plugin.

This does not make engineering knowledge irrelevant. It changes where that knowledge becomes necessary.

The first version can emerge through a guided build rather than a manually assembled deployment stack. Engineering attention can move toward tool boundaries, authorization, error handling, and data quality.

That is the central reversal. MCP was designed to standardize connections, yet operating a server still created friction for people who only wanted a focused workflow. OpenAI is now using a managed host to reduce that operational burden.

The pressure falls first on lightweight hosting patterns and internal prototypes. A developer may no longer need a separate cloud project merely to test whether a three-tool workflow solves a real problem.

The pressure also reaches no-code and low-code AI builders. ChatGPT now connects conversational specification, application generation, hosting, and plugin installation within one account environment. That narrows the distance between a prototype and a usable ChatGPT tool.

Yet self-hosting retains meaningful advantages. A managed Site does not automatically offer the deployment flexibility, observability, portability, or capacity required by every production system.

OpenAI also applies plan-specific usage limits during the public beta. Those limits cover Sites across an account and can affect the ability to create Sites, add storage, or keep a busy Site publicly available.

The documentation tells users to check the limits displayed within their account. It does not provide one fixed capacity that applies universally.

That uncertainty prevents a simple conclusion that Sites replaces conventional MCP hosting. It instead creates a managed default for smaller or earlier-stage deployments.

Developers should view the two routes as different operational commitments:

• Site-hosted tools prioritize speed, integrated deployment, and a guided workflow.

• Self-hosted tools prioritize infrastructure control, custom architecture, and independent operations.

• Site-hosted plugins inherit OpenAI account and workspace controls.

• Self-hosted servers still inherit ChatGPT connection, authorization, and review requirements.

For many teams, the choice will depend less on code generation than on governance. Building an MCP tool is becoming easier. Deciding who can invoke it remains the harder product decision.

How the Site Becomes an Installable Plugin

The workflow links a published Site to a plugin, but installation and authorization remain separate steps.

OpenAI’s hosting guide describes a specific sequence. The creator starts with a Site they own, asks ChatGPT or Codex to add MCP tools, reviews them, and publishes the Site.

After the MCP setup finishes, ChatGPT presents a plugin card associated with that Site. The creator can review the card, select Install, and complete the connection flow.

The installed plugin can then be mentioned in a supported ChatGPT or Codex conversation. ChatGPT may also select an installed plugin when it matches the user’s request.

This packaging step matters because a raw MCP endpoint and a distributable ChatGPT experience are not identical. The plugin provides a recognizable unit that users can install, find, select, and manage.

Plugins can include skills, connected applications, MCP-backed tools, and interactive extensions. A Site-hosted MCP application becomes one component within that broader packaging system.

The current plugin directory appears on ChatGPT web, desktop, and mobile. However, OpenAI warns that individual capabilities can vary by surface, account, region, plan, role, and workspace configuration.

That qualification is important. A plugin appearing in the directory does not guarantee that every included tool or view works identically everywhere.

Local MCP applications illustrate the distinction. OpenAI says a local application can run through a plugin on ChatGPT Desktop. Saving that plugin to an account does not make its local tools available on web or mobile.

Site hosting addresses that limitation by providing a remote runtime. Even then, the plugin’s precise surface support depends on its included capabilities and current product availability.

The associated Site also has its own access model. A recipient may need permission to view the Site, permission to use the plugin, and authorization for any connected service.

Installing the plugin does not bypass those layers. Sharing a Site alone does not share the plugin, and sharing a plugin does not grant unrelated data access.

This separation protects against an easy but dangerous assumption. A tool being installable does not mean that it can read everything its creator can read.

Each user may need to connect an eligible account. When a Site accesses connected applications, visitors use their own connections and their existing permissions.

Consider a project dashboard connected to an issue tracker. The Site could show assigned issues and expose an update action. A recipient should only see records allowed by their issue-tracker account.

The same principle applies to document repositories, customer records, and internal handbooks. The Site supplies the interface and hosted tools, but the underlying service remains an authorization boundary.

This model creates a more practical route to personal and workspace tools. It also introduces a multi-layer troubleshooting problem when access fails.

A failed tool call might originate from the Site, the plugin connection, a workspace role, the underlying application, or the user’s provider account. Creators will need to test each layer independently.

The installation experience therefore represents real product progress, but not universal portability. OpenAI has unified the build and packaging flow while retaining distinct security domains.

Permissions Are the Product Boundary

The strongest feature of the new workflow is also its largest risk: a conversationally generated tool can perform real actions.

Creators must decide whether each tool only reads information or can modify it. A search operation and an update operation may appear beside each other, but they carry different operational consequences.

OpenAI instructs creators to review Site contents and tool behavior before sharing access. It specifically asks them to consider whether users should only read data or also perform write actions.

Write access can include changing a milestone, creating a record, sending information, or updating stored content. These operations require more scrutiny than a generated interface suggests.

A polished Site preview does not prove that its access rules are correct. It also does not prove that every input produces the intended server action.

Creators should test representative records, permission levels, missing data, invalid inputs, and denied actions. They should also verify results by opening the Site after a tool performs a change.

Enterprise controls add another layer. OpenAI says several plugin permissions can be managed independently, including using plugins, uploading plugins, creating plugins with MCP, sharing plugins, and publishing them to a workspace directory.

Some permissions are disabled by default in Enterprise environments. An administrator may need to enable the relevant role before a creator can publish a Site or share its plugin.

This design limits accidental distribution, but it can also make the feature appear inconsistent between accounts. One user might build and install a tool immediately, while another cannot see the required controls.

Public access deserves even greater care. The original social claim suggested that a creator could restrict a tool to selected people or share it with the world. Official documentation supports controlled workspace sharing and a separate public submission route.

It does not describe personal plugin sharing as universally open. Pro and personal-account users currently cannot invite other ChatGPT users directly to a Site-hosted plugin through a share link.

Business and Enterprise members can share with coworkers, subject to workspace permissions. Recipients need access to both the plugin and its Site, then must install and connect it themselves.

Public directory distribution follows another process. Developers submit a plugin for review, satisfy identity and permission requirements, and publish only after approval.

OpenAI’s review requirements require a real, publicly accessible MCP endpoint for remote submissions. Review can inspect tool schemas, security schemes, annotations, user data handling, and expected behavior.

The review guidance also distinguishes read-only, destructive, and open-world operations. Those classifications affect how reviewers understand a tool’s behavior and risks.

A tool cannot become read-only merely because its description calls it harmless. Its declared annotations and actual behavior must agree.

That standard matters for Site-generated tools as much as manually coded servers. Natural-language creation can reduce implementation effort, but it cannot replace an accurate security model.

The largest unresolved question is how reliably ordinary creators will recognize unsafe tool boundaries. Developers know that an apparently small update function can trigger downstream systems or expose sensitive fields.

Less technical users may focus on whether the workflow works. They may not inspect excess response fields, indirect side effects, or inconsistent authorization rules.

OpenAI’s managed workflow can provide guardrails, but the documentation still assigns testing responsibility to the creator. It tells owners to review tools, test sample data, and check results before sharing.

That makes governance the real adoption constraint. A useful tool needs both a clear capability and a defensible permission boundary.

ChatGPT MCP Server Use Cases Start Small

The best early uses are narrow workflows with obvious data limits, reversible actions, and results that users can inspect.

A team handbook is OpenAI’s clearest example. A Site can present the handbook while MCP tools let ChatGPT search its contents and retrieve relevant sections during a conversation.

This use case has a defined corpus and a relatively simple output. The creator can compare ChatGPT’s response with the underlying Site and identify missing or incorrect information.

A project dashboard provides a second pattern. Read tools could retrieve milestones, owners, blockers, or deadlines. A controlled write tool could update a milestone status after user confirmation.

That workflow offers visible verification. The user can reopen the dashboard and confirm that the requested record changed correctly.

Document finders offer another practical starting point. A Site could expose tools that search approved folders, return matching titles, and open records the current user can access.

These tools become more valuable when paired with good information organization. A personal or team knowledge workflow still depends on accurate source material, stable permissions, and clear retrieval boundaries.

Internal directories, launch calendars, and status reports also fit the model. Each can use a small tool set with bounded inputs and understandable outputs.

Higher-risk workflows require more caution. A tool that sends messages, deletes records, publishes content, changes permissions, or starts external jobs can produce consequences outside the Site.

Such actions should expose clear parameters and require appropriate confirmation. Creators should avoid combining broad data access with broad write authority in one early prototype.

The Site should also reveal enough state for users to verify results. A conversational confirmation is not sufficient evidence that an external action completed correctly.

This is where ChatGPT MCP server hosting differs from a conventional website generator. The output is not merely content or interface code. It can become an operational participant inside future conversations.

That creates a compounding effect. Once installed, the plugin can be selected whenever ChatGPT considers it relevant, or when a user mentions it directly.

Metadata therefore matters. Tool names and descriptions should make the intended scope clear. Ambiguous descriptions can cause the wrong tool to be selected or encourage unsuitable requests.

The managed environment also changes iteration. Creators can ask ChatGPT or Codex to add a new tool, revise an existing action, or change the Site’s interface.

Those changes are not automatically live. The owner must publish the Site again, then confirm that the plugin exposes the expected tool version.

This publication requirement creates a useful checkpoint. Teams can review changed capabilities before they reach users.

However, it also creates potential version confusion. A Site draft, a published Site, and an installed plugin may not always reflect the same expected behavior.

Teams should maintain simple release notes, named test cases, and an owner for each tool. Even a small internal plugin benefits from knowing which version users currently invoke.

The best first project is therefore not the broadest assistant imaginable. It is a focused workflow where the owner can answer four questions clearly:

• What information can the tool read?

• What can the tool change?

• Who can invoke it?

• How can users verify the result?

If those answers remain vague, faster deployment only brings uncertainty into production sooner.

Three Signals Will Show Whether Sites Changes MCP Adoption

The next test is not how many Sites get generated, but how many hosted tools become trusted, repeatable workflows.

The first signal is cross-surface reliability. OpenAI says the plugin directory is available on web, desktop, and mobile, while individual features can vary across those surfaces.

Watch whether Site-hosted tools behave consistently across each supported client. Consistent installation, authorization, tool selection, and output would strengthen the case for Sites as a general MCP deployment layer.

Persistent surface differences would weaken that case. Creators would still need to design separate expectations for desktop, web, and mobile users.

The second signal is workspace adoption. Business and Enterprise environments provide controlled sharing, but administrators govern the required permissions.

Watch whether organizations enable Site creation, MCP plugin creation, and workspace sharing for broad employee groups. Adoption beyond developer teams would show that conversational deployment addresses a genuine operational need.

Restrictive default policies would produce the opposite result. Sites might remain a prototype tool if security teams cannot confidently audit generated actions and connected data.

The third signal is public plugin quality. Private distribution and public publication are different paths, and directory submission includes formal review.

Watch for Site-backed plugins that graduate from personal experiments into approved public products. Their reliability, privacy disclosures, support practices, and user satisfaction will test the managed model under real demand.

A steady pipeline of approved tools would strengthen OpenAI’s claim that Sites can support more than internal demonstrations. Repeated permission failures or unclear tool behavior would expose the limits of prompt-driven deployment.

The remaining uncertainty is therefore practical, not conceptual. OpenAI has documented the build, host, publish, install, and share workflow. The mechanism is real.

What has not yet been established is how well it handles sustained traffic, complex authorization, operational debugging, and long-term maintenance across many creators.

For developers, the immediate move is to test one bounded workflow against the conventional self-hosted route. Compare setup time, permission clarity, error diagnosis, update control, and client coverage.

For enterprise buyers, the priority is governance. Review which roles can create tools, who approves write actions, how connected accounts behave, and what evidence users receive after changes.

For knowledge workers, the opportunity is direct. A useful internal dashboard or reference collection can now become a conversational tool without starting as a standalone infrastructure project.

The ChatGPT MCP server shift matters because deployment is moving closer to the request itself. The decisive question is whether teams can keep access, testing, and ownership equally close. Choose one narrow workflow, define its boundaries before building, and test it with users who hold different permissions. That evidence will reveal whether Sites is merely faster hosting or a durable new route for creating AI tools.