Suppose I want Codex to check the latest OpenAI documentation every time it changes an API integration.
I can keep adding a sentence to the prompt: “Check the docs first. Do not rely on memory.” That is fine for a few jobs. Eventually the rule grows teeth. Which documentation should it use? What should it compare? Which compatibility boundaries are off-limits? What verification should run before the change is handed back?
That is where a Skill starts to earn its keep.
OpenAI’s Agents SDK repositories use Skills in much the same way. implementation-strategy helps establish compatibility boundaries before implementation, code-change-verification covers changes to SDK code, tests, examples and build behaviour, and openai-knowledge makes current documentation part of the workflow when the task touches OpenAI APIs or platform integrations.[3]
The interesting part is that openai-knowledge does not carry a private copy of the documentation inside the Skill. When current docs are required, the workflow reaches them through the official Docs MCP path.[3]
That single example already separates two jobs which are often blurred together.
Put repeatable working habits in a Skill
Agent Skills in Codex are folder-based. A Skill starts with SKILL.md and can bring supporting scripts, references and assets with it. A user can invoke one explicitly, or Codex can select one when the task matches.[1]
my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/I find it more useful to think of a Skill as a working method than as a larger prompt.
Good candidates are things such as:
- checking compatibility before an API change
- running the same verification after a class of code edits
- keeping documentation and source changes in sync
- enforcing release checks which are easy to forget
- producing a consistent PR handoff
OpenAI’s own repositories follow that pattern. Codex can see that Skills exist without loading all of them into the working context; once a Skill is selected, it reads SKILL.md and only reaches for references or scripts when the procedure needs them.[3]
That progressive disclosure matters. A repository can carry several specialised procedures without paying the context cost of every procedure on every task.
A one-off instruction does not need this machinery. If there is no stable procedure, no supporting material and no repeat use, turning the request into another named Skill mostly creates something else to maintain. OpenAI’s January 2026 deprecation of Custom Prompts pointed reusable instructions and workflows towards Skills for the same reason.[2]
MCP is about reaching capabilities outside the procedure
Return to openai-knowledge.
A Skill can say:
Before changing an OpenAI API integration,
check the latest official documentation.The rule does not magically provide the current documentation. The external capability still has to come from somewhere. That is the MCP side of the picture.[3]
It is tempting to compress the distinction into “Skills are instructions, MCP is tools”. That is easy to remember and technically too narrow. The 26 March 2025 MCP specification allows servers to expose resources, prompts and tools.[6]
An MCP server may therefore provide context to read, parameterised prompts to discover, or actions to invoke.
My working rule is simpler. If the missing piece is “how should we handle this class of work?”, I look at a Skill. If the missing piece is “how does this workflow reach an external capability through a standard interface?”, I look at MCP.
The two can work together, but neither depends on the other.
Tool Search solves a different problem: too many tools to preload sensibly
As the number of connected capabilities grows, another problem appears. Should the model receive the complete definition of every possible tool before it has decided which one it needs?
GPT-5.4 introduced Tool Search on 5 March 2026. OpenAI described the change in concrete terms: instead of placing every tool definition in the prompt up front, the model can receive a lighter list of available tools and retrieve a full definition when it needs that tool.[8]
That addresses discovery cost. It does not establish the MCP connection, and it does not grant permission to execute an action.
An MCP server may already be available while the model has not yet selected the relevant tool. Tool Search can help it find the right definition in a large catalogue. Finding the tool still does not prove that the action is authorised, nor that the call succeeds.
By the end of April, a useful operating picture was therefore:
Integration / MCP configuration
↓
Connection available
↓
Discover or search the relevant capability
↓
Select the action
↓
Approval if this action requires it
↓
Execute
↓
Check the returned resultThis is not an official fixed Codex pipeline. It is a way to stop several states being collapsed into one. Codex already exposed custom MCP approval handling by this point, so “the model can find this tool” and “this action can run without another decision” were clearly different claims.[7]
That missing distinction is the one I care about most in larger tool setups: MCP brings a capability into reach, Tool Search helps the model find the relevant tool, and authority plus execution still have their own boundaries.
Do not add MCP just because something is external
A workflow may already have a perfectly good route to the data or action it needs.
If the existing path is sufficient, inserting another MCP server simply to make the architecture diagram look tidy adds another dependency, another authentication path and another place to fail.
MCP becomes useful when you genuinely want a standard client/server interface for that capability, or when the target service already exposes an MCP server as the sensible integration surface.
The history makes the same point. Codex could work with MCP before Plugins existed; OpenAI’s Codex for Linear material already described a local Codex setup reaching Linear through MCP in December 2025.[7]
So this is a misleading mental model:
Plugin → Skill → MCPA Skill does not have to use MCP. MCP does not need to live inside a Plugin.
Package the setup when it needs to travel
I would usually think about Plugin later.
If a Skill works, the integration is connected, and the setup belongs to one person or one repository, there is no urgent reason to package it.
Codex Plugins, introduced on 25 March 2026, could bundle Skills, app integrations and MCP server configuration into one installable package.[4]
my-plugin/
├── .codex-plugin/
│ └── plugin.json
├── skills/
├── .app.json
├── .mcp.json
└── assets/The format becomes useful when the real problem is reproducibility: another developer should be able to install the same setup, or another repository should be able to recreate the same collection of capabilities without a hand-written onboarding ritual.
Packaging a setup which still changes every day tends to create more syncing than it removes. I would wait until the capability is reasonably stable and distribution has become an actual problem.
Installed is not the same as used
This is more important than memorising the product labels.
Seeing a Plugin in the interface proves very little about a specific task. An underlying app or MCP connection may still be unavailable, workspace controls may block it, and an action may still cross an approval boundary. Enterprise and Edu release notes already documented workspace app controls affecting Plugins, while Codex exposed approval handling for custom MCP actions.[5][7]
So I would not treat one green state as completion evidence.
If the claim is “Codex checked the latest docs through MCP”, I want to see the lookup result. If the claim is “Codex performed an external action”, I want evidence of that call and its return. Installed, connected, authorised and executed are different things.
Take the API-integration example from the beginning. A task may select a Skill because of the work it is doing. The Skill may require a current-docs lookup through Docs MCP. If the catalogue is large, Tool Search can reduce the cost of carrying every definition in context. If an action crosses an approval boundary, the normal approval rules still apply. The workflow then returns to the code, tests and handoff.
Plugin sits on a different axis. It matters when that whole setup needs to be installed somewhere else.
There is no need to memorise four product nouns as a stack. When a workflow starts to feel awkward, ask what is actually missing: a repeatable procedure, a standard path to an external capability, a way to find the right tool in a large catalogue, or a way to distribute the whole setup. Fix that layer first.
References
- OpenAI, ChatGPT & Codex changelog: Agent skills in Codex, 19 December 2025.
https://developers.openai.com/codex/changelog - OpenAI, ChatGPT & Codex changelog: Custom prompts deprecated / Team Config, 22 to 23 January 2026.
https://developers.openai.com/codex/changelog - OpenAI Developers, Using skills to accelerate OSS maintenance, 9 March 2026.
https://developers.openai.com/blog/skills-agents-sdk - OpenAI, ChatGPT & Codex changelog: Build and install plugins in Codex, 25 March 2026.
https://developers.openai.com/codex/changelog - OpenAI Help Center, ChatGPT Enterprise & Edu Release Notes: Plugins in Codex, 26 March 2026.
https://help.openai.com/en/articles/10128477 - Model Context Protocol, Specification revision 2025-03-26: Overview / Resources / Prompts / Tools.
https://modelcontextprotocol.io/specification/2025-03-26/index
https://modelcontextprotocol.io/specification/2025-03-26/server/resources
https://modelcontextprotocol.io/specification/2025-03-26/server/prompts
https://modelcontextprotocol.io/specification/2025-03-26/server/tools - OpenAI, ChatGPT & Codex changelog: Codex for Linear / custom MCP approval panels, 4 December 2025 and 1 April 2026.
https://developers.openai.com/codex/changelog - OpenAI, Introducing GPT-5.4: Tool search, 5 March 2026.
https://openai.com/index/introducing-gpt-5-4/