Plugins, MCP, Skills and Connectors: Choosing the Right Layer

Other units in this course look separately at repository instructions, Skills, hooks, the Model Context Protocol (MCP) and subagents in two ecosystems. Now it is time to see how these pieces fit together, and why similar names in different products do not mean the same behaviour.

Imagine the request: "The agent should check a Jira issue and the linked pull request (PR), compare them with the acceptance criteria and report whether the PR can be merged." That may require access to Jira and GitHub, a review procedure and, possibly, a way to share that procedure with the team. These are four different needs. A single plugin will not necessarily meet all of them.

By the end of this unit the reader will be able to separate a technical capability from a permission and from knowledge of a procedure, will understand the lifecycle of an integration, and will be able to choose the smallest mechanism that is sufficient. It assumes basic familiarity with CLAUDE.md, Claude Code rules, Claude Skills, Claude subagents, Claude agent teams, Claude hooks, MCP in Claude Code, AGENTS.md, OpenAI Skills and Codex subagents. The names of specific surfaces and versions below are marked as checked as of 24 September 2026.

Four different questions that are easy to confuse

A host is the application that runs the interaction with the model and gives it tools. A tool is a machine-executable operation with a name, arguments and a result. A Skill is a package of instructions for a repeatable procedure; a plugin is a way to group and distribute components. Connector or app is the product name for an integration with an external service.

When choosing a mechanism, give four separate answers.

Question	What we are looking for	Example
Capability	Which action or data can the host reach?	Read the description of a Jira issue and the current diff of a PR
Permission	Who can do it, on behalf of which account, and within what limits?	The user has read access to the project; writing a comment is forbidden
Procedure	Which sequence of steps produces a useful and verifiable result?	Compare the issue's criteria with the files in the diff and name the missing evidence
Packaging	How is the configuration and procedure bundled and distributed?	A team plugin containing a Skill and a connection to the service

These layers correspond to different mechanisms. An application programming interface (API) defines how one program calls another. MCP (a protocol for connecting context and tools to a model application) standardises part of the interaction between a host and a server. The particular host decides how calls are shown and controlled, and the names "connector" and "app" depend on the product.

In a given product these roles can overlap: a plugin can contain a Skill and an MCP configuration. But the word "plugin" does not mean it necessarily contains a server, and the word "Skill" does not mean it has access to an external system.

Skills are explained in detail elsewhere for both Claude and OpenAI, MCP for Claude Code, and Codex subagents separately. We do not repeat how to build these components here. Instead we work out when to combine them, which permissions are required, and where exactly the combination will work.

Capability is not permission

The model may see a tool's description, yet the call can still be forbidden by host policy, by a user confirmation step, by the workspace or by the external service. An MCP server may advertise a write tool while the user's request only has read access. A Skill may demand that a PR be merged, but the text of the procedure does not grant that authority.

The reverse is also possible: the account has access, but the agent does not know how to use it properly. For example, a GitHub token allows reading a PR, but a proper review still has to compare the diff with specific criteria, separate fact from assumption, and check the HEAD (the current commit of the branch) to which the evidence belongs.

So check two independent things: whether the system can perform the action, and whether this particular call has the right to it. Then separately check a third: whether the procedure provides enough steps for the result to be correct. This distinction underlies every example below.

Tool, API, MCP and connector are not synonyms

A tool is an operation available to the host, with a name, arguments and a result. For example, a tool might find an issue by its key or read the list of files in a PR. The description and the argument schema help the model decide which call to propose. They do not by themselves guarantee that the server will check every business condition the way the user expects.

An API is a broader programming contract. In a typical function-calling example, the model returns a function name and arguments, and the developer's application code decides how to perform the action and return the result to the model. Declaring a function in the API does not create access to Jira or GitHub unless the application's author has implemented that connection and configured the credentials OpenAI on function calling.

MCP is an open integration protocol, not a separate cloud service or a permission. In its model, the host manages clients, a client connects to a server, and the server can expose tools, resources or prompts. A tool is meant for invoking an operation; a resource provides data; a prompt can be an interaction template. Individual host products support different sets of primitives and transports, so a capability existing in the specification does not prove that every client exposes it MCP, specification 2026-07-28.

When a host connects a remote MCP server, it can fetch the list of available tool definitions and forward selected calls to the server. At execution time the server must validate the arguments and apply its own authorisation model if its data or operations require it; the protocol itself does not impose one login method on every integration. MCP does not prove that a server is safe, and a tool description is not a trusted instruction.

