MCP vs. Agent Skills vs. Plugins vs. Custom Agents: What Should You Use?

MCP, Agent Skills, Plugins, and Custom Agents are often presented as four ways to extend an AI coding tool. That framing creates the wrong decision. They are not direct substitutes. They operate at different layers.

• MCP provides access to external tools, services, and live data.
• Agent Skills provide a procedure for completing a repeatable kind of work.
• Plugins package and distribute capabilities so other people can install them.
• Custom Agents provide delegation to a specialized worker with its own context and constraints.

The shortest useful rule is: access → MCP, procedure → Skill, distribution → Plugin, delegation → Custom Agent.

Real systems often combine all four. A security-review plugin might install a review skill and an MCP server, while a custom security agent runs the skill in an isolated context and returns prioritized findings. Asking which single mechanism “wins” misses the architecture.

This guide explains where each layer belongs, when a plain prompt is enough, and how the model maps to Codex and Claude Code as of September 2026.

Why these concepts are easy to confuse

All four mechanisms can make an agent appear more capable. A skill can instruct an agent to call a service. An MCP server can expose a prompt as well as a tool. A plugin can contain skills, server configuration, agents, and hooks. A skill can even run inside a subagent. From the prompt box, the result may look identical: you ask for an outcome and the agent does more than it could before.

The difference becomes visible when you ask four architectural questions:

1. Where does the capability come from? Instructions, executable tools, or another model context?
2. When is it loaded? Every session, only when relevant, or only after delegation?
3. What trust boundary does it cross? Local files, an external account, or a separate worker?
4. How is it shared? Copied into one repository, installed as a package, or configured per user?

OpenAI's Codex documentation explicitly describes project guidance, Skills, MCP, and subagents as complementary customization layers. Claude Code exposes nearly the same architecture, while adding its own product-specific controls and packaging conventions. The concepts align more closely than their user interfaces do.

The four layers in one minute

This table describes responsibilities, not rigid walls. MCP servers can publish prompts and resources. Skills can invoke tools. Plugins can bundle custom agents. The important question is which layer owns the problem.

MCP: give the agent access

The Model Context Protocol standardizes how an AI application connects to tools and context. In practical coding work, it is the right layer when the missing capability lives outside the agent's local repository or built-in tools.

Use MCP when the agent needs to:

• search an internal documentation system;
• inspect production errors in Sentry;
• read or update issues in a tracker;
• query a database through a controlled interface;
• inspect design data from Figma;
• call an internal deployment or compliance service.

An MCP server describes the available operations and handles communication with the underlying system. It can also enforce authentication and return structured data. Both Codex and Claude Code support local servers launched as processes and remote servers reached over HTTP.

What MCP does not solve

Access is not a workflow. Giving an agent a create_release tool does not tell it when a release is safe, which checks are mandatory, how to choose a version, or when to stop for approval. That procedure belongs in a Skill, durable project instructions, or deterministic automation.

MCP also does not make an external system trustworthy. A server can expose destructive tools, stale descriptions, oversized responses, or more data than the task needs. Treat every MCP server as executable integration code, not as a harmless prompt library.

MCP costs and risks

• Permissions: grant the narrowest tools and scopes that support the workflow.
• Prompt injection: external content can contain instructions aimed at the model. Keep retrieved data separate from trusted policy.
• Side effects: distinguish reading from writing and require approval for consequential actions.
• Availability: remote tools can time out, change schema, or fail authentication.
• Context cost: large tool catalogs and responses consume attention even when they are technically available.
• Auditability: preserve which tool was called, with what arguments, and what changed.

If a local CLI already provides a stable, testable interface, an MCP wrapper may add no value. Use MCP when standard discovery, structured invocation, cross-client reuse, or controlled remote access justifies the additional boundary.

Agent Skills: teach a repeatable workflow

An Agent Skill packages task-specific guidance. Its core is a SKILL.md file with a name, description, and instructions; it can also include references, templates, examples, and scripts. Both Codex and Claude Code use progressive disclosure: the agent sees enough metadata to identify a relevant skill, then loads the detailed procedure when needed.

Create a Skill when you keep repeating a prompt such as:

• review this pull request using our severity model;
• prepare a database migration with rollback evidence;
• generate a release note in the team's format;
• diagnose this service using the same log and metric sequence;
• produce a frontend handoff with required API examples.

A useful Skill defines inputs, steps, output, success criteria, and stop conditions. It may tell the agent which tools to use, but the Skill itself is the playbook—not the connection to those tools.

Skill vs. project instructions

Do not turn every convention into a Skill. Rules that apply to nearly every task in a repository belong in AGENTS.md for Codex or CLAUDE.md for Claude Code. A procedure that should load only for a particular task belongs in a Skill.

For example:

Always run pnpm typecheck before declaring completion.        → project instruction
When preparing a release, calculate the version, update the
changelog, run the release matrix, and produce rollback notes. → Skill

See Instructions vs. Skills: What Belongs Where? for the deeper boundary.

Skill vs. script

Use a script when the same inputs should produce the same mechanically verifiable result. Use a Skill when the work requires judgment, repository exploration, tool selection, or synthesis. Strong Skills often call deterministic scripts for the parts that should not depend on model interpretation.

Plugins: package and distribute capabilities

A Plugin is primarily a delivery unit. It answers “How do other people install and update this capability?” rather than “How does the agent reason?”

In both Codex and Claude Code, a plugin can bundle multiple extension types. The exact contents and manifests differ by product, but the architectural role is similar:

• ship one or more Skills;
• include MCP server or connector configuration;
• distribute custom agents;
• add lifecycle hooks or related supporting assets;
• version and share the package through a team or marketplace.

This is why “Skill vs. Plugin” is usually the wrong comparison. A Skill is an authoring format for the workflow. A Plugin is how that Skill—and possibly the tools it needs—becomes installable.

Start standalone, package later

For one repository or an experiment, create the Skill, agent, or MCP configuration directly in the project's supported location. Packaging too early adds manifests, namespacing, release management, compatibility work, and a larger trust surface.

Create a Plugin when at least one of these becomes true:

• multiple repositories need the same capability;
• teammates need a repeatable install and update path;
• the workflow combines several Skills, agents, hooks, or integrations;
• you want versioned internal distribution or a public marketplace listing;
• setup is complex enough that copying files creates drift.

Codex plugins and Claude Code plugins are not interchangeable packages. Both can carry Skills based on the Agent Skills format and both can reference MCP servers, but their manifests, supported components, installation flows, and runtime surfaces differ. Share the portable core where possible; maintain product-specific packaging around it.

Custom Agents: delegate to a specialist

A Custom Agent is a reusable worker definition. When invoked as a subagent, it gets a bounded task and a separate context, performs its work, and returns a result to the coordinating agent.

Use one when the value comes from isolation or specialization:

• repository exploration would flood the main conversation;
• several independent investigations can run in parallel;
• a reviewer should not inherit the implementer's reasoning;
• a task needs a restricted tool set or permission mode;
• a cheaper or more capable model should handle one workstream;
• the same specialist role is delegated repeatedly.

A Custom Agent can be given a Skill and MCP tools. The agent is the worker, the Skill is its method, and MCP is its access.

Custom Agent vs. Skill

This is the most important operational distinction:

Do not create an agent merely to hold a long prompt. Delegation adds model calls, coordination, summaries, and possible merge conflicts. If the main agent can complete the workflow cleanly in its current context, a Skill is simpler.

For larger orchestration patterns, see What Is Multi-Agent Coding?.

The decision tree

Start with the missing capability, not the product menu:

Does the agent need a system or live data it cannot already reach?
├─ Yes → add the narrowest suitable tool; use MCP when a standard
│        agent-facing connection is valuable.
└─ No
   ↓
Does good work depend on a repeatable, multi-step procedure?
├─ Yes → create an Agent Skill.
└─ No → use a clear prompt or deterministic command.

Does the work need isolation, parallelism, a specialist role,
different tools, or a different model?
├─ Yes → define or invoke a Custom Agent.
└─ No → let the main agent execute the Skill.

Do other users or projects need to install and update the bundle?
├─ Yes → package the Skills, agents, and integrations as a Plugin.
└─ No → keep the configuration standalone.

The branches are cumulative. “Yes” to MCP does not prevent “Yes” to Skill or agent. It establishes the bottom layer first.

