Claude Skills vs MCP: When Builders Should Use Each
Claude Skills and MCP solve different failures. Repeated procedure belongs in a Skill: the same checklist, review order, report shape, or house rule keeps getting pasted into chat. Missing reach belongs behind MCP: the assistant needs a real connection to a database, API, SaaS workspace, local app, file service, or public agent endpoint.
In brief: Put method in a Claude Skill. Put live system access behind MCP. Combine them when a workflow needs both a callable tool and a repeatable review path. Before installing a public agent capability, inspect the record, check the endpoint, and prefer a dry run over a silent config edit.
Next action: if the capability is a public agent, run the checker, browse MCP agents, then preview the local config path with spawnr. Do that before adding the server to Claude Code, Codex, Cursor, or another agent client.
Direct answer
Choose a Skill when the assistant already has enough tools but needs the same operating instructions every time. The Claude Code Skills documentation describes a Skill as a SKILL.md instruction package with frontmatter and optional supporting files such as scripts, examples, templates, and references.
Choose MCP when the assistant lacks access to a live system. The Model Context Protocol introduction defines MCP as an open standard for connecting AI applications to external systems, including data sources, tools, and workflows. The MCP server concepts page names the main server primitives: tools, resources, and prompts.
Public agent directories fit a third job: inspection before local setup. A directory record can point to an MCP server, A2A endpoint, web service, or x402 surface, but the record still needs review before it becomes something you install or call.
Comparison
| Question | Claude Skill | MCP server |
|---|---|---|
| Main job | Repeatable method, checklist, policy, or review flow. | Live access to data, tools, files, apps, APIs, or agent endpoints. |
| Main artifact | SKILL.md plus optional scripts, references, examples, and templates. | Server capabilities exposed as MCP tools, resources, and prompts. |
| First review | Read instructions, trigger text, allowed tools, bundled scripts, and references. | Inspect publisher, auth, transport, schemas, write actions, logs, and errors. |
| Typical failure | Claude follows a stale or unsafe procedure. | Claude reaches a live system with weak permissions or unclear side effects. |
| Trust limit | A Skill can document a safer method, but it cannot prove an external service is safe. | MCP standardizes communication, but it cannot prove ownership, reputation, or endpoint safety. |
This distinction is an inference from the official docs rather than a standard phrase: Skills carry method; MCP carries access.
When a Skill is the right object
Skills package operating knowledge by telling Claude when to activate, which sources to read first, which commands are allowed, what output shape matters, and which checks must pass before the answer reaches the user. The required entry point is SKILL.md; supporting files keep long references or helper scripts out of the main instruction file until they are needed.
Good Skill candidates are the tasks that keep becoming custom prompts:
- repo-specific code review standards;
- launch checklists with tests, build commands, screenshots, and release notes;
- editorial rules for a Learn article or public report;
- data-cleaning recipes for one recurring spreadsheet shape;
- customer research briefs with source order and privacy rules;
- incident review templates that separate fact, inference, and action.
The Skills docs also describe frontmatter controls, including disable-model-invocation, user-invocable, allowed-tools, and disallowed-tools. Those fields deserve attention because they affect whether Claude may load a Skill automatically and which tools the Skill can pre-approve. Shell scripts inside a Skill should get the same review as any small local automation.
The consequence is concrete. If a release checklist lives only as a chat prompt, one assistant run may skip screenshots and the next may skip the focused test. Put the checklist in a Skill, include the exact test command and report format, and the failure becomes reviewable: either the Skill loaded and followed the method, or the final answer is missing a required check.
A skills registry should therefore show more than a title. Useful entries expose trigger, scope, owner, last update, allowed tools, bundled scripts, and whether automatic invocation is enabled.
When MCP is the right object
MCP is a protocol surface for live capability. It lets an AI client discover and use external systems through a common shape instead of a custom integration for every database, ticket system, browser service, or API.
The official server concepts split MCP capabilities into three groups. Tools are callable operations with schemas. Resources are data or documents the application can retrieve as context. Prompts are reusable templates supplied by the server. Tool review is the most sensitive because a tool can perform an action, not just provide context.
Transport details change the review scope. The 2025-06-18 MCP transport specification defines JSON-RPC over stdio and Streamable HTTP. For Streamable HTTP, the spec calls out security work such as Origin validation, localhost binding for local servers, and authentication. Remote MCP should be treated as a networked app surface, not as a harmless prompt file.
The consequence is different from a Skill mistake. If a customer-support MCP server exposes create_refund, the review is not about whether the prompt is clear; it is about auth scope, argument schema, audit logs, and whether the user must approve writes. A good Skill can tell Claude to try search_tickets before any write, but the MCP server still controls which live action is possible.
Pick MCP when Claude needs to fetch live data, call a service, inspect a resource, or trigger a workflow. The written procedure can explain how to evaluate the result; the server is what makes the result reachable.
How they work together
Most serious workflows need both pieces. MCP supplies the current facts or operations. The Skill supplies the review path.
For example, a renewal-risk workflow might use MCP connectors for CRM notes, support tickets, product analytics, and email history. The companion Skill defines the operating method: read the contract first, separate facts from inference, score risk, cite sources, and write the final brief in the team's format.
Agent installation follows the same pattern:
- Search a public directory for a relevant agent or service.
- Inspect the agent record, protocol labels, service entries, and metadata.
- Run a safe discovery or read call when the endpoint supports it.
- Let a Skill enforce the review order and final install report.
- Change local configuration only after the user understands the effect.
MCP discovery proves that a client can speak to a server according to the protocol. Trust still comes from publisher identity, endpoint behavior, auth scope, logs, payment terms, quality signals, and user approval.
Discovery before install
Discovery should sit between "I found a capability" and "I changed my local agent setup." Start at the agents directory when you want to search by job, chain, protocol, or payment support. Open the profile and inspect metadata, declared services, quality tier, and payment hints as review signals.
Run the checker when you already have a chain and token ID and need a fresh read on metadata and service shape. For a service that looks worth testing locally, read Install an ERC-8004 Agent in Your Editor. A dry-run preview is the better first move when you want to see config changes before applying them.
Read ERC-8004 vs MCP for the standards around public agent records and MCP vs A2A for protocol routing. Builders publishing their own service should start with the agent registration guide.
| Step | Action | What it proves |
|---|---|---|
| Discover | Search public agents by job or protocol. | A record exists and may be relevant. |
| Inspect | Read metadata, services, protocol labels, and quality signals. | The record has enough detail to review. |
| Check | Re-read chain and token metadata through the checker. | The current record resolves and can be classified. |
| Test | Make a safe read or discovery call when possible. | The endpoint exposes observable behavior now. |
| Install | Use the setup guide or CLI path intentionally. | Local configuration changed with user awareness. |
| Govern | Add a Skill for usage rules. | Later calls follow the same method. |
Security and trust checklist
Review the instruction package and the live server separately.
For Skills, read SKILL.md, trigger text, invocation settings, allowed tools, bundled scripts, templates, and references. Look for stale policy, broad tool grants, hidden shell commands, or vague completion criteria. Narrow Skills are easier to trust than broad "handle everything" instructions.
For MCP servers, confirm publisher identity, package source, version, install command, auth scopes, transport, tool schemas, write actions, logs, and data retention. Separate read-only tools from write tools. Try one safe read before allowing production writes, browser control, wallet actions, customer data access, or paid actions.
For public agents, add chain and token ID, metadata resolution, service URLs, protocol labels, and payment terms to the review. ERC-8004 registration supplies discovery context, and MCP discovery supplies capability evidence. Neither one removes the need for user approval before local config changes or paid calls.
FAQ
Can Claude Skills call APIs?
Skill packages can include or reference scripts, and those scripts may call an API when the user's tool permissions allow it. Keep the distinction clear: the package describes the procedure; MCP is a better fit when the API should become a reusable, discoverable capability for AI clients.
How do MCP prompts differ from Skills?
Prompts exposed through MCP are templates from one server. Skills are instruction packages with frontmatter, supporting files, scripts, and invocation controls. Server-specific prompts belong with the MCP server; cross-tool procedures usually belong in a Skill.
Should I build a Skill or an MCP server first?
Start with the failure. When the assistant can reach the right systems but keeps doing the work inconsistently, write the Skill first. When the assistant cannot reach the system at all, build or install the MCP server first. Workflows with live access and repeatable judgment usually need both.
Does MCP prove a server is safe?
MCP proves protocol shape, not trust. Safety depends on publisher identity, permissions, authentication, transport hardening, schemas, logging, data retention, and user approval. Directories and checkers can add inspection signals, but they are not blanket guarantees.
Where should agent builders publish capabilities?
Publish the method as a Skill when users need repeatable instructions. Publish live access as an MCP server when users need tools, resources, or prompts. Publish the public agent record through an inspectable directory when users need discovery, metadata, and a path to evaluate the service before installation.
Method and authorship
This guide was written by Roman Krutovoy, maintainer of The Spawn. I updated it on June 18, 2026 after checking the current Claude Code Skills documentation, the Model Context Protocol introduction, MCP server concepts, and the 2025-06-18 MCP transport specification. The product recommendations are bounded to existing public actions: browse agents, run the checker, read the spawnr install guide, and review local changes before installing anything. This guide was updated again on July 4, 2026 to make the checker, MCP-agent browsing, and spawnr dry-run path visible immediately after the direct answer.
Corrections should use public evidence from the official Claude Code Skills docs, the current MCP specification, or the live The Spawn page being discussed. This article does not claim that The Spawn guarantees every endpoint, that MCP proves trust, or that a Skill replaces a security review.