Skills vs MCP: Local Workflows vs Network Protocol

+15 Mana ✨
Model Context Protocol(DOCUMENTATION)Hermes MCP Support(DOCUMENTATION)

Introduction

MCP (Model Context Protocol) is the other extension surface people often confuse with skills. They scratch different itches. MCP is a wire protocol for exposing tools and resources across processes or even across the network. Skills are local Markdown files loaded into the prompt. Both can extend what an agent can do, but they extend it in different directions.

Key Concepts

  • MCP (Model Context Protocol): An open transport protocol for connecting AI clients to external servers that expose tools, resources, and prompts.
  • MCP server: A process (local or remote) that speaks MCP and offers tools the agent can call.
  • Skill: A local Markdown package that orchestrates tools (which may include MCP-provided tools) into a workflow.
  • Transport vs content: MCP is how tools are delivered to the agent. Skills are what the agent does with the tools it has.

Real World Context

A team uses the GitHub MCP server to expose gh_create_pr, gh_list_issues, and other GitHub tools. They also write a skill called pr-from-branch whose procedure is: run git log, summarize the changes, call gh_create_pr with a clean title and body. MCP provides the GitHub capabilities. The skill provides the workflow that uses them. Neither replaces the other.

Deep Dive

The two systems exist at different layers of the agent stack.

text
┌──────────────────────────────────────────────────────────────┐
  │                       Skill (Markdown)                       │
  │       "Use the GitHub tools to open a PR from a branch"      │
  └────────────────────────────┬─────────────────────────────────┘
                               │ orchestrates
                               ▼
  ┌──────────────────────────────────────────────────────────────┐
  │                     Tool registry (in agent)                 │
  │   ┌────────────────────────────┐   ┌─────────────────────┐   │
  │   │  Built-in (terminal, ...)  │   │  MCP-provided tools │   │
  │   └────────────────────────────┘   └──────────┬──────────┘   │
  └────────────────────────────────────────────────│─────────────┘
                                                   │ network or stdio
                                                   ▼
                                          ┌──────────────────┐
                                          │   MCP server     │
                                          │ (GitHub, Slack,  │
                                          │  filesystem...)  │
                                          └──────────────────┘

A few consequences fall out of this layering:

  1. A skill can call MCP-provided tools. It does not care where the tool came from. To the model, every tool is the same shape (name, description, schema). If the GitHub MCP server is loaded, a skill can reference gh_create_pr just like it references terminal.

  2. An MCP server cannot install a skill. Skills are content the agent already has on disk. They are not delivered over the protocol.

  3. They have different deployment shapes. MCP servers run as processes (often spawned with Docker or uvx). Skills sit as files in ~/.hermes/skills/. Updating a skill is editing a file; updating an MCP server is restarting a process.

  4. They have different trust models. MCP servers run code on your behalf and need permission scoping. Skills run no code of their own; they only describe procedures the agent should follow.

When would you reach for which? If you need to add a new capability the agent does not currently have (a new SaaS API, a private database, a custom action), an MCP server is the right shape. If you need to capture how the agent should combine existing capabilities into a repeatable workflow, a skill is the right shape.

Common Pitfalls

  1. Treating MCP as a skill repository: MCP delivers tools, not skills. You cannot install a skill via MCP the way you install one via hermes skills install.
  2. Writing a skill to wrap a single MCP tool call: If the skill body is just call this MCP tool with these arguments, the skill adds little. The user can call the tool directly. Skills earn their keep by orchestrating multiple steps.

Best Practices

  1. Layer them deliberately: Use MCP servers to bring new capabilities into the registry. Use skills to compose those capabilities into named workflows.
  2. Document MCP prerequisites in the skill: If a skill depends on an MCP server being loaded, say so in the ## When to Use section so the agent and user both know what is required.

Summary

  • MCP is a wire protocol for exposing tools, resources, and prompts across processes.
  • Skills are local Markdown packages that orchestrate tools into workflows.
  • A skill can call MCP-provided tools; MCP cannot deliver skills.
  • Use MCP for new capabilities. Use skills for new workflows over existing capabilities.

Code Examples

yaml
# Conceptual: a skill that depends on the GitHub MCP server
---
name: pr-from-branch
description: Open a clean PR from the current branch, drafting title and body from recent commits.
metadata:
  hermes:
    requires_tools: [gh_create_pr, gh_get_pr]
---
# PR From Branch

## When to Use
User asks to open a PR on the current branch.

## Procedure
1. Run `git log origin/main..HEAD` via the `terminal` tool.
2. Draft a conventional-commit-style title from the latest commit.
3. Summarize the diff in the body.
4. Call `gh_create_pr` (provided by the GitHub MCP server) with the draft.
✓ Completed