Our OpenCode setup runs seven MCP servers in its config file and reads 30 skills from a folder, and the two do different jobs even when both end up touching the same website. MCP gives an agent a way to act: fetch a page, drive a browser, schedule a task. A skill gives it a way of working: the steps, rules and files for a job it would otherwise improvise. Agent skills vs MCP is less a choice between two options than a question of which half of a task each one covers, and this piece sets that out from the two specifications and from what we run.
Our examples come from OpenCode, Claude Code, Hermes Agent and Pi on our test machine, a 48 GB M4 Pro, in September 2026.
What is the difference between agent skills and MCP?
The Model Context Protocol is a wire protocol. Its introduction calls it “an open-source standard for connecting AI applications to external systems”. An application such as Claude Code or OpenCode is the host. For each server it connects to, the host creates a client, and the server is “a program that provides context to MCP clients”, according to the MCP architecture overview.
A server offers three kinds of thing. The overview lists tools, “executable functions that AI applications can invoke to perform actions”; resources, “data sources that provide contextual information”; and prompts, “reusable templates that help structure interactions with language models”. Messages are JSON-RPC 2.0, carried over standard input and output for a server on the same machine or over Streamable HTTP for a remote one.
An agent skill is a folder on disk. Anthropic’s Agent Skills overview describes skills as “reusable, filesystem-based resources” containing instructions, scripts and reference material, with a SKILL.md file that opens with a name and a description. No server runs and no protocol is spoken. The agent reads files with the same file and shell tools it already has.
So an MCP server adds capabilities the agent does not have, and a skill tells the agent how to use capabilities it does have. A skill can say “check the internal links with curl before publishing”; an MCP server is what lets an agent without a shell reach the web in the first place.
| Agent skill | MCP server | |
|---|---|---|
| What it is | A folder with SKILL.md and optional files | A running program speaking JSON-RPC 2.0 |
| What it adds | Instructions, reference files, scripts | Tools, resources and prompts |
| How the agent reaches it | Reads files from disk | Calls the server through a client |
| Where it runs | Inside the agent’s own environment | Locally over stdio or remotely over HTTP |
| Setup | Put a folder where the agent looks | Configure a command or URL, keep it running |
How agent skills and MCP servers use an agent’s context window
Anthropic’s overview describes skills as loading in three levels. The name and description load at startup, which the overview puts at about 100 tokens per skill. The body of SKILL.md loads only when a request matches, with guidance to keep it under 5,000 tokens. Bundled files load only when read, and scripts run through the shell, so “only their output enters context”.
On our machine the startup cost is the descriptions. Our 37 skills carry 15,702 characters of description in total. Their bodies are far larger, with a median of 5,036 characters and a largest of 40,999, but a body stays on disk until the agent opens that skill.
MCP servers work the other way by default. The MCP overview explains that an application fetches the tools from every connected server and combines them “into a unified tool registry that the language model can access”. Each tool arrives with a name, a description and a JSON Schema for its inputs. The overview also mentions progressive tool discovery for clients that connect to many servers, but that depends on the client implementing it.
This matters on a local model with a fixed window. OpenCode’s system prompt on our machine measured about 51,700 tokens, which is why its model has to be loaded at 64K context or more, as we found when an agent’s system prompt outgrew its context window. One comment in our own OpenCode config describes a ComfyUI MCP server with more than 80 tools. We keep that server switched off.
Agent skills vs MCP in OpenCode: what we run in each
OpenCode’s config file on our machine lists seven MCP servers, four of them enabled:
| MCP server | State | What it gives the agent |
|---|---|---|
fetch | Enabled | Reads web pages and JSON from a URL |
filesystem | Enabled | Read and write access limited to seven named folders |
playwright | Enabled | Browser automation in a separate Chrome profile |
cron | Enabled | Scheduled shell commands and prompts, sent to our local model in LM Studio |
searxng | Disabled | Meta-search through a local SearXNG instance |
wordpress | Disabled | WordPress through a plugin; discovery worked, running actions did not |
comfyui | Disabled | Local image generation through ComfyUI |
Every one of those is a capability: something the agent could not do with its built-in tools. The filesystem server also shows MCP’s other use, which is to narrow access. It lists seven folders, so the agent can read our voice guides and publishing rules and nothing else under that server.
The WordPress server is a case where MCP was the wrong layer. The config note records that the plugin’s discovery step listed its abilities but could not run them, so the agents use fetch and the WordPress REST API instead. A skill now carries the rules for that work.
The skills are the other half. OpenCode reads 30 of them, including our editorial voice, our universal writing rules and a WordPress publishing checklist. None of them adds a capability. They tell the agent which files to read first, which words are banned and which checks must pass before a draft is saved. Claude Code has 4 skills and one project MCP server, and Hermes Agent has 99 skills and no MCP servers in its config. Hermes does most of its work through built-in tools and skills.
When to write a skill and when to add an MCP server
The test we use is whether the agent is missing an ability or missing knowledge.
Add an MCP server when the agent cannot reach something: a service with no command-line tool, a browser session, a database, a remote system that needs authentication. The server is also the right place for a hard boundary, such as a folder list the agent cannot talk its way past.
Write a skill when the agent can already do the work but does it inconsistently. Publishing rules, a house style, a checklist, a sequence of commands in the right order: all of these are knowledge, and a skill costs about a hundred tokens until it is needed. A skill can also bundle a script, which gives a fixed, repeatable operation without a server to keep running.
Most real tasks use both. Publishing a draft on our site uses the shell and HTTP to reach WordPress and a skill to decide what a publishable draft looks like. The same split applies to setting up tool calling for a local model: the model must handle the tool format before any MCP server is useful to it.
Skills also fail differently. An MCP server that is down produces an error. A skill that points at a file which has moved loads normally and quietly does nothing, a failure we traced when a folder rename broke 106 paths across our own skills. That difference is the strongest argument for keeping skills short and their file references few: a broken tool announces itself, and a broken skill does not.