"Connector" or "app" is mainly a product-interface term. In OpenAI's current integration management, the name "app" covers a connected service or an MCP server; users see whether the integration is available and which actions are allowed on their surface. In Claude chat, "connector" often refers to an integration with a service or a remote MCP server. This is not the same as the protocol term "client": in the MCP specification, a client is a component inside the host that talks to the server managing apps and connectors in OpenAI, Anthropic's MCP overview.

A connected service does not necessarily use MCP in every implementation. An integration may call the vendor's API directly or use an internal adapter. Do not infer the protocol just because a menu says "app" or "connector".

A Skill defines the process, a plugin packages the components

A Skill holds the instructions by which a host tries to carry out repeatable work: when to apply the process, which sources to read, in what order to act, what to check and what report to return. Its text may refer to tools, but it does not create those tools, a user account or network access. The verified format and limits of Skills are described in Claude Skills, OpenAI Skills and the OpenAI Skills documentation.

A script can implement a step whose result is precisely determined by code: comparing two manifests or checking a data structure, for example. If the action needs access to a service, the script also becomes part of the security surface: its input parameters, files, permissions, network addresses, dependencies and side effects all matter.

A plugin is a way to bundle and distribute configuration that is compatible with a particular ecosystem. Under OpenAI's current Agent Plugins schema, a package can contain Skills, an MCP server, resources and optional hooks; hooks run only in a supported Codex runtime, and a package being listed in the web catalogue does not install local scripts. Claude Code plugins have their own manifest and can package Skills, subagents, hooks, MCP servers, Language Server Protocol (LSP) servers and settings. The components OpenAI's importer accepts from a Claude plugin are not the same as everything a Claude manifest can describe: the official converter turns commands and agent procedures into Skills, hooks have to be adapted to the Codex runtime, and some Claude-specific settings are dropped. So check what was actually carried over OpenAI plugin architecture, OpenAI packaging format, Claude Code plugins, converting a Claude plugin for OpenAI.

A manifest is a structured description of a package from which the host learns its name, components and settings; in these examples the manifests are JSON (JavaScript Object Notation) files. The current portable Agent Plugins format has a root <code>plugin.json</code>, a <code>skills/</code> directory and, if a server is needed, <code>mcp.json</code>; OpenAI-specific fields can be declared separately under <code>extensions.com.openai</code>. When this root overlay is present, its OpenAI fields replace the legacy overlay in <code>.codex-plugin/plugin.json</code> rather than being merged with it. The older file remains a compatibility fallback. Claude Code, by contrast, uses <code>.claude-plugin/plugin.json</code>, and its MCP configuration may live in <code>.mcp.json</code>. OpenAI's documentation explicitly supports a separate import path for a Claude manifest, but that is a conversion with rules and limitations, not a promise of identical execution in every product OpenAI: packaging a plugin, Claude Code: plugins, converting a Claude plugin for OpenAI.

When importing a Claude plugin that includes an MCP server, OpenAI requires a stable public HTTPS address for the server using Streamable HTTP. If the server is local, it has to be deployed at such an address; where that is not possible, the documentation suggests getting in touch about local MCP support. An MCP connection that is already registered is not carried over by simply copying a link. Compare the original and converted packages and check separately which components and settings were actually transferred guide to importing a Claude plugin.

OpenAI's GitHub repository provides a concrete, pinned example: at commit <code>1dc195897af4161d039b80d8471ec0a10c9bbc89</code>, the GitHub package has <code>.codex-plugin/plugin.json</code>, refers to <code>.app.json</code> and declares interface metadata. This is the compatible layout of one particular Codex example, not proof that the same folder can be imported by Claude Code or any other host GitHub plugin manifest in openai/plugins.

An example package shape is not a universal schema

An imaginary package directory might contain short instructions, a separate MCP configuration and reference files. This is only an illustrative structure:

team-review-package/
  <a manifest the chosen host understands>
  skills/
    evidence-review/
      SKILL.md
      references/
  <optional MCP configuration, if the host supports it>

Before creating or installing a package, check its official schema, its distribution channel and whether the specific host supports each component. Do not copy file names from another ecosystem, and do not assume that a server will start just because its description sits in the package.

The product and the surface define the meaning

