Agent skills vs MCP: When to use which

August 9, 2026

Agent skills teach an agent how to do a repeatable job. MCP gives an agent a standard way to reach data and actions outside itself. Use a skill when the hard part is procedural knowledge. Use MCP when the hard part is a system boundary. Use both when the agent needs a repeatable workflow that operates on live product data.

The distinction: instructions versus interfaces

An Agent Skill is a portable package of expertise. The open Agent Skills format centers on a folder with a SKILL.md file containing metadata and instructions. A skill can also include scripts, reference material, templates, and other resources. Compatible agents can discover the skill, load its instructions when a task matches its description, and use its supporting files as needed. This progressive disclosure keeps every skill from consuming the full context window before it is relevant. Agent Skills overview

That makes a skill a good home for things such as:

• the steps for closing a month-end process;
• definitions for an organization's internal metrics;
• a review standard for a customer-facing report;
• a template and the rules for filling it out; or
• a script that performs a deterministic transformation.

MCP solves a different problem. It is a protocol for connecting an AI application to external data and tools. An MCP server can expose resources, prompts, and tools. The protocol describes resources as contextual data, prompts as user-controlled templates, and tools as executable functions that retrieve information or take actions. MCP server overview

The simplest test is this:

If you removed the agent and kept the capability, would another client still need it?

If yes, the capability probably belongs behind an API or MCP server. If the capability is mainly a method for using several tools together, the method probably belongs in a skill.

A practical comparison

Decision question	Agent skill	MCP
Primary job	Teach a workflow, method, or domain practice	Expose data and actions through a client/server contract
Best unit of reuse	A repeatable task	A product capability or integration
Main contents	Instructions, references, templates, optional scripts	Resources, prompts, tools, schemas, transport, and authorization
Typical owner	Domain or workflow team	Product API, platform, and security teams
Source of truth	The agent's procedural guidance and packaged assets	The connected system's live data and business APIs
Main failure mode	Wrong steps, stale guidance, or unsafe bundled code	Excessive permissions, weak authorization, or an unsafe tool call

A skill package can contain detailed instructions without making an agent accurate. MCP can standardize an exposed operation without making it safe. The workflow, API, permissions, and review process determine whether the result is acceptable.

Use a skill when the hard part is knowing how

Choose a skill when the workflow has a sequence that a capable general-purpose agent would not reliably infer on its own.

Typical signals include:

• The work has domain-specific steps, definitions, or decision points.
• The same method should be reused across many tasks or projects.
• A human expert would normally rely on a playbook, checklist, template, or style guide.
• The workflow changes more often than the underlying product API.
• Some steps are better handled by a deterministic local script than by generated text.

Consider a finance agent that prepares a month-end expense review. The skill might define which expense categories require supporting evidence, the order of checks, the organization's materiality rules, and the format of the final review. It could include a spreadsheet template and a script for normalizing dates. None of that needs to become a network service merely because an agent uses it.

The skill should describe the method and the quality bar. It should not be the authority for access control. A markdown instruction that says “only review this team's records” cannot enforce tenant isolation. The product API or tool layer must enforce that boundary using the authenticated identity and server-side rules.

Skills are also software supply-chain inputs. The format permits executable scripts, and a repository-mounted skill sits inside the agent's trust boundary. Anthropic's documentation warns that anyone who can change a mounted repository can change its instructions or scripts, so teams should review trusted repositories and pin the versions they run. Anthropic's Agent Skills engineering guide and Claude platform guidance on repository skills

Use MCP when the hard part is reaching the system

Choose MCP when an agent needs a governed connection to live data or product operations that should remain available beyond one workflow or one agent host.

Typical signals include:

• The data or action belongs to another service.
• Several AI clients should use the same capability.
• The capability needs a typed input and output contract.
• Authentication, authorization, tenant scope, rate limits, or audit logs belong at a service boundary.
• The capability depends on the product's current state and cannot rely on a packaged document.

For the expense example, MCP tools might search expenses, fetch a receipt, retrieve a policy, and submit a review for approval. The server can expose those operations to an embedded assistant, a coding agent, or another compatible AI client. The agent still needs a separate month-end method that tells it when to call each operation and how to interpret the result.

MCP can expose prompts and resources along with tools. Its architectural role is to standardize how an AI client discovers and invokes capabilities. A skill packages the agent-specific procedure for using capabilities toward an outcome.

Do not hide business policy inside tool descriptions just to avoid creating a skill. A tool description should explain the operation, inputs, outputs, and important constraints. A multi-step method with branching decisions, examples, and validation belongs in a workflow layer that can be versioned and evaluated as such.

