Host an MCP-backed plugin with ChatGPT Sites

Platform eligibility: the hosting article says hosting a plugin is available to all plans. Account rollout: the same article warns that DevDay features are gradually rolling out. Eligibility is not evidence that your account already has the controls.

There is a scope difference in the current sources: the general Sites overview describes Sites as a public beta for workspaces, Plus and Pro. This guide preserves the hosting article’s all-plan statement without promising universal access to Site creation. If Sites or the plugin controls are absent, check the account, surface and workspace settings before assuming setup failed.

The Sites overview describes creation in Work on ChatGPT web, or Work/Codex in the current desktop app. It excludes the Classic app. An individual plugin’s capabilities can have additional surface limits.

For a managed workspace, review Workspace settings → Permissions & roles. The plugin permissions list separates:

• Use plugins: permission to use them; documented as on by default for Enterprise.
• Upload plugins and Create plugins with MCPs: required alongside Use plugins for the Site-hosted creation path; documented as off by default for Enterprise.
• Share plugins: invitation/link access within the permitted workspace audience.
• Publish plugins to workspace: listing in the workspace directory.

Site creation and publishing controls are separate. Do not copy Enterprise defaults onto every Business workspace or assume a toggle publishes anything automatically. Check your effective role and the intended audience. Sites administration.

Open a Site you own, or coordinate with its owner. Decide what information the tools may read and what records, if any, they may change. Then ask ChatGPT or Codex to add an MCP server to that Site. Review its tools and test with sample data before publishing. Official hosting flow.

Original example prompt — not a tested integration:

Add MCP tools to this sample equipment tracker. Provide a read tool that lists equipment and a write tool that updates the inspection date for one named item. Use only the sample records. Explain the exposed inputs and results, and show how access is checked. Do not publish or share yet.

Keep the first task small enough to inspect: one known sample record, one expected read result and one reversible change. Ask the builder to explain where the data is stored and how each exposed action checks access. Tool names and parameters in your generated Site must be inspected; this example does not define an official MCP schema.

Do not confuse tools exported by a Site with a Site reading a visitor’s connected apps. The latter is a separate Business/Enterprise capability: the current Sites admin guide describes private-workspace, visitor-authorized, read-only access. It does not authorize writes to those external apps or background scheduled access. A tool that updates the Site’s own data is a different operation.

For initial plugin creation, the Site owner must publish. An editor adding tools or saving a preview does not complete that step. If the Site was already published before tools were added, the hosting instructions say to have its owner publish again.

Review the generated plugin card and its tools. You can also find plugins you created under Plugins → Personal → Created by you. A visible card is an inspection point, not proof that installation, connection or an action succeeded.

Owner/editor distinction: the general Sites collaboration guide allows an editor to publish later Site versions after the owner’s first publication. The hosting-specific troubleshooting instructions still direct the owner to publish MCP tool updates. Follow that owner-led path for this workflow; the general editor rule does not establish that an editor’s publication updates every associated plugin correctly.

Site ownership, Site editing, plugin editing, plugin installation, plugin sharing and workspace-directory publishing are separate abilities. Shared plugin access does not confer edit permission. Public Site publishing and workspace-directory publication also reach different audiences.

On the associated plugin card, choose Install, then complete the connection flow for your own account. Mention the plugin in a supported ChatGPT or Codex chat. Ask for a read result and compare it with the Site. If a write tool is included, use a sample record and open the Site to check the actual change.

The sequence is: plugin created → installed → connected → access and action checks satisfied → tool used → result verified. A successful earlier step does not prove the next one. Plugin installation and account connection guidance.

Installing a plugin does not automatically connect every included app, grant all Site information, or enable all write actions. The connected account needs the relevant source access; workspace roles and supported actions still apply. A colleague does not inherit the author’s connection.

App permissions control when an available action asks for approval; they do not grant provider access or replace workspace policy. Some actions can be denied instead of offering a prompt. Do not assume every action asks, or that one approval grants all future actions.

If the plugin is installed but disconnected, open its card and use Connect when shown. Finish the incomplete setup step with the intended account. If the wrong data appears, check account selection and permissions before asking the model to retry the same write.

The hosting article currently permits sharing with other members of a Business or Enterprise workspace. Recipients need plugin access plus Site viewer access. Each recipient installs the plugin and completes their own connection. Pro and personal-account users cannot currently share a Site-hosted plugin directly with other ChatGPT users through invitations or a share link. Sharing the Site itself is a separate action.

For the supported workspace flow: open the created plugin, choose Share, invite the intended coworkers, and grant Site viewer access when prompted. Give recipients the plugin link after reviewing the audience. The plugin sharing guide distinguishes sharing with people/groups or workspace-link access from publication to the workspace directory. Neither is public-directory submission.

Before inviting a colleague, use this original access worksheet:

• Which account will they use, and is it in the permitted workspace?
• Can that account view the intended Site?
• Can their role install and use this plugin and its required apps?
• Which of the exposed actions should that person be able to run?
• Have they completed their own connection and checked a sample result?

Viewer access is a prerequisite described by the hosting guide, not evidence that every generated write tool is appropriate for every viewer. Review the actual exposed tools and their authorization. Sharing grants neither plugin editing nor permission to publish it in the workspace directory. Separate Site and plugin controls.

AgentSkillsHub editorial checklist, synthesized for this workflow; this is not an OpenAI-required schema or evidence of a test we performed.

1. List every exposed tool and mark it read or write.
2. Record its intended input, expected result and affected data.
3. Use sample data with an obvious expected outcome.
4. Check who can access the Site and whether the selected audience is appropriate.
5. Check the builder’s and recipient’s workspace roles separately.
6. Test a denied action using an authorized test account that lacks the relevant access; confirm no change occurred.
7. Run one reversible sample write, then inspect the Site record itself.
8. After publication, inspect the plugin’s actual tool list.
9. Verify each recipient’s connection separately from installation.

For example, reading an inspection date should not silently update it. A write should affect only the selected sample record. These are editorial acceptance criteria you can adapt to the task.

Workspace action controls and app approval settings remain distinct from provider consent. Where a workspace offers action controls, check read/write availability and how newly introduced actions are handled. Treat returned documents and tool output as data, not instructions granting new access. Our MCP security checklist covers broader server authorization concerns.

Ask ChatGPT or Codex to modify the existing Site’s tools, review the change, and test it with sample data. Have the owner publish the Site again, inspect the plugin’s tool list and run the affected action. Saving the edit alone does not make the new action usable. Official update and troubleshooting instructions.

Use this diagnostic order instead of assuming a cache delay:

• No plugin: confirm MCP tools were actually added and the owner performed the required publication.
• Missing new tool: confirm the updated Site was republished and the owner’s connection is active; inspect the plugin tool list.
• Installed but disconnected: complete the card’s connection step.
• Colleague blocked: check plugin access, Site access, their installation and connection, and applicable app/workspace restrictions.
• Unexpected result: compare the Site record before and after the affected action. Stop repeated writes while the result is uncertain.

Record which step failed. “The builder finished” and “the tool changed the intended record” are different observations.

These are deployment and access distinctions, not performance rankings. A workspace-created app can itself point to an external server; the rows are not mutually exclusive product tiers.

Sources: plugin component choices, Sites hosting, and external MCP setup. The older developer-mode article describes its own workspace/web flow; do not transfer all of its surface restrictions to newer desktop-local plugins.

Plugin Extensions adds optional supported UI such as a sidebar or panel. Hosting determines where the MCP tools run. A Site-hosted plugin can include interactive views where extensions are supported; hosting alone does not create an extension or establish client support.