The same word can point to different levels. ChatGPT, Codex and the OpenAI API are three different products. Claude chat, Claude Desktop, Claude Code and the Anthropic Messages API also have different models of connection and execution. Behaviour has to be confirmed for the specific combination of product, host and version.

Surface	What the mechanism means here	Where the important boundary lies
ChatGPT app / connector	A connected service that can be used in chat within the available actions	Availability in the workspace, account connection, user roles, action confirmations and administrator rules can all restrict the capability
OpenAI plugin	A package that can combine Skills, an MCP server and other supported components	The documentation describes plugins in Chat and Work in ChatGPT on the web, desktop and mobile, in Codex desktop and in the CLI (command-line interface) plugin browser; the IDE (integrated development environment) extension does not support plugins. Individual components have narrower compatibility
Codex runtime hooks	Event automation in the Codex environment, including ChatGPT Work	They work only if the script is available in the runtime and its definition has been approved; hooks do not run in ordinary ChatGPT Chat
OpenAI API	Declared functions, built-in tools or MCP connections in a specific API request	The developer's application is responsible for its own function code; a remote MCP server has its own server, authorisation and approval policy
Claude connector in chat	A connection to a built-in integration or a compatible remote server	The organisation may require prior configuration; the user may separately connect or enable the connector
Claude Code plugin / MCP	Local or team components of Claude Code with their own settings and permissions	Repository trust, the plugin's source, the type of transport and the invocation rules each matter separately
Anthropic Messages API	An API feature for working with compatible remote MCP servers	The API client manages the OAuth (Open Authorization, a standard for delegated authorisation) token and its refresh; the current API connector supports tool calls, not the full set of MCP capabilities

This is deliberately not a catalogue of plans or buttons: availability depends on the plan, region, organisation settings, sign-in method and current version. OpenAI's plugin catalogue is shared between ChatGPT and Codex, but the documentation separately defines the surfaces where a package works and where each of its capabilities is available. In particular, plugins are described for Chat and Work in ChatGPT on the web, desktop and mobile, and in Codex desktop and the CLI plugin browser; the IDE extension does not support plugins. Hooks run only in the Codex runtime, including ChatGPT Work, when the script is available in the environment and the hook definition has been approved; ordinary ChatGPT Chat does not run hooks OpenAI plugin architecture, packaging plugins and hook requirements, managing plugins in a workspace, importing a Claude plugin. The ChatGPT documentation describes managing custom MCP apps and their confirmations separately from built-in integrations; Anthropic's documentation distinguishes cloud connectors, local MCP in Desktop, Claude Code servers and the API connector ChatGPT developer mode and MCP apps, connecting MCP in Claude Code, Claude Messages API MCP connector.

A shared public catalogue does not mean a package works the same way on every surface, and local and team catalogues may differ. Check the specific component you need: installing a plugin does not prove that its Skill loaded, its MCP server connected or its hook has a script available in the runtime.

In Claude Code, a local server using standard input/output (stdio) is started as a local process; a remote connection works over a network transport. That differs from a Claude chat custom connector, which reaches the server from Anthropic's infrastructure and needs an externally reachable endpoint. In the Claude Messages API, the developer's application supplies the required authentication data and manages the token lifecycle. Do not carry the properties of one of these paths over to another Claude Code MCP, custom connectors in Claude, Messages API MCP.

Support was checked against the current documentation available on 24 September 2026. Before rolling anything out, check the client and the components again: one plugin appearing in the catalogue does not mean its MCP server, Skill, app or hook will work on every surface. In particular, do not confuse plugins in Codex desktop with support for plugin packages in the IDE extension; a separately configured MCP server may have its own rules managing plugins in a workspace, packaging plugins and hook requirements.

From discovery to a verified result

Be precise about the surface on which a plugin with hooks is being installed: the current OpenAI packaging documentation names lifecycle hooks for plugins installed manually in Codex desktop. That is narrower than the general support for Codex runtime hooks in ChatGPT Work and Codex. Do not conclude that every plugin from the catalogue carries or runs its hooks; nor does a web installation deploy scripts into the runtime.

The word "installed" compresses several different states. For reliable diagnosis, walk through this sequence:

1. Discovered. A person or the host knows that the package, app or server exists. That does not yet mean it is in this user's catalogue.
2. Installed or configured. The package files are in the right place, or the host has received the server's address. For an app, this does not necessarily mean an account has been connected.
3. Allowed by policy. The user or administrator has allowed the relevant category of use. An organisational rule can forbid a component that the user can see locally.
4. Connected and authenticated. The network is reachable, the server responds and the required identity has been verified. For a server without authentication this step looks different; MCP does not require one global login method.
5. Invocable. The Skill was found by its description or invoked by the user; the tool is listed by the host; the action is not blocked by policy or by a missing tool.
6. Executed and verified. The call returned a result; the agent checked its completeness, date, the relevant revision and any side effect.

This is a diagnostic model, not a status system shared by every product. For example, a "connected" label may mean that OAuth authorisation was obtained, but not that a particular tool is available in this chat. The list of MCP tools can also change after connection. MCP includes mechanisms through which a server can announce changes to the list; so trusting an endpoint is a long-term decision, not a one-off check of a manifest MCP specification 2026-07-28, MCP security.

Permissions form several independent checkpoints

In a typical integration call, the decision may depend on:

• whether this product and connector are available to the user;
• whether the correct external account has been authorised;
• which data and operations its access covers;
• whether the host allows the specific tool;
• whether a confirmation has to be shown before data is sent or written;
• whether organisation policy lets the request through;
• whether the server checks authorisation again on its own side.

This is not redundant duplication. For example, the host may forbid using an MCP server altogether, while the server may refuse a deletion for an account that only has read access. Do not rely on one broad "trust in the plugin" as a substitute for checking each level. Current OpenAI and MCP guidance emphasises least privilege, consent, input validation and treating tool results as potentially untrusted OpenAI: plugin security, MCP: security best practices.

Three worked examples of choosing a layer

Example 1: reviewing a Jira issue and a PR without merge rights

Situation. A team wants an agent to check whether a PR meets the Jira requirements and to return findings with evidence. For this teaching example, both connections provide read access only.

Problem. The request "check Jira and the PR" does not by itself provide a way to find the issue, read the diff or tell whether the PR changed after the review. And access to the services does not tell the agent how to distinguish a blocker from a question for the author.

Options. If the working host already has permitted Jira and GitHub apps, a new MCP server adds nothing useful. If the task is a one-off, a clear prompt is enough. If this kind of review is a routine team process, it makes sense to describe the repeated steps in a Skill. If other users need a shared installation, you can consider a package that distributes the Skill and the necessary configuration; that is justified only if the chosen host supports such a combination.

Solution. The team keeps the permitted read-only apps as the data source and adds a Skill that describes the sequence:

1. Get the exact Jira issue key and the exact PR identifier.
2. Read the current criteria and the PR's current HEAD; record their identifiers in the report.
3. Read the diff, the relevant files and, if available, the results of checks that were actually run.
4. For each criterion, state the evidence, partial coverage or lack of evidence. Each finding must have a file/line or another verifiable reference, a condition and a consequence.
5. Return PASS (checked, no blockers found), MUST-FIX (a required fix before merging) or PENDING EVIDENCE (conclusion deferred for lack of evidence), according to the team's local scale. If HEAD changed during the review, recheck the diff and checks before concluding.
6. Finish with reading and reporting. This Skill does not write a Jira comment, approve the PR or merge it.

Result. The agent returns a "criterion → evidence → result" table and the exact SHA (Secure Hash Algorithm; here, the commit hash) of the HEAD that was checked. If it has no access to the checks, it marks this as PENDING EVIDENCE rather than assuming a green build.

Hypothetical data and observed result. In the fictional teaching PR demo-17 at HEAD 4f12c8a (an abbreviated, made-up commit reference), the changed file src/jira-review.ts contains a call to GET /issues/{key}; no write to Jira is visible in the reviewed diff. For the narrow criterion "this diff adds no Jira write", the conclusion is PASS. The CI (continuous integration) status and the behaviour of unchanged code were not provided, so for those the conclusion is PENDING EVIDENCE.

Why it fits. The system already has the necessary read capabilities, so the team does not build an unnecessary server. The Skill adds procedural knowledge that is not in the tool descriptions.

Limit. The Skill does not revoke or restrict the permissions of the external service. To actually forbid writes or merges, you need read-only access at the provider or a matching host policy. The words "do not merge" are not, by themselves, a technical control.

Example 2: a release Skill exists, but there is no production access

