Agent skills vs MCP: when to use instructions, tools, or both

The short answer: guidance versus capability

An agent skill teaches an agent how and when to perform a workflow. An MCP server exposes tools, resources, or interactive capabilities the agent can call. A skill can say how your team qualifies a sales lead; an MCP server can read records from the CRM and write an approved status update. One is primarily instruction and packaged expertise, the other is a protocol boundary to systems and data. They overlap in user experience because both extend what an agent can accomplish, but choosing the wrong layer creates either a powerless playbook or an overpowered tool with no operating judgment.

Use an agent skill for repeatable judgment

Choose a skill when the hard part is the sequence, decision criteria, quality bar, or organizational policy. Skills are well suited to code review, research synthesis, release readiness, design critique, incident communication, and document production. They can inspect local context and use tools already available to the agent. A skill should not pretend it grants access; writing 'update Salesforce' in Markdown does not create a Salesforce connection. It should define which evidence supports an update, which fields are allowed, and when the agent must ask for approval before using a real capability.

• The workflow changes with context and needs agent judgment.
• The knowledge can be expressed as instructions, examples, references, and local scripts.
• The task can use existing tools or remain useful without a new remote integration.

Use MCP for governed access to systems

Choose MCP when the agent needs a defined interface to external data or actions: searching a knowledge base, creating an issue, querying a database, retrieving design assets, or launching a deployment. The server owns authentication, input schemas, permissions, errors, and the connection to the underlying service. Tool descriptions should explain what each operation does, while the protocol keeps the action surface machine-readable. Do not move business process prose into dozens of nearly identical tools. Keep the server composable and let a skill orchestrate those capabilities when a higher-level workflow is needed.

Combine them for real operational workflows

The strongest design often uses both. The official MCP development guidance itself is distributed as agent skills: the skills teach deployment choices, tool design, authentication, and packaging, while MCP provides the runtime interface being built. In a customer-support workflow, a skill can instruct the agent to verify identity, inspect account history, classify urgency, draft a response, and request approval for compensation. MCP tools can retrieve the account, read tickets, and apply the approved credit. The skill provides policy and sequence; the server provides governed, auditable actions.

Keep permissions outside the prompt

A skill can state an authorization rule, but it cannot enforce service-side access by itself. Sensitive operations need controls in the MCP server or underlying API: scoped credentials, user identity, confirmation, rate limits, validation, audit logs, and least-privilege tool definitions. Treat all remote content as untrusted input and avoid returning secrets or unnecessary personal data to the model. The skill should tell the agent how to handle approval and suspicious instructions, while the tool boundary prevents a persuasive prompt from obtaining authority the user or workspace did not grant.

Avoid the two common architecture mistakes

The first mistake is building an MCP tool for every sentence in a workflow, producing a large brittle surface with overlapping operations. The second is encoding a remote integration as shell commands inside a skill, leaking credentials and bypassing centralized permissions. Start by separating decisions from actions. If an operation must be authenticated, shared, observable, or safely callable across clients, it belongs behind a tool boundary. If the agent needs to choose why, when, and in what order to call those operations, that logic belongs in a skill or the application orchestrator.

• Do not use a skill as a credential store or permission system.
• Do not turn one business workflow into twenty tightly coupled MCP tools.
• Do not duplicate the same policy independently in every tool description.
• Do not claim portability until the skill and server are tested in the target clients.

Choose with a four-question decision test

Ask four questions before building. Does the agent need new access to a system or only better instructions? Must the capability be shared across several agents or applications? Does the operation require enforceable authorization and auditability? Is the difficult part executing an API call or applying judgment across several steps? New governed access points toward MCP. Reusable judgment points toward a skill. A shared capability plus a company-specific operating process usually needs both. If neither is true, a normal project instruction or small local script may be the simpler and more maintainable answer.

Three practical architecture recipes

For engineering release management, use a skill for repository inspection, risk classification, test selection, and reporting, with MCP only if the agent must update hosted issues or deployments. For design implementation, use a skill for visual fidelity standards and responsive verification, plus design or browser tools for source assets and live evidence. For sales qualification, use a skill for fit criteria, evidence standards, and outreach boundaries, plus a CRM MCP server for governed records. In every case, test the combined failure path: unavailable tool, denied permission, incomplete data, and an instruction embedded in retrieved content that conflicts with user intent.

• Skill only: local code review against a team checklist.
• MCP only: a small read-only tool that fetches an issue by ID.
• Both: incident triage that gathers telemetry, applies policy, creates an issue, and drafts a status update.