Agent Skills vs MCP Servers: Decision Framework

Agent Skills and MCP servers are often presented as competing ways to extend an AI agent. That framing is wrong: a skill teaches the agent how to work, while an MCP server gives it governed access to live capabilities.

The useful question is not “Which standard wins?” It is “Where should this responsibility live?” This guide answers that for hosted assistants such as Hermes Agent and OpenClaw, where context size, long-running connections, credentials, and operational safety matter more than a tidy demo.

This is not an academic comparison. It is a practical decision framework built from real deployment experience with both mechanisms, including the context-cost tradeoffs that only become visible once an agent is running in production. If you are building multi-agent systems, you may also want to read our A2A vs MCP protocol comparison, which covers a different axis of the same problem space.

Agent Skills vs MCP Servers in One Table

Use a skill for procedure, judgment, and reusable operating knowledge. Use an MCP server for authoritative state, protected operations, and a stable capability contract.

My default is deliberately conservative: start with a skill when the job is local, read-heavy, and procedural. Add an MCP server when the agent crosses a trust boundary, touches changing external state, or needs an operation that should remain correct even when the model is confused.

The Core Distinction: Procedure vs Capability

An Agent Skill is a directory centered on SKILL.md, with optional scripts, references, and assets. The Agent Skills specification defines required metadata and a progressive disclosure model: the host can discover a small name and description first, load the full instructions when relevant, and fetch supporting files only when needed.

That makes a skill a strong home for an incident rubric, a release checklist, a research method, or instructions for using an existing command-line tool. Its central value is encoded procedure: sequence, judgment, constraints, examples, and the definition of a good result. For Hermes-specific authoring details including frontmatter structure and conditional activation, see Hermes Agent Skill Authoring.

MCP solves a different problem. The Model Context Protocol specification gives a client and server a JSON-RPC-based contract for capabilities including tools, resources, and prompts, with standard transports and discovery behavior. Practical implementation guides for MCP servers in Python and MCP servers in Go show how straightforward the integration layer can be once the protocol handles the heavy lifting.

An MCP server is therefore a good boundary around a ticket system, cloud control plane, source-of-truth database, or internal search service. It owns the mechanics of reaching that system and can enforce validation, authorization, timeouts, rate limits, and audit behavior outside the model’s prose instructions.

A More Precise Rule

Ask whether a responsibility must remain correct without the model remembering an instruction. If the answer is yes, it belongs in deterministic code or server policy, not only in SKILL.md.

For example, “collect three supporting signals before escalating” is a useful skill instruction. “Reject a status change unless the caller has the incident-manager scope” must be enforced by the service or MCP server, even if the skill repeats the rule.

This is the boundary that matters:

• A skill can tell the agent when an action is appropriate.
• An MCP tool can make the action available through a typed interface.
• The backing service must decide whether the action is actually allowed.

MCP servers can also expose prompts, so the standards overlap at the edges. Still, putting an entire operating procedure in a giant tool description usually produces a brittle capability catalog, while putting a privileged API client in a shell script hidden inside a skill usually produces an avoidable security problem.

When a SKILL.md Is Enough

A skill is enough when the agent already has safe access to everything required and the missing ingredient is know-how. This is common for repository analysis, document transformation, report generation, or a local workflow built on mature CLI commands.

The Data Is Local or Supplied by the User

Suppose an agent must inspect a checked-out repository, run read-only linters, compare configuration files, and produce a migration report. The files are already in the working environment, and the host already exposes filesystem and process tools, so another network service adds little value.

The skill can describe which files to inspect, the command order, failure handling, and the required evidence. A bundled script may normalize output, but the host’s existing sandbox and command permissions remain the actual execution boundary.

The Workflow Depends on Judgment

Skills are especially useful when several technically valid actions exist but the organization prefers one operating method. A code-review skill can explain which risks deserve blocking comments, when to request a reproduction, and how to separate correctness issues from taste.

Those rules change as teams learn. Keeping them as version-controlled prose and small references is often clearer than recompiling or redeploying a server for every editorial adjustment.

Portability Matters More Than Central Control