Situation. After review, a team release Skill has been installed that describes preparing a release of a football statistics website: freeze the changes, check the release notes and collect the required evidence. A real production deployment requires a separate account with the appropriate role; the current environment does not have it.

Problem. The instructions contain the step "run the production deployment". That does not mean the agent can see the relevant button, key, cloud account or execution right. Having the Skill, and invoking it successfully, is not evidence of a release.

Options. You can safely prepare the materials and hand them to an authorised release manager. You can ask an administrator to grant the minimum necessary temporary access under an agreed procedure. What you must not do is substitute a written promise for the missing access, or pick up a stray production secret from the repository.

Solution. The Skill splits the work into preparation and the external action. The agent checks the available release notes and the actual results of pre-production checks, drafts a short plan with the version and exact commit, and then explicitly stops at the deployment step. Its report says: "Materials prepared; production deployment was not run because there is no confirmed access." It does not infer success from the absence of an error.

Result. The team gets a ready package of verified evidence and a clearly marked boundary. An owner with permission can carry out the deployment and then pass the agent a URL (Uniform Resource Locator) or release identifier for independent verification.

Hypothetical data and observed result. In this fictional teaching package, the release notes name version v1.4.0, and the pre-production report has status PASS for commit a7c219e (an abbreviated, made-up reference); there is no production deployment identifier. So what is recorded is that the materials are ready and the check result applies only to that commit; the production deployment is neither confirmed nor declared done.

Why it fits. This process keeps useful automation where access really exists and does not hide a missing permission.

Limit. If the host does not even have read access to the release data, the Skill cannot prepare verified materials from it. It should ask for safe evidence or mark the unknown, not invent the state of production.

Example 3: moving a workflow from Claude Code to Codex

Situation. A team has a Claude Code Skill for reviewing data migrations and wants to use the same procedure in Codex.

Problem. A file named <code>SKILL.md</code> may be understandable to both systems at the level of text, but its frontmatter, discovery paths, invocation rules, MCP configuration and hooks do not necessarily have the same semantics. Moving just the directory can silently lose an important condition or change permissions.

Options. You can keep the workflow text in a shared neutral document and write a thin adapter for each host. Or you can maintain two separate Skills that point to a single set of rules. If installation and versioning together with configuration are needed, the team can package the adapters separately as a Claude Code plugin and a Codex/OpenAI plugin. The last option increases maintenance cost and is not something every team needs.

Solution. The team looks at the supported path for converting a Claude plugin to OpenAI, but compares the output package with the input before using it: the converter may turn useful commands and agent instructions into Skills, adapt some hooks, and fail to carry over the MCP configuration or certain settings. The team moves the content of the procedure separately from the configuration:

• keeps the shared review criteria, risk classification, evidence format and stop conditions in a neutral Markdown document;
• checks how each host discovers the Skill and whether it supports the fields used;
• replaces host-specific mechanisms, such as a Claude Code slash command or allowed-tools, with confirmed Codex mechanisms, and flags anything unknown for a manual decision;
• configures the connection to the Git service, its authentication and permissions separately, without carrying over tokens or configuration secrets;
• reruns the set of positive, negative and edge-case test requests on both surfaces and compares the conclusions with the expected set of evidence.

OpenAI's official importer has explicit conversion rules: Claude commands and agents can become Skills; hooks need adaptation and trust in their code in a supported environment; some product-specific settings, server declarations or formats are not carried over automatically. It is a useful migration path, but its result has to be checked component by component OpenAI: submit a Claude Code plugin.

Result. The team has the same review logic but two verified adapters. Each has its own record of the host version, discovery path, available tools and actual test results. "The file was copied" is no longer presented as evidence of full compatibility.

Why it fits. Procedural knowledge can be reused without merging it with product syntax and permissions.

Limit. If the two systems manage invocation, permissions or MCP differently, a neutral document does not remove that difference. The official import does not preserve every Claude plugin component: for example, some settings and local integrations need to be redesigned by hand. The adapters may need to behave differently, and sometimes the right decision is to keep this procedure available on only one surface.

Evidence of incompatibility: a specific report, not a universal law

A GitHub issue for Claude Code described a case where a plugin from a third-party marketplace was installed, but its Skills, commands and agents were not discovered in version 2.1.76, the version the reporter stated. A practical write-up by another author recorded a similar limit in Claude Code 2.1.224: a package with a portable-root <code>mcp.json</code> exposed the Skill, but the MCP tool did not appear until the author adapted the configuration to the file Claude Code expects. These are the results of specific tests, not proof of how every plugin behaves now; they show why you should test the full set of components after an import Claude Code issue #38670, practical report on a portable plugin layout.