When a workflow needs both

A useful architecture separates the workflow from the capabilities it orchestrates:

1. A skill recognizes the task and lays out the method, such as “prepare the month-end expense review.”
2. The agent loads the relevant policy, definitions, and templates from the skill package.
3. The agent calls MCP tools to read current records, retrieve evidence, and submit permitted actions.
4. The product API enforces identity, tenant boundaries, field-level rules, approval requirements, and write permissions.
5. The skill's final checks determine whether the result is complete and how it should be presented.

Workflow owners can update the method without redesigning every integration. Backend owners can evolve a product capability without rewriting every agent playbook. Security owners get an enforceable service boundary they can inspect; prose cannot protect data.

Use both only when the workflow and service boundary each solve a demonstrated problem. A narrow internal agent may need one local skill and a direct SDK. A broadly distributed product capability may need MCP while each client owns its workflow. Start with the smallest abstraction that has multiple credible consumers.

Portability also depends on the implementation. A skill is reusable across agents that support the Agent Skills format and its execution model. An MCP server is reusable across clients that support the relevant MCP version, transport, primitives, and authorization flow. Compatibility still needs testing.

Security changes the choice

Skills and MCP create different trust and failure surfaces, so they need different controls.

For skills:

• review instructions, scripts, references, and dependencies before installation;
• pin versions and record the owner of each skill;
• test representative tasks, including cases where the skill should not activate;
• keep secrets and authorization decisions out of the skill package; and
• restrict the agent's filesystem, network, and command privileges when scripts are allowed.

For MCP:

• authenticate the client and authorize every request;
• expose the smallest useful set of tools and data;
• enforce tenant scope and permissions in the server or the downstream API;
• validate token audience and claims; never pass tokens through blindly; and
• require clear user consent for high-impact operations, especially for local servers.

The MCP security guidance calls out token passthrough, confused-deputy risks, state-handle hijacking, and local server compromise. It recommends explicit consent and sandboxing for local server configuration, and requires MCP servers not to accept tokens that were not issued for them. MCP security best practices

The rule is straightforward: put judgment and instructions in the workflow layer, and put authority in the system that owns the data or action. Keep both layers observable. Skill evaluations show whether the agent followed the method. MCP and product logs show what data it accessed and what mutations it attempted.

Where Ginger Labs fits

For a SaaS product, the choice is also about where the user's work should happen.

An embedded Ginger Labs agent fits when the user's goal is to ask the product to do work inside the product experience. The agent can live in a side panel, inline surface, or modal, answer questions, and perform product work over the product's schemas, stages, records, and data. The customer still owns the product API and data model, domain rules, permissions and tenant boundaries, allowed actions, customer-facing experience, and definition of a correct result.

MCP as a service fits when selected product capabilities should be available to compatible external AI clients. Ginger Labs manages the MCP infrastructure, while the customer decides which capabilities to expose and how access is governed. The underlying API, data model, permission model, and tenant rules remain the customer's responsibility. MCP distributes those capabilities; the product's authorization model continues to govern them.

The two can work together. A SaaS team can keep its workflow knowledge in a skill, use an embedded agent for users who work inside the product, and expose a deliberate subset of the same product operations through MCP for users who work from an external AI client. The shared asset is the product's capability and policy model. The skill and MCP server are different ways of making that model usable.

A decision rule for your next workflow

Take one valuable workflow and ask four questions:

1. Is the main missing ingredient procedural knowledge? Start with a skill.
2. Does the agent need live data or actions owned by another system? Add an API or MCP server.
3. Will multiple clients need the same capability? Prefer a service boundary, with MCP when compatible clients are part of the requirement.
4. Is the action sensitive or irreversible? Keep authorization and approval in the product or service, regardless of whether a skill initiates it.

Then test the smallest vertical slice: one workflow, one or two real data reads, and one controlled write. Measure whether the agent follows the method, respects permissions, produces a correct result, and leaves an audit trail. That evidence will tell you whether you need a richer skill, a better tool contract, a stronger API boundary, or all three.

Agent skills and MCP are complementary layers. Skills make an agent better at a job. MCP makes a product's capabilities reachable in a standard way. The architecture works when neither layer is asked to pretend it is the other.

Sources

• Agent Skills overview, accessed August 9, 2026.
• Equipping agents for the real world with Agent Skills, Anthropic, accessed August 9, 2026.
• MCP server overview, Model Context Protocol, accessed August 9, 2026.
• MCP security best practices, Model Context Protocol, accessed August 9, 2026.
• Skills, Claude Platform Docs, accessed August 9, 2026.