"Agent Skill" and "MCP" show up in the same conversations, and it's easy to end up unsure which one you actually need. They aren't two ways of doing the same thing. A Skill packages instructions that load straight into the agent's own context. An MCP server is something else: a separate process the agent calls over a protocol, the way it would call any outside service.
What a Skill actually is
A Skill is a folder of instructions, sometimes with a few scripts attached, that an agent reads into its own context when a task calls for it. Nothing runs outside the agent. No server, no network call, no separate process to keep alive.
The agent just knows more than it did before, the same way it would if you'd pasted the instructions into the conversation yourself. That's the whole idea: a Skill teaches the agent a better way of doing something it could already sort of do.
The format is small. The Agent Skills specification
asks for one required file, SKILL.md, with YAML frontmatter that has a name and a
description, followed by the instructions in plain Markdown. Next to it you can put
scripts/ for code the agent may run, references/ for longer documentation, and
assets/ for templates. All of those are optional.
The part that makes Skills cheap is how they load. At startup the agent sees only each
Skill's name and description, roughly a hundred tokens apiece. The body of SKILL.md
comes in when the Skill is activated, and the reference files only when a step needs
them. The spec calls this progressive disclosure. In practice it means you can have
dozens of Skills installed and pay for one at a time.
What an MCP server actually is
An MCP server is a program running somewhere else. The agent connects to it and calls the specific tools it exposes, the same way a web app calls an API. We've written a full explainer on what MCP is if you want the background. Short version: MCP gives an agent a consistent way to reach a live external system, instead of a one-off integration for every tool it needs to use.
Do they replace each other?
No. A Skill and an MCP server solve different problems, and most working agent setups end up with both.
A Skill can tell the agent how to use an MCP server well: which tool to call first, what to check before publishing, what order to do things in. Neither one makes the other obsolete. They stack.
A real MCP server: how Birta's works
A concrete example beats another diagram. Birta ships an MCP server, and it's reachable two different ways depending on how your agent runs.
If your agent works from files on your own machine, you connect it locally. The command starts a small MCP server as a local process:
npx -y @birta/cli mcpIf your agent runs somewhere else, or you'd rather not run anything locally, you connect to a remote server over HTTP instead, using the same setup as any hosted MCP connection:
claude mcp add --transport http birta https://birta.dev/mcpSame product, same set of capabilities either way. Neither of these is a Skill. Both are MCP: a server your agent connects to and calls, not instructions it reads into its own context.
What the agent actually gets from that connection is a list of named tools. It can
list_projects and create_project, open a draft with create_version, fill it with
write_file and edit_file, read the remarks the owner left on the draft with
list_version_comments, and put it live with publish_version. There are tools for
domains (connect_domain, verify_domain), lead forms (create_form, list_leads),
visitor stats, and rollback. The full list, for both the hosted and the local
connection, is on the Birta MCP reference.
Every one of those is an action the agent could not take on its own. That is the tell for MCP: the capability lives on the other side of the connection.
A real Skill: a publish checklist that drives those tools
Birta does not ship a Skill of its own. It doesn't need to, because the server already describes its tools to any agent that connects. But a Skill is exactly the right place for the judgment the server can't carry: what to check before you publish, and in what order. So here is what one would look like, built only on tools the server actually exposes.
---
name: birta-publish-checklist
description: Publish a static site to Birta through its MCP tools without skipping review. Use when the user asks to publish, ship, or go live with a site on Birta.
---
1. Call `list_projects`. If the site has no project yet, `create_project`.
2. Call `list_versions`. If a draft already exists, work in it. Otherwise call
`create_version` with `from_version` set to the live version, so you change
only what you need.
3. Make the edits with `write_file` or `edit_file`. Confirm `index.html` is at
the site root with `list_files`; publishing is refused without it.
4. Stop. Give the owner the draft address and wait for their reply.
5. Call `list_version_comments` on the draft. Fix every open thread in the same
draft. Do not open a second one.
6. Only when the owner says it is good, call `publish_version` with a one-line
note. Report both addresses it returns: the live site and the review page.
7. If the owner reports a problem after publishing, use `list_versions` and
`rollback` to the previous number rather than editing live.Read that again with the distinction in mind. The Skill contains no code that publishes anything. It cannot create a project or write a file. Every verb in it is a call to the MCP server, and the server would accept those calls in any order.
What the Skill adds is the order, and the two places where the agent should stop and wait for a person. That is knowledge, not capability, and it costs nothing until the moment the agent decides the task is about publishing to Birta and pulls the file in.
If you want to try this yourself, the folder layout is the same one our own internal
writing Skills use: a SKILL.md at the top, a references/ folder next to it when the
instructions grow. Drop the folder where your agent looks for Skills, connect the MCP
server, and ask it to publish something.
Skill vs. MCP, side by side
| Agent Skill | MCP server | |
|---|---|---|
| What it is | A folder with a SKILL.md and optional scripts and references | A running program that speaks the Model Context Protocol |
| Who hosts it | Nobody. It sits on disk where the agent looks for Skills | Whoever runs the process: you, locally, or a service like Birta over HTTP |
| Who executes | The agent itself, inside its own context | The server, on the other side of the connection |
| What it carries | Instructions, judgment, order of operations | Capabilities: named tools with typed inputs and live results |
| When it loads | Name and description at startup; the body only when activated | Tool list on connect; each tool when the agent calls it |
| What it can reach | Only what the agent could already reach | Whatever the server has access to |
| Reach for it when | The agent knows how to do the task badly and you want it done well | The agent cannot do the task at all without an outside system |
| How they combine | The Skill says which tools to call, and when to stop and ask | The server does the work when a tool is called |
When to reach for which
Reach for a Skill when you want the agent to know how to do something well.
Reach for MCP when the agent needs to actually do something outside its own context: publish a file, check a version, read a live status. Most real setups use both. The Skill supplies the judgment, the protocol supplies the action.
A useful test: if you deleted it, what would the agent lose? Delete a Skill and the agent still has every tool it had, it's just worse at using them. Delete an MCP server and a whole class of actions disappears. That is the difference in one move.
Connect an agent and see the MCP server in action
Try either connection, local or remote, and publish something to see the tool calls happen for real.