How to choose the smallest sufficient solution

Start from what is missing:

If what is missing is…	First consider…	Do not assume…
A one-off explanation or plan	A prompt and the sources available in the session	That every request needs a Skill
A repeatable procedure with the same evidence	A Skill or a short workflow document	That text will automatically make an API call
Access to external data or actions	An app/connector that is already permitted, or an existing tool	That you need to build your own server
A standardised connection to a service	MCP, when the specific client and server support it	That the protocol automatically provides authentication and the right role
A deterministic check	An existing test or a small, controlled script	That a natural-language instruction is more reliable than an exact code check
Repeatable team installation of components	A supported plugin or marketplace	That any plugin works the same way in Claude, ChatGPT, Codex and the API

The smallest sufficient solution does not mean "use less security". It means not creating a new mechanism where a permitted existing tool already meets the requirement. If there is no integration, first confirm the exact need, the owner of the access, the data source and the limits on writing. Only then decide whether you need your own implementation.

Supply, trust and updates

A plugin may be nothing more than a package of instructions, or it may contain executable code, hooks or a remote server configuration. Before installing one, check:

1. Origin. Who the author is, which repository/tag/commit the package comes from, who publishes it and whether they have the right to distribute the files it contains.
2. Code and configuration. Read the scripts, hooks, launch commands, server addresses and connection configuration, and see which files or environment variables they read.
3. Permissions. Which reads and writes are possible, on whose behalf the server will act, and whether a narrower scope can be granted. Avoid keys that give far broader access than needed.
4. Side effects. Whether a call can create, edit or delete records, send data to third parties, run a shell or perform a release.
5. Change over time. Whether the package updates automatically; whether an update can change the instructions, the endpoint, a dependency or the list of available tools; and whether the review is repeated afterwards.

Popularity in a marketplace does not replace checking the source. A tool description and text from a document can contain untrusted data or an attempt to influence the model. Treat them as input data; do not hand over secrets just because a tool or Skill asked for them. Official OpenAI and MCP guidance recommends minimising access, checking instructions and arguments, requiring explicit approval for sensitive actions and keeping dependencies up to date OpenAI: security and privacy, MCP: security best practices.

A Skill can name a required check, but that does not turn it into enforcement. Even the rule "never send customer data" will not stop a script with network access if the permissions and runtime allow it. A guaranteed restriction needs the appropriate host rules, account access controls, server-side authorisation or network controls.

Disabling and revoking are different operations

Leaving a workflow involves several possible actions:

• disable the plugin in the host while leaving it installed;
• delete the package or remove its source so that it is no longer found during discovery;
• disconnect the app in the host;
• clear the local cache or the OAuth token of a particular client;
• separately revoke the account's access at the external provider;
• ask an administrator to change organisational roles or policies.

These steps are not interchangeable. Deleting a Skill removes instructions; it does not by itself revoke GitHub or Jira credentials. Disabling a plugin does not necessarily cancel OAuth grants stored in the provider account or in another client. To stop future access, check tokens and authorisation at the provider as well, if its documentation requires it.

An operational exit plan is worth preparing before installation: record who owns the server endpoint, where scopes are administered, which user connected their account and how their rights are revoked. After removal, check from the relevant surface; the visible absence of a plugin does not prove that all tokens and integrations are gone managing apps in OpenAI, Claude Code MCP and authentication, managing Claude connectors.

Also take specific product behaviour into account: according to OpenAI's help pages, uninstalling removes the package, but a separately connected MCP server stays connected in ChatGPT until the user disconnects it. So check the state of both the package and the connection; removing one is not revoking the other OpenAI: managing plugins.

Summary

• A tool or API provides or describes a machine action; MCP standardises part of the communication between a host and a server; "app" and "connector" are names for a particular product integration.
• A Skill describes a repeatable procedure. It does not create access and does not force the host to carry out every sentence.
• A plugin is the packaging and distribution of components in a particular ecosystem's schema. Claude Code and OpenAI have different manifests, paths and lifecycles.
• Check discovery, installation, configuration, policy, authentication, invocation and the actual result separately.
• The smallest solution starts with a permitted existing tool and a reused procedure; your own plugin or MCP server is needed only when there is a specific gap.
• Removing a package does not prove that external credentials have been revoked. Plan updates and the termination of access separately.

