"Agent Skill" and "MCP" show up in the same conversations, and it is easy to end up unsure which one you need. They are not two ways of doing the same thing. A Skill packages instructions that load into the agent's own context. An MCP server is 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, 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 simply knows more than it did, the same as if you had pasted the instructions into the conversation.
The format is small. The Agent Skills specification
asks for one required file, SKILL.md, with YAML frontmatter carrying a name and a
description, followed by instructions in plain Markdown. Beside it you can put
scripts/ for code the agent may run, references/ for longer documentation and
assets/ for templates, all optional.
What 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 arrives when the Skill is activated, and the reference files only when a step needs them. The spec calls this progressive disclosure: dozens installed, one paid for at a time.
What an MCP server actually is
An MCP server is a program running somewhere else. The agent connects and calls the tools it exposes, the way a web app calls an API. Our full explainer on what MCP is has the background; short version, it gives an agent a consistent way to reach a live external system instead of a one-off integration per tool.
Do they replace each other?
No. They solve different problems, and most working setups have 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. They stack.
A real MCP server: how Birta's works
Birta ships an MCP server, reachable two ways depending on how your agent runs. If it works from files on your machine, you connect locally, and 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 capabilities either way. Neither is a Skill: both are MCP, a server your agent connects to and calls rather than instructions it reads.
What the agent 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 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 connections is on the
Birta MCP reference.
Every one is an action the agent could not take alone. 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 ships no Skill of its own. It does not need to, because the server already describes its tools to any agent that connects. But a Skill is the right place for the judgment the server cannot carry: what to check before you publish, and in what order. Here is what one would look like, built only on tools the server 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, and 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 rather than capability, and it costs nothing until the agent decides the task is about publishing and pulls the file in.
To try it, the folder layout is the one our own writing Skills use: a SKILL.md at the
top, a references/ folder beside 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 it needs to do something outside its own context: publish a file, check a version, read a live status. Most real setups use both, the Skill supplying judgment and the protocol supplying action.
A useful test: if you deleted it, what would the agent lose? Delete a Skill and the agent still has every tool, it is just worse at using them. Delete an MCP server and a whole class of actions disappears.
See the MCP server in action
Try either connection, local or remote, and publish something to see the tool calls happen for real. Or skip the setup and describe the page in Birta's chat; its agent uses the same tools.