The open Agent Skills format is designed as a portable folder rather than a remote runtime. A well-scoped skill can move between compatible hosts with its instructions, examples, and supporting assets intact, although tool names and sandbox behavior still require host-specific testing.

This portability is useful for Hermes Agent and OpenClaw workflows that share a method but not necessarily the same deployment. Keep host-specific notes in short references instead of forking the core procedure at the first difference. The OpenClaw skills ecosystem guide covers which skills are worth installing and how to gate them safely per agent role.

An Existing CLI Already Provides the Capability

Do not build a server merely to wrap a reliable local command. If a single-user assistant can call a narrow CLI that already handles authentication, structured output, and errors, a skill may be the smaller and more maintainable solution.

The caveat is important: a CLI is not automatically safe because it is local. Avoid broad shell interpolation, prefer structured output, constrain writable targets, and do not treat a skill’s suggested tool allowlist as a complete authorization system.

When You Need an MCP Server

Choose MCP when the problem is not merely remembering what to do. An MCP server becomes valuable when the agent needs a durable, typed, and governable bridge to a changing system.

The State Is Live and Authoritative

Customer tickets, deployment status, inventory, billing records, and production metrics can change between two model turns. Copying that state into a skill makes it stale by construction, while asking the model to scrape an interface produces an unstable contract.

An MCP resource or tool can retrieve the current record at execution time. The server can normalize upstream quirks and return a compact result instead of exposing an entire vendor response to the model.

Credentials or User Identity Are Involved

Credentials should not live in SKILL.md, examples, or bundled helper scripts. For remote HTTP deployments, the MCP authorization specification defines an OAuth-based model; for local stdio servers, credentials can be supplied through the process environment or another host-controlled mechanism. See the official MCP authorization guidance.

The deeper reason to use a server is not secret storage alone. A server can map identity to scopes, restrict tenants, redact fields, and record who requested a mutation, while a prose instruction can only ask the model to behave.

Writes Need Transactional Guarantees

Creating an invoice, changing a ticket status, or starting a deployment requires more than a plausible JSON object. The operation may need idempotency keys, optimistic concurrency, server-side validation, and a durable audit trail.

These properties belong below the model. The skill may define the approval policy, but the MCP server should reject an invalid transition and make a retried request safe.

Multiple Agents Need the Same Capability

A shared MCP server can present one contract to several agent hosts, languages, and model providers. That gives platform teams a central place to improve schemas, patch upstream API behavior, and apply access controls without copying integration logic into every skill.

Centralization is not free. The server becomes an operated dependency with versioning, observability, availability, and incident-response obligations, so it should earn its existence with a real boundary rather than architectural enthusiasm.

The Context-Cost Question

Context cost is frequently reduced to the slogan “skills are progressive, tools are always loaded.” Real hosts are more nuanced, and the difference should be measured in serialized model input rather than assumed from the extension format.

The Agent Skills documentation describes roughly 100 tokens of discovery metadata per skill, recommends keeping activated instructions below 5,000 tokens, and allows references to load on demand. A simple planning estimate is:

C_skill = discovery metadata + activated instructions + selected references

MCP clients discover tool definitions from servers, but the protocol does not require every discovered schema to appear in every model call. Hosts may filter, defer, cache, or route tools, so the practical estimate is:

C_mcp = tool schemas exposed to this turn + tool results retained in context

The MCP tools specification also notes that stable tool ordering can improve prompt-cache behavior. Caching may reduce repeated processing cost, but it does not make an oversized catalog easier for a model to choose from.

An Illustrative Token Budget

Consider a hosted assistant with 20 installed skills. At the Agent Skills documentation’s approximate discovery cost, the compact skill index is around 2,000 tokens; activating a focused triage skill might add another 1,200 tokens and one 600-token reference.

Now compare two MCP designs. A thin ticket server with four concise schemas might serialize to 500-800 tokens, while a broad enterprise server with 35 verbose tools could consume several thousand tokens before any result arrives.

These are illustrative planning numbers, not protocol guarantees or benchmarks. Measure the exact prompt generated by your host because schema verbosity, descriptions, routing, result retention, and tokenizer choice can move the total substantially.

