Agent Skill vs MCP: What Belongs in Each Layer?

An agent skill packages a repeatable workflow: what to inspect, how to decide, what to produce, and when to stop. MCP packages an integration layer: how an AI application connects to external tools, data, prompts, and resources through a standard protocol.

Use a skill when the hard part is procedure. Use MCP when the hard part is access.

The two often belong together. A skill can tell an agent when to use a GitHub, Slack, CRM, browser, or database MCP server; the MCP server gives the agent the actual capability to read or act in that system. The distinction matters because teams often try to solve workflow ambiguity by adding more connectors. More connectors do not tell the agent what good work looks like.

If you already know the difference between a skill and a single callable tool, Agent Skill vs Tool is the lower-level comparison. This article focuses on the MCP boundary: where the protocol should stop and where a skill should start.

The Model Context Protocol specification describes MCP as a standard way for applications to share context, expose capabilities, and build integrations around language models. In MCP terms, a host is the AI application, a client is the connector inside that host, and a server provides context or capabilities. The protocol uses JSON-RPC messages and defines server features such as tools, resources, and prompts.

In practice, MCP is the right layer for:

• exposing callable actions such as search_docs, create_issue, query_database, or send_message
• declaring schemas for inputs, outputs, and structured content
• making external resources discoverable without hard-coding every API call into a prompt
• packaging reusable prompt templates that a host can surface to users
• keeping integration ownership separate from workflow authoring
• supporting permission, approval, and audit boundaries around external systems

The MCP tools specification is especially relevant for skill authors because it treats tools as model-controlled capabilities with declared schemas. A tool can query a database, call an API, or perform computation. That is a capability surface, not a workflow by itself.

MCP resources and MCP prompts are different from tools. A resource might expose the current API schema, a file, a support transcript, or a runbook. A prompt might offer a reusable template for a user to start a task. Those are valuable context surfaces, but they still do not define the full operating procedure for a recurring job.

OpenAI's Codex skills documentation frames skills as structured bundles of instructions, resources, and optional scripts that help Codex perform tasks reliably. Anthropic's Claude Code skills docs describe skills as SKILL.md files with instructions that load when relevant, and Anthropic's engineering write-up on Agent Skills emphasizes organized folders of instructions, scripts, and resources that agents can discover dynamically.

A skill is the right layer for:

• naming one repeatable job
• telling the agent which sources to trust first
• describing the decision path, not just the available action
• requiring completion evidence
• defining stop rules and escalation rules
• capturing examples, references, and review checklists

For example, an MCP server might expose linear.createIssue. A skill for "turn customer feedback into triaged product issues" would explain which feedback to include, how to group duplicates, what severity labels mean, which product area owners to mention, and what evidence must be quoted. That is why What Is an Agent Skill? defines the skill as a reusable job, not just a container for instructions.

The packaging is part of the value. A skill can keep the visible SKILL.md lean, then point to references/, scripts/, or examples only when the task requires them. That progressive disclosure is different from pasting a giant prompt into every request. It lets a skill author capture domain knowledge without forcing every agent run to carry every detail.

Imagine a DevRel team needs agents to migrate old SDK docs to a new style guide.

The MCP layer might provide:

• repo.read_file
• repo.search
• repo.create_branch
• repo.open_pull_request
• docs.lookup_style_rule

The skill layer should provide:

• which docs count as migration candidates
• which style guide sections matter most
• how to preserve API semantics while changing examples
• what tests or previews must run
• how to write the PR summary
• when to stop and ask for maintainer input

Without MCP, the skill may know what to do but lack access. Without the skill, the agent may have access but no repeatable editorial judgment.

A GitHub MCP server is useful because it can make repository data and actions available to an AI client. GitHub's MCP setup docs describe connecting Copilot-style environments to GitHub through MCP, with OAuth or personal-access-token scopes determining what the agent can reach. GitHub's own MCP changelog also points to scope-based tool filtering: if a token cannot perform an action, the server can hide the unavailable tool instead of letting the agent discover failure at call time. That is access control and tool-surface design.

A serious pull-request review still needs a skill. The skill should tell the agent to read the PR description before browsing the whole repo, inspect changed files before historical files, separate blocking correctness issues from style suggestions, cite file paths and lines, check CI status, and avoid posting a review unless the user asks. A connector can fetch the diff. It cannot decide that a migration-guide violation is more important than a naming nit.

This distinction is operational. If the review is inconsistent, another GitHub tool will not fix it. The next improvement is a sharper review skill, a better severity rubric, or an example final report. How to Write an Agent Skill That Actually Works covers that skill contract in more detail.

The Playwright MCP documentation describes a server that lets an agent interact with pages through browser state: navigate, click, type, fill forms, select dropdowns, press keys, handle dialogs, switch tabs, and capture screenshots. The Playwright MCP project also emphasizes structured accessibility snapshots, which are useful because the agent can reason over page roles and text rather than relying only on pixels. That is exactly the sort of capability a QA workflow needs. It is not a QA workflow.

A checkout-QA skill would define the job:

• start from a seeded cart and test account
• run desktop and mobile widths
• cover happy path, declined payment, missing address, and expired session
• check console errors and failed network requests
• use test payment credentials only
• capture screenshots for cart, payment, confirmation, and error states
• return a pass/fail table with reproduction steps