Four practical architectures

1. Repeatable local code review: Skill only

The repository and Git diff are already accessible. The problem is consistency, so create a review Skill that defines severity, scope, evidence requirements, and output format.

Input: requirement, base branch, current diff
Skill: inspect changed behavior, trace callers, verify tests,
       report at most five evidence-backed defects
Output: prioritized findings with reproduction guidance

No MCP server or custom agent is required for a small self-review. For a meaningful independence boundary, run the same Skill in a separate reviewer agent. Our AI code review best-practices guide explains when that extra boundary is worthwhile.

2. Incident diagnosis: MCP + Skill

The agent needs live Sentry events and deployment metadata, so MCP provides read-only access. A Skill defines the diagnostic sequence: establish the time window, correlate the release, group symptoms, test competing hypotheses, and produce evidence before proposing a change.

MCP: Sentry.read_events + Deployments.list_changes
Skill: incident-triage playbook
Main agent: combines evidence and proposes next action

Without MCP, the workflow lacks current evidence. Without the Skill, the agent may browse opportunistically and stop at the first plausible explanation.

3. Independent security assessment: MCP + Skill + Custom Agent

Delegate threat analysis to a restricted security agent. Give it a threat-modeling Skill and read-only access to vulnerability data through MCP. Keep write and deployment tools unavailable.

Custom Agent: security-reviewer, isolated context, read-only tools
Skill: threat model → trace trust boundaries → verify controls
MCP: vulnerability and dependency intelligence
Return: ranked findings and evidence, no automatic fixes

The separate context reduces self-confirmation, while tool restrictions keep review from silently becoming remediation.

4. Team-wide release system: Plugin containing all three

Once several repositories use the same release process, package the capability:

release-plugin/
├── Skills: prepare-release, validate-release, rollback-plan
├── Custom Agent: release-auditor
├── MCP configuration: issue tracker and deployment service
└── Hooks or supporting scripts: deterministic validation

The Plugin creates an installation and update boundary. It does not replace the internal layers; it distributes them.

Codex and Claude Code: how the concepts map

Codex

Codex documentation presents AGENTS.md, memories, Skills, MCP, and subagents as layers that work together. Skills are reusable workflows with optional resources and scripts. MCP connects Codex to third-party context and tools. Plugins distribute Skills and connectors, and custom Codex agents specialize delegated work.

Codex's current local clients can use subagent workflows, and each subagent performs its own model and tool work. That can protect the main context and enable parallelism, but it also increases token use. Use the boundary when it buys independence or time—not by default.

Primary references: Codex customization , Skills , Plugins , MCP , and subagents .

Claude Code

Claude Code Skills use the Agent Skills open standard and add product-specific features such as invocation controls, dynamic context, and subagent execution. A Skill may live at user or project scope or arrive inside a plugin.

Claude Code custom subagents run with their own context window, system prompt, tool access, and permissions. Plugins are the sharing layer: Anthropic documents them as bundles that can include Skills, agents, hooks, and MCP servers. Standalone configuration is appropriate for project-specific or experimental work; packaging is useful when the capability needs distribution and versioning.

Primary references: Claude Code documentation for Skills , Plugins , MCP , and custom subagents .

What is converging—and what is not

The durable trend is composability. Both ecosystems are moving away from one giant instruction file and toward discoverable workflows, standardized tool connections, installable capability bundles, and specialized contexts.

Three developments matter:

1. Skills are becoming more portable. Both products support the SKILL.md-based Agent Skills format, although each adds its own behavior and metadata.
2. MCP is becoming the shared integration boundary. A server is not guaranteed to behave identically in every client, but the protocol reduces the need to invent a new tool interface for each agent.
3. Plugins are becoming composed products. The useful unit is increasingly a workflow plus the tools, agents, and governance it needs—not a prompt file by itself.

What is not converging is the whole runtime. Plugin manifests, marketplaces, scopes, hooks, permission systems, invocation syntax, UI surfaces, and advanced Skill fields remain product-specific. Portability should be designed, tested, and documented rather than assumed.

Common mistakes

Building an MCP server for a prompt problem