The practical conclusion is not “skills are cheap” or “MCP is expensive.” It is that progressive disclosure and capability selection are architecture features: keep skill metadata discriminative, activate only relevant instructions, expose the smallest useful tool set, and return projections rather than raw upstream payloads.

The Thin-Server Pattern: MCP Below, Skill Above

The most durable design often combines both mechanisms. Put a small capability boundary in MCP, then place the operating method in a skill that calls it.

Consider a support-incident workflow used from either Hermes Agent or OpenClaw. The agent must read a ticket, gather evidence, classify severity, draft an operator note, and change status only after the required approval.

What the MCP Server Owns

Keep the server interface narrow and literal:

The server should not contain a tool called triage_everything with a paragraph-long description and a dozen unrelated flags. Four bounded operations are easier to authorize, test, observe, and reuse.

What the Skill Owns

The skill owns the sequence and judgment. A compact SKILL.md could look like this:

---
name: incident-triage
description: Triage support incidents using ticket evidence and the severity rubric.
---

1. Read the ticket and its current version.
2. Collect at least two independent signals before assigning severity.
3. Separate observed facts from hypotheses in the note.
4. Ask for operator approval before any customer-visible note or status change.
5. Re-read the ticket before a write; stop if its version changed.
6. End with severity, evidence, uncertainty, and recommended next action.

That file is readable, reviewable, and easy to revise when the triage policy changes. A linked reference can hold the severity rubric, while the main instructions remain short enough to activate without dragging an operations handbook into every turn.

How It Runs in Hermes Agent

Hermes Agent’s native MCP documentation describes startup discovery, persistent connections, stdio and Streamable HTTP transports, and namespaced MCP tools. Its current configuration also filters the environment for stdio servers and passes explicitly configured variables, which is a useful defense against accidental secret inheritance.

In this design, Hermes discovers the four ticket tools, while the incident skill activates only for relevant requests. The model follows the skill, the MCP server executes bounded operations, and the ticket service remains the final authority.

How It Runs in OpenClaw

OpenClaw’s skills documentation follows the Agent Skills structure and builds a compact list of eligible skills for the model. The same incident folder can carry the core procedure, with a short host-specific reference explaining the available ticket tool names.

Do not put the ticket token in the shared skill. OpenClaw explicitly treats shared skills as inputs rather than secret storage, and third-party skills should be reviewed as untrusted code before they are enabled.

Why the Split Survives Change

If the support team revises its severity rubric, update the skill. If the ticket vendor changes authentication or pagination, update the MCP server without rewriting the operating policy.

If a second agent host arrives, it can reuse the same MCP contract and adapt the skill’s small host-specific layer. This separation reduces duplicated integration logic without turning every procedural edit into a service deployment.

A Five-Step Decision Framework

The following sequence is more reliable than picking the fashionable extension type first.

1. Identify the Source of Truth

Write down every input and output the workflow touches. Static guidance, repository files, and user-provided documents lean toward a skill; mutable remote records and authoritative systems lean toward MCP.

Not all state justifies a server. A local build artifact is state, but an existing sandboxed CLI may already provide a sufficient boundary.

2. Locate the Trust Boundary

Mark where credentials, tenant identity, privileged data, or irreversible actions appear. If the agent crosses that line, introduce a deterministic enforcement point, typically an MCP server backed by service authorization.

Treat the model and skill as request planners, not policy engines. They may propose a permitted action, but they should not be able to redefine permission by changing their own instructions.

3. Separate Capability From Policy

Name capabilities as narrow verbs with typed inputs: get a ticket, add a note, or change status. Put the conditions for choosing those verbs, the evidence standard, and the preferred sequence in the skill.

Some policy must exist in both layers for different reasons. “Ask the user before deploying” belongs in the skill for interaction quality, while “reject deployment without an approval token” belongs in code for enforcement.

4. Estimate Context and Operating Cost

Capture a real prompt trace and count the skill metadata, activated instructions, tool definitions, and returned data. Then add the non-token cost of an MCP service: deployment, authentication, monitoring, versioning, and on-call ownership.