The browser MCP server can click the Pay button. The skill decides whether the run has enough evidence to say checkout is healthy. If the agent can browse but keeps testing only the happy path, the missing artifact is not MCP. It is procedure.

Slack is another place where the boundary matters. Slack's MCP server docs describe search, message retrieval, message sending, canvases, user lookup, app identity, admin approval, rate limits, IP allowlists, and audit logs. The risk is not that an agent lacks verbs. The risk is that the verbs are too broad.

A Slack escalation skill should define which channels count, which time window to inspect, how to classify incidents versus normal customer questions, when to draft instead of send, what message links or timestamps to cite, and when sensitive threads must be escalated to a human. The MCP server carries workspace access. The skill carries the operating policy.

The same pattern applies to Gmail, CRM, Linear, Zendesk, and internal analytics. A connector can expose the system. A skill turns the system into a bounded job.

Ask these questions before building anything:

Question	Build a skill when yes	Build MCP when yes
Does the agent need a repeatable operating procedure?	Yes	Maybe
Does the agent need access to a system, API, or datastore?	Maybe	Yes
Is the main risk inconsistent judgment?	Yes	No
Is the main risk missing integration or permissions?	No	Yes
Do humans need a standard output and review path?	Yes	Maybe
Do multiple agents or apps need the same connector?	Maybe	Yes

If both columns are yes, build both: MCP for the connector, skill for the job.

MCP prompts are the confusing middle case. The MCP server-concepts docs describe prompts as reusable templates that are user-controlled and explicitly invoked. They are useful when the server author wants to show a good way to start a task with that server: "summarize this repository," "plan a vacation," or "draft a release note from these resources."

That sounds close to a skill, but the control model is different. An MCP prompt is a server-provided interaction template. A skill is an agent-side workflow package that can be selected because the user's task matches its description. A prompt can help a user start. A skill can define the whole job: discovery, source priority, tool order, approval rules, evidence, and final output.

Use an MCP prompt when the workflow is mostly a form or starter command attached to one server. Use a skill when the workflow is a durable practice you want agents to repeat across tools, repos, customers, or teams. For a deeper combined pattern, Agent Skill with MCP walks through how a skill can name the job while MCP supplies the connected systems.

MCP servers can touch real systems. The MCP specification's trust and safety section emphasizes consent, user control, data privacy, and caution around tools that can execute arbitrary behavior. The tools specification recommends user-visible tool exposure, visible indicators when tools run, and confirmation prompts for operations.

That means the security boundary should not be hidden inside the prose of a skill. Put hard access control in the MCP server, host, and authorization layer. The MCP authorization specification describes HTTP authorization around OAuth-style resource servers and scopes; for local stdio servers, credentials commonly come from the environment instead. Those details belong with the connector and host configuration.

This is also where community caution is useful. In a Reddit discussion about MCP security, developers called out tool sandboxing, public-server trust, signing, and manifest controls as practical concerns. Simon Willison has written about MCP prompt-injection risks such as tool-definition changes and cross-server tool shadowing. You do not have to accept every worst-case claim to act on the underlying lesson: treat an MCP server like executable integration code, not like a harmless prompt library.

Skills still have safety responsibilities, but they are procedural:

• read-only by default unless the job requires a write
• ask before sending, posting, deleting, purchasing, merging, or deploying
• summarize the planned write action before requesting approval
• do not expose secrets, private customer data, or unnecessary personal data in the final answer
• stop when the requested access is broader than the job requires
• cite the source that drove the recommendation

For skill authors, the clean rule is: MCP enforces what the agent can reach; the skill explains when reaching for it is appropriate.

The most common mistake is stuffing workflow policy into an MCP tool description. Tool descriptions should help the model call the tool correctly, but they should not carry the entire operating procedure for a business workflow.

Keep the tool description narrow:

Create a Linear issue with title, body, team key, priority, and labels.

Put workflow judgment in the skill:

Only create an issue after grouping duplicate feedback, quoting two examples,
assigning a product area, and checking whether an existing issue already covers it.

That separation makes both artifacts easier to test. Integration tests can verify the MCP server. Skill evals can verify that the workflow creates the right issue for the right reason.

Not every repeatable interaction needs a full skill. MCP prompts can be enough when the user needs a reusable starting template rather than a durable operating procedure. MCP resources can be enough when the main value is exposing current context, such as the latest API schema or incident runbook, and the human is still driving the work.

Use a skill when the task has a standard of quality that survives across runs:

• the agent must inspect sources in a specific order
• the output must follow a reviewable format
• there are stop rules or approval gates
• multiple tools need to be coordinated
• feedback should improve the workflow over time

That last point is important for Skillfully's audience. If you are publishing and improving reusable workflows, the question is not only "did the connector work?" It is "did the skill guide the agent to the right outcome?" How to Test an Agent Skill Before You Publish It is the natural next step after the architecture decision.

Agent skills and MCP are complementary, not competing abstractions. MCP gives agents structured access to systems. Skills tell agents how to use access to complete a repeatable job with evidence, boundaries, and reviewable output.

For Skillfully's audience, the practical rule is simple: if you are packaging expertise, write a skill. If you are packaging access, build or use MCP. If the workflow needs both expertise and access, connect them deliberately instead of letting tool availability stand in for procedure.