If the agent already has the required data and tools, adding a server creates authentication, deployment, and reliability work without improving the decision process. Start with a Skill.

Encoding policy only in a Skill

A model-readable rule is guidance, not enforcement. Put mandatory checks in tests, CI, schemas, permissions, or policy engines. Let the Skill run and interpret those controls.

Treating a Plugin as a security review

Installation is a trust decision. Inspect the package's Skills, scripts, hooks, server configuration, requested scopes, and update source. Namespacing and a marketplace listing do not prove safety.

Giving every Custom Agent every tool

Specialization should narrow access. A reviewer rarely needs deployment rights. A documentation researcher rarely needs database writes. Restrict tools according to responsibility.

Creating an agent for every role name

“Frontend expert” and “backend expert” are not useful boundaries by themselves. Create a Custom Agent when it needs distinct context, tools, model behavior, or independent work. Otherwise, invoke the relevant Skill in the main session.

Packaging before the workflow stabilizes

First prove the procedure in one repository. Then extract the portable core, add tests or evaluations, and package it. Distribution magnifies both good design and unclear instructions.

A practical adoption order

For most teams, the simplest path is:

1. Write a direct prompt and complete the task manually with the agent.
2. Move recurring project-wide rules into instructions such as AGENTS.md or CLAUDE.md.
3. Extract repeatable procedures into Skills and test them on realistic inputs.
4. Add MCP only for missing external access, starting read-only and with narrow scopes.
5. Introduce Custom Agents where isolation, parallelism, or specialist permissions have measurable value.
6. Create a Plugin after the combined capability needs reliable installation, versioning, and sharing.

This order keeps architecture proportional to the problem. It also makes failures easier to diagnose: workflow errors live in the Skill, connectivity errors at the MCP boundary, coordination errors in agent delegation, and distribution errors in the Plugin.

Frequently asked questions

Is MCP better than Agent Skills?

No. MCP provides access to tools and context; a Skill defines how to perform a repeatable workflow. A Skill can use MCP tools. If the agent already has access but behaves inconsistently, improve the Skill. If the workflow is clear but the agent cannot reach a required system, add MCP.

What is the difference between an Agent Skill and a Plugin?

A Skill is the reusable procedure itself. A Plugin is an installable package that can distribute Skills together with integrations, agents, hooks, and other supported components. Build the Skill first; create a Plugin when sharing and versioning become requirements.

What is the difference between a Skill and a Custom Agent?

A Skill changes how an agent performs a task. A Custom Agent creates a specialized execution context for delegated work. Use a Skill for procedure and a Custom Agent for isolation, parallelism, restricted tools, or model specialization.

Can a Custom Agent use MCP and Skills together?

Yes. That is one of the strongest patterns: the agent supplies role and context isolation, the Skill supplies the method, and MCP supplies controlled external access.

Are Skills portable between Codex and Claude Code?

The portable core can be. Both support the Agent Skills format, but product-specific frontmatter, invocation behavior, scripts, dependencies, and tool names may require adaptation. Keep shared instructions standards-compliant and isolate product-specific extensions.

Are Plugins portable between Codex and Claude Code?

Not as complete packages. Their packaging formats, supported components, marketplaces, and runtime behavior differ. Individual Skills and MCP servers can be more portable than the Plugin that distributes them.

When is a plain prompt enough?

Use a plain prompt for one-off work that needs no external integration, reusable procedure, isolated worker, or distribution. Turning every successful prompt into infrastructure creates maintenance without improving reliability.

Should teams standardize on one mechanism?

Standardize the boundaries, not one mechanism. Define what belongs in persistent instructions, Skills, MCP integrations, Custom Agents, and Plugins. The system becomes easier to audit when every layer has a clear owner.

The bottom line

MCP, Agent Skills, Plugins, and Custom Agents answer different questions:

• Can the agent reach what it needs? MCP.
• Does it know the repeatable way to do the work? Agent Skill.
• Should a specialized worker handle the task? Custom Agent.
• Can the complete capability be installed and updated by others? Plugin.

Start with the smallest missing layer. Compose layers only when each one has a clear responsibility. The best agent setup is not the one with the most extensions; it is the one where access, procedure, delegation, and distribution can be understood—and trusted—separately.