If a 30-tool catalog supports one workflow, expose a task-specific subset or split the server by coherent capability domain. If a skill repeatedly loads a 200-page reference, create a retrieval step or smaller references instead of congratulating yourself on progressive disclosure.

5. Test the Boundary, Then the Behavior

Test the MCP server as software and the skill as agent behavior. They fail differently, and a single happy-path chat transcript hides both classes of defect.

For tool safety, the MCP specification recommends input validation, access controls, rate limits, output sanitization, timeouts, confirmations for sensitive operations, and audit logging. Tool annotations are hints, not trusted proof that an operation is read-only or harmless. The A2A and MCP agent security guide covers the broader threat model including prompt injection and tool poisoning.

Security Rules That Do Not Fit in a Slogan

Skills reduce the need for some servers, but they do not remove risk. A skill can include scripts and can persuade an agent to call powerful host tools, so review its instructions and executable files as code, pin trusted versions, and limit the host tools available to the session.

MCP adds another boundary: a local subprocess or remote service with its own dependencies, inputs, outputs, and credentials. Apply least privilege, validate resource audience for remote authorization, use HTTPS, sanitize untrusted content, and keep approval visible for consequential writes.

Most importantly, do not confuse discoverability with authority. A tool appearing in the model’s catalog does not mean the current user should be allowed to execute every operation it describes.

Common Anti-Patterns

Hiding a Remote API Client in a Skill

A shell script that reads a static bearer token and calls a production API may work in a demo. It also mixes procedure, credentials, network behavior, and authorization into a package designed to be copied and read by agent hosts.

Move the protected integration behind a narrow server or an existing approved CLI. Keep only the workflow and calling guidance in the skill.

Encoding the Workflow in Tool Descriptions

Tool descriptions should help the model select a capability and fill its schema. They are a poor substitute for a multi-step operating procedure with examples, exceptions, escalation rules, and output conventions.

Long descriptions inflate every turn in which the tool is exposed and make the service contract harder to reuse. Put the procedure in a skill and keep tool semantics precise.

Building an execute_anything Tool

A generic shell, SQL, or HTTP proxy collapses many permissions into one difficult-to-audit capability. It shifts validation to the model and makes least privilege mostly fictional.

Expose operations aligned to actual business actions. If expert operators truly need an escape hatch, separate it, restrict it, and require stronger approval and logging.

Publishing a Kitchen-Sink MCP Server

A server with dozens of unrelated tools burdens selection, schema context, permissions, and maintenance. Split by coherent domain or let the host expose a relevant subset for the current task.

Hermes Agent’s FastMCP guidance makes a sensible starting recommendation: begin with one to three high-value endpoints and prefer a thin server with clear names and schemas. See the official FastMCP skill documentation.

Treating Tool Hints as Security Policy

An experimental allowed-tools field or a tool’s read-only annotation can improve host behavior, but neither replaces sandboxing and server-side authorization. Metadata may be stale, misconfigured, or supplied by an untrusted component.

Use hints to improve the interface. Use code and infrastructure to enforce the boundary.

Using MCP for Static Knowledge

If a procedure or reference changes only with the repository, a remote round trip adds deployment and availability costs without making the information more authoritative. Package concise material with the skill and version it with the workflow.

Introduce a retrieval service only when the corpus is large, access-controlled, independently updated, or genuinely needs search. Architecture should follow the data lifecycle, not the acronym.

Final Decision: Skill, MCP Server, or Both?

Choose an Agent Skill when the hard part is knowing what to do. Choose an MCP server when the hard part is safely reaching something that changes, belongs to another trust domain, or must enforce a contract.

Choose both when a real workflow needs judgment above a protected capability. That is not duplication: the skill makes the agent useful, the server makes the integration governable, and the backing system makes the final decision authoritative.

For most hosted assistants, the best first architecture is modest: one focused skill, a small MCP surface only where live access demands it, and a captured prompt trace to verify the context cost. Add complexity after the boundary is clear, not before.

References

• Agent Skills specification
• Model Context Protocol specification
• MCP authorization guidance
• Hermes Agent native MCP documentation
• OpenClaw skills documentation
• FastMCP skill documentation