Sources and further reading

Product pages and the specification that may change were checked on 26 September 2026. OpenAI's official rules for packaging, importing and managing MCP connections were rechecked on 10 October 2026.

1. OpenAI, Skills and plugins, current documentation, accessed 2026-09-26. Supports the distinction between a Skill as instructions and a plugin as a package, and the boundaries between ChatGPT and Codex surfaces.
2. OpenAI, Plugin architecture, current documentation, accessed 2026-09-26. Used for the composition of a plugin, its separate components and the choice between Skill-only, MCP-only and a combination.
3. OpenAI, MCP server concepts, current documentation, accessed 2026-09-26. Explains host, client and server, and tools, resources and prompts.
4. OpenAI, Package plugins, current documentation, accessed 2026-09-26. Supports the manifest and component schema, hook execution in the Codex runtime (including ChatGPT Work), the requirement for an available script and separate hook approval.
5. OpenAI, Function calling, current documentation, accessed 2026-09-26. Supports the distinction between the model declaring a function call and the application code executing it.
6. OpenAI, Apps and connectors for workspace administrators, current documentation, accessed 2026-09-26. Used for the terminology of apps, MCP servers, actions and policy, and for the current list of surfaces where workspace plugins are available, including the IDE extension limitation.
7. OpenAI, Developer mode and MCP apps in ChatGPT, current help article, accessed 2026-09-26. Supports the difference between custom MCP apps and built-in integrations, and the existence of confirmation controls.
8. OpenAI, Security and privacy, current documentation, accessed 2026-09-26. Supports the recommendations on least privilege, consent, input validation, secrets and dependencies.
9. OpenAI, Changelog, current changelog, accessed 2026-09-26. Used only as time context for the development of plugins and available surfaces, not as a stable compatibility guarantee.
10. Anthropic, Claude Code plugins, current documentation, accessed 2026-09-26. Supports the manifest and components of a Claude Code plugin and how it differs from standalone Skills.
11. Anthropic, Claude Code MCP, current documentation, accessed 2026-09-26. Used for local and remote servers, configuration and authentication in Claude Code.
12. Anthropic, Custom remote MCP connectors, help article, updated 2026-08-11, accessed 2026-09-26. Supports the behaviour of remote connectors in Claude chat and the difference from local configuration.
13. Anthropic, MCP connector for the Messages API, current API documentation, accessed 2026-09-26. Used for the limited API connector, tool calls and the client's responsibility for OAuth.
14. Model Context Protocol, Specification 2026-07-28, version 2026-07-28, accessed 2026-09-26. Supports the host/client/server roles, server primitives and the boundary between the protocol and a product implementation.
15. Model Context Protocol, Security best practices, current guidance for version 2026-07-28, accessed 2026-09-26. Supports treating inputs as untrusted, least privilege and the need for explicit consent.
16. Anthropic Claude Code, Issue #38670: third-party marketplace plugins cannot register skills/commands/agents, GitHub issue, opened 2026-03-25; report for Claude Code 2.1.76, accessed 2026-09-26. Used as a concrete example of possible incompatibility between a catalogue and a host, not as evidence of general behaviour.
17. OpenAI, Submit a Claude Code plugin to OpenAI, current documentation, accessed 2026-09-26. Supports the existence of Claude plugin conversion and the exact limits on transferring Skills, commands, agents, hooks, MCP and product-specific files; also explains the runtime, trust in hook scripts and the absence of hook handlers in ordinary ChatGPT Chat.
18. OpenAI, GitHub plugin manifest in openai/plugins, pinned commit <code>1dc195897af4161d039b80d8471ec0a10c9bbc89</code>, accessed 2026-09-26. Used as an example of a specific Codex-compatible layout, plugin metadata and a reference to its app configuration; not as a universal schema.
19. Marius Bughiu, How to Package Skills and an MCP Server as One Agent Plugin, 2026-08-17, accessed 2026-09-26. Read as limited personal evidence: an experiment with the same package in a portable layout and Claude Code 2.1.224; used only to explain why, after conversion, you should check that the host actually loaded both the Skill and the tool.
20. OpenAI, Plugins, help article, accessed 2026-09-26. Used for the difference between removing a plugin and separately disconnecting an MCP server in ChatGPT.