MCP vs Skills vs Automations

Codex is extensible in three ways, and the single biggest mistake is treating them as interchangeable. They answer three different questions:

• MCP answers "where does the agent get context and tools that live outside this repo?" — connect Codex to a database, an issue tracker, a design tool, or a docs service.
• Skills answer "how should the agent do this recurring task?" — a reusable, named method for a workflow you keep performing.
• Automations answer "when should that method run?" — a schedule (or trigger) layered on top of a skill.

The cleanest way to hold this: MCP is what the agent can reach, a skill is the method, and an automation is the schedule. They compose — an automation can run a skill that calls an MCP tool — but each solves a problem the others don't. Picking the wrong layer (stuffing a method into MCP, or scheduling a workflow that isn't reliable yet) is exactly how setups rot.

The rest of this lesson is a decision framework for choosing among them, plus the in-session surfaces Codex gives you to inspect each one.

The official rule is precise and worth memorizing: use MCP when the needed context lives outside the repo, the data changes frequently, or you want Codex to use a tool. Each clause is a separate trigger.

• Lives outside the repo — the truth you need isn't in your files. Open tickets in Jira, rows in a production database, a Figma design, current library docs. The repo can't tell Codex what an open bug says; an MCP server can.
• Changes frequently — anything you'd otherwise paste into a prompt and watch go stale. A snapshot of your schema rots; a live database MCP server is always current.
• You want Codex to use a tool — not just read data, but take an action through an external system (query an API, fetch a page, run a service-specific operation).

If instead the context lives in your repo — your architecture, your conventions, your build commands — that belongs in AGENTS.md, not an MCP server. And if you find yourself describing a procedure over and over, that's a skill, not MCP. MCP is the plumbing to the outside world; it is not where you put instructions.

You add a server with codex mcp add and inspect what's connected with /mcp in the TUI:

# stdio server (a local process Codex launches)
codex mcp add context7 -- npx -y @upstash/context7-mcp

# streamable HTTP server (a remote URL)
codex mcp add figma --url https://mcp.figma.com/mcp --bearer-token-env-var FIGMA_OAUTH_TOKEN

Servers are stored in ~/.codex/config.toml; /mcp in a session lists the active servers and their tools.

A skill is a reusable, named method — you teach Codex how to do a recurring task once, then invoke it instead of re-explaining every time. The signal that something should become a skill is simple and behavioral:

"If you keep reusing the same prompt or correcting the same workflow, it should probably become a skill."

Two triggers, both about repetition: a prompt you keep retyping, or a workflow where you keep making the same correction ("no, run the linter first," "always update the changelog too"). Those corrections are the method trying to become a skill.

Scope it with 2-3 concrete use cases. Don't try to write a general-purpose skill in the abstract — start from two or three real instances of the task you've actually done, and capture the method that covers them. A skill grounded in concrete cases is sharper and more reliable than one written speculatively.

Manage skills in-session with /skills (browse and use them). The discipline that keeps skills useful:

• Keep skills local while you iterate. Refine the method against real tasks on your own machine first. A skill that's still changing shape doesn't belong in a shared package.
• Package as a plugin to share. Once a skill is stable and you want your team to use it, package it as a plugin. Browse installed and discoverable plugins with /plugins.

Notice the boundary with MCP: a skill is instructions and method; MCP is reach. A skill can call MCP tools, but the moment you're writing down "how to do X," you're writing a skill, not configuring a server.

An automation runs a skill on a schedule (or trigger) without you in the loop. The defining line is the one to memorize:

"Skills define the method, automations define the schedule."

An automation has no method of its own — it fires a skill at a chosen time or event. Good candidates are recurring, low-judgment chores you'd otherwise forget: nightly commit summaries, a scheduled bug scan, release notes on tag, a CI-failure check that runs when a build goes red.

The hard rule — and the heart of this lesson — is sequencing: automate only after the manual workflow is reliable. The order is always:

1. Run the task by hand in a session until it works consistently.
2. Capture the stable method as a skill.
3. Only then wrap the skill in an automation with a schedule.

Skip step 1 or 2 and you've built a robot that reliably does the wrong thing on a timer, unattended, where no one is watching to catch it. An unreliable manual workflow doesn't get more reliable by being scheduled — it gets less visible.

  manual & reliable  ──▶  capture as SKILL  ──▶  schedule as AUTOMATION
   (you verify it)        (the method)            (the schedule)

Think of it as a ladder you climb in order: prove it works, name the method, then let it run on its own.

Put the three mechanisms side by side and the choice usually makes itself. Ask the questions in order:

A few sharpening notes:

• These are not mutually exclusive — a real setup often has all of them. An automation runs a skill whose method calls an MCP tool and follows your AGENTS.md conventions.
• MCP vs skill is the most-confused pair: MCP is reach (what the agent can touch), a skill is method (how it should act). When in doubt, ask whether you're connecting to something or describing how to do something.
• Skill vs automation is just method vs schedule. If you can already invoke it cleanly by hand, the only thing automation adds is when.

Keep the ordering instinct, too: AGENTS.md and MCP set up what Codex knows and can reach; skills capture how; automations decide when — and you only get to "when" after "how" is reliable.

Codex exposes each extension mechanism through a slash command, so you can inspect and manage your setup without leaving the session. Knowing what each surface is for keeps you from mixing them up:

The practical workflow: when something feels off — Codex can't reach a tool, a skill isn't firing, a connector is missing — open the matching surface to see actual state rather than guessing. /mcp tells you a server is connected; /skills tells you a method exists; /plugins tells you what's installed to share. These surfaces are how you audit your extension setup, which matters most right before you automate something, because an automation runs unattended and you want to confirm every piece it depends on is actually live.

The roster of slash commands evolves; check the live reference for the current set rather than memorizing it.