MCP vs Agent Skills: Reach, Know-How, and the Controls Between Them

MCP and agent Skills solve different parts of the same operating problem. One gives an AI system a consistent way to reach external capabilities. The other gives an agent reusable know-how for carrying out a task well.

That distinction matters because teams often treat every agent requirement as an integration problem. They connect more systems, expose more tools, and then wonder why execution remains inconsistent. Other teams write increasingly detailed instructions while the agent still cannot retrieve the right record or perform the required action.

The useful question is not "MCP or Skills?" It is: what capability is missing, and where should its control boundary live?

MCP is a connection standard, not merely tool calling

The Model Context Protocol standardizes communication between AI applications and servers that expose capabilities. Calling it a connection layer is a helpful metaphor, but the protocol is broader than a catalog of functions.

The 2026-07-28 MCP specification defines three server primitives:

• Tools are executable functions that can retrieve information or take action.
• Resources provide structured data or content that an application can place in model context.
• Prompts are reusable templates or instructions that users can select.

This separation is valuable. Reading an approved policy document is not the same operation as updating a customer record. A guided troubleshooting prompt is not the same thing as either. Treating every interaction as a powerful tool call creates permissions that are too broad and audit trails that are too vague.

MCP standardizes discovery and invocation. It does not decide which employee may access a customer, whether a refund needs approval, or how your team should handle an ambiguous exception. Those remain application and operating-design responsibilities.

A Codex Skill is a reusable playbook

This guide uses OpenAI's Codex Skills as a concrete implementation of the broader agent-skills idea; other hosts may package procedural knowledge differently. In Codex, a Skill is a reusable folder centered on a SKILL.md file. It can also include scripts, references, assets, and other supporting resources. The purpose is to package task-specific procedures so the agent can load the right conventions and methods when needed.

A Skill might explain how your team reviews an infrastructure change, which evidence belongs in an incident report, or how to validate a customer migration. It can point to a deterministic script and require specific verification before the work is considered complete.

That is procedural knowledge, not a new external service. A Skill normally works through capabilities already available in the agent's environment. It can tell an agent how to use a deployment tool safely, but it does not create the deployment API, identity, or authorization boundary.

When you need one, the other, or both

Use MCP when the agent needs a standardized connection to a system of record or service. Examples include reading a CRM opportunity, querying a governed data source, or creating an issue through an approved interface.

Use a Skill when the agent already has the necessary access but needs a reliable procedure. Examples include applying your architecture-review rubric, producing a post-incident timeline, or following a customer onboarding checklist.

Use both when the task combines external reach with organization-specific judgment. A customer-escalation workflow might use MCP resources to retrieve account context, a tool to create an escalation record, and a Skill that defines severity, evidence requirements, approval gates, and communication standards.

The combination is powerful precisely because the responsibilities remain separate. The MCP server owns a narrow capability boundary. The Skill owns a transparent execution playbook. The host application owns user experience, approvals, and policy enforcement.

Controls belong around the combined workflow

An accountable production design needs more than a successful demo.

Identity: Carry the calling user or workload identity to the enforcement point. Do not collapse every employee into one undifferentiated service account when customer or role boundaries matter.

Least privilege: Expose the smallest useful tools and data surfaces. Prefer get_account_summary over unrestricted database access, and separate read operations from write operations.

Approval gates: Require confirmation based on effect, not on how confident the model sounds. External communication, financial changes, destructive actions, permission changes, and high-impact writes deserve explicit review.

Auditability: Record who requested the action, which tenant and tool were involved, whether approval was required, the outcome, and a correlation ID. Redact secrets and unnecessary personal data.

Failure containment: Bound time, retries, concurrency, spend, and downstream scope. Make repeated writes idempotent. Ensure a failed step cannot silently continue as though it succeeded.

These are architecture decisions; secure MCP integration patterns shows how to enforce them across identity, effects, retries, and evidence.

Implementation checklist

1. Inventory the tasks, systems, and data classes involved.
2. Classify each capability as a tool, resource, prompt, or local procedure.
3. Define identity propagation and authorization at the resource level.
4. Split read, reversible write, irreversible write, and external communication paths.
5. Put the operating procedure in a versioned Skill with explicit completion checks.
6. Add approval gates for consequential actions.
7. Capture structured audit events and downstream identifiers.
8. Test denied access, stale credentials, partial failure, duplicate delivery, and timeout behavior.
9. Assign owners for the MCP server, the Skill, and the business result.

Measurable signals

Track more than successful calls. Useful signals include task completion rate, human intervention rate, approval rejection rate, permission-denied rate, duplicate-action prevention, time to recovery, and the percentage of runs with a complete audit trail. Pair those with the business measure the workflow exists to improve, such as resolution time or onboarding cycle time.

Common failure modes

• A broad MCP tool becomes a thin wrapper around administrator access.
• A Skill contains credentials or customer data that belong in a secret store or governed resource.
• Instructions are mistaken for authorization enforcement.
• Every action receives the same approval treatment, creating either risk or approval fatigue.
• Tool success is reported as business success without checking the downstream state.
• Nobody owns versioning when an API, policy, or procedure changes.

MCP gives an agent reach. A Codex Skill gives it reusable know-how. The production system emerges only when identity, authorization, approvals, evidence, and failure boundaries make that combination accountable.

Further reading

• MCP server primitives: prompts, resources, and tools
• MCP tools specification and human-in-the-loop guidance
• MCP base protocol overview
• OpenAI documentation: Build skills