MCP vs Agent Skills: What Each Is For and When to Use Both

MCP vs Agent Skills: The Short Answer

MCP gives an agent a connection to something outside itself. Agent Skills give an agent a procedure for doing something well. A skill can tell the agent to call an MCP tool, and an MCP server can serve a skill, which is why the two sit at different layers rather than competing for the same job.

Anthropic states the relationship directly in its engineering write up on equipping agents with Agent Skills, describing how Skills "complement Model Context Protocol (MCP) servers by teaching agents more complex workflows that involve external tools and software". The same post publishes Agent Skills as an open standard for cross-platform portability.

What We Measured Across 71 Skills

Every comparison of these two formats mentions context cost, and almost none of them show a number you can reproduce. So we measured our own library, which is public and can be checked line by line.

The mechanism being measured is progressive disclosure, which Anthropic defines as three levels. Level one is the name and description, which it describes as providing "just enough information for Claude to know when each skill should be used without loading all of it into context". Level two is the full SKILL.md body, read only when the agent judges the skill relevant. Level three is bundled files the agent opens on demand.

Method. We walked every SKILL.md file in the TestMu AI skills library, parsed the YAML frontmatter, and measured two quantities per skill: the level one payload, meaning the name and description fields alone, and the complete file. Characters and words are reported rather than tokens, because character counts are exact and reproducible on any machine without a tokenizer, and the ratio between the two holds regardless of which tokenizer you use.

$ node measure.mjs

=== TestMu AI agent-skills: progressive-disclosure measurement ===
SKILL.md files                : 71
-- LEVEL 1 (name + description, always preloaded) --
  total characters            : 33,016
  total words                 : 4,404
  median chars per skill      : 383
  min/max chars per skill     : 170 / 1023
-- FULL SKILL.md (level 2, loaded only on trigger) --
  total characters            : 402,822
  total words                 : 47,385
  median chars per skill      : 5259
  median lines per skill      : 174
  largest SKILL.md (chars)    : 12125
-- RATIO --
  level1 / full (chars)       : 8.20%
  reduction if only L1 loaded : 91.80%
  full/L1 multiple            : 12.2x

Across all 71 skills, the always resident metadata comes to 33,016 characters against 402,822 characters of full body content. Level one is 8.2 percent of the library, a 12.2x multiple between what the agent always carries and what exists to be loaded.

The comparison point on the MCP side comes from Anthropic's own engineering post on code execution with MCP, which states that "most MCP clients load all tool definitions upfront directly into context". That is the structural difference in one sentence. Skills defer, and MCP clients typically do not.

• The median skill is small at level one - 383 characters of metadata, roughly the length of this bullet plus the one below it.
• The median skill is not small at level two - 5,259 characters and 174 lines, which is why loading all 71 bodies at once would be the wrong design.
• The spread matters more than the average - level one payloads run from 170 to 1,023 characters, so a badly written description costs six times what a tight one does.
• Reproduce it yourself by cloning the library and counting the same two quantities, since both numbers come from files in the repository rather than from a vendor dashboard.

Where MCP and Agent Skills Actually Differ

Context cost is the difference people quote most, and it is the one that matters least once you have chosen sensibly. The differences below decide who can maintain the thing after you ship it.

If your comparison is against a terminal interface rather than packaged instructions, the trade-offs shift again and are covered in MCP vs CLI for AI agents. For the protocol level view of how MCP differs from a traditional API, including its authorization flow, that breakdown covers the specification detail this section summarises.

When an Agent Skill Is the Right Call

Reach for a skill when the agent can already touch everything it needs and still produces work you would reject in review. That is a judgment problem, and instructions fix judgment problems.

• Encoding conventions - your fixture layout, naming rules, assertion style, and the wait strategy your team settled on after the last flaky sprint.
• Procedures with a fixed order - reproduce, isolate, capture evidence, then file, where the sequence is the value rather than any single step.
• Knowledge that changes slowly - a stable convention is cheap to keep correct in a file, whereas a fast moving external system is not.
• Work that must survive the agent choice - the same folder is read by Claude Code, Cursor, and Copilot, so the investment is not locked to one vendor.
• Anything that belongs in code review - if a teammate should be able to object to the rule in a pull request, it belongs in a file rather than in a deployed service.

TestMu AI publishes its testing conventions this way, and how Agent Skills encode your testing conventions walks through the file anatomy and install paths in detail. Kane CLI is distributed the same way rather than as an MCP server. It is a deterministic browser agent that validates rendered UI in a real Chrome browser from natural language objectives, and the skill that ships with it teaches an agent when to invoke it, how to build the command, and how to parse the NDJSON event stream its agent mode returns. The capability is a binary the agent can already run, so the missing piece was instruction rather than connection.

When an MCP Server Is the Right Call

Reach for MCP when instructions cannot help, because the agent has no path to the thing it needs. No amount of markdown grants access to a hosted dashboard or a credentialed API.

• Live system access - build history, session logs, or device availability that exists behind a service and changes by the minute.
• Credential isolation - the protocol defines an authorization model, so the server holds the secret and the agent works with scoped access instead.
• Many clients, one capability - a single server serves every agent your team runs, rather than each repository carrying its own copy.
• Audited operations - calls arrive at a service you control, which is where logging and rate limiting can actually live.
• Fast changing surfaces - one server update fixes every consumer at once, with no repository needing to pull a new file.

The TestMu AI MCP servers follow that split, covering test orchestration, automation session debugging, visual comparison, accessibility checks, and test lifecycle management. Each one exists because the data lives on the platform rather than on the developer's laptop. If you are wiring one up for the first time, connecting your first MCP server to Claude covers client configuration, and the TestMu AI MCP server documentation lists the available tools.

Note: Connect your AI agent to real build logs, session details, and 10,000+ real devices with TestMu AI. Start free!

Running Both in a QA Workflow

Flaky test triage is the clearest case for using both, because it needs live data the agent cannot reach and a procedure the agent will not invent correctly on its own.

• The skill triggers on the request to investigate an intermittent failure, because its description matches that task.
• The skill instructs the agent to pull the last several runs of that test through an MCP tool, which is the step it cannot do alone.
• The skill supplies the comparison procedure, telling the agent to separate genuine product failures from timing and environment noise before drawing a conclusion.
• The agent proposes a fix in the convention the skill defines, so the diff arrives in your house style rather than a generic one.
• The change goes through review, where the skill itself is a reviewable file if its guidance turned out to be wrong.

Each layer does the part the other cannot. Strip out the MCP server and the agent guesses at run history it cannot see. Strip out the skill and it has the data but no method, which produces a plausible answer that a reviewer then has to check from scratch.

Skills Over MCP: How the Two Are Converging

Treating these as rival formats is already out of date, because the MCP project is standardising how skills travel over MCP itself. The Skills Over MCP Working Group exists to define how agent skills "are discovered, distributed, and consumed through MCP".

• Formal status - it started as an interest group in February 2026, was chartered in April 2026, and became a working group two days later.
• Current direction - a Skills Extension on the extensions track, built on MCP's existing resources primitive rather than a new primitive.
• Who is in the room - it is co-led by maintainers from Anthropic and Nordstrom, with participants from Google, GitHub, AWS, Bloomberg, Databricks, and Saxo Bank.
• Stated goal - interoperable skill distribution across MCP servers and clients, which is a convergence rather than a contest.

The practical read for a QA team is that neither format is a dead end. A skill written today stays a plain folder, and the work underway is about giving it another distribution channel rather than replacing it.

Failure Modes and Telling Which Layer Broke

When an agent misbehaves with both layers installed, the symptom usually tells you which one to open first.

For the MCP half of that table, the MCP Inspector lets you exercise a server's tools directly, which separates a broken server from an agent that chose badly. If the conclusion is that you need your own server, building an MCP server step by step covers transports and the request lifecycle.

Conclusion

Start by writing down the last agent output your team rejected, then ask whether it failed because the agent could not reach something or because it did not know how you work. Access problems are MCP problems. Method problems are skill problems, and they are far more common on teams that have already connected their tooling.

A skill is the cheaper experiment either way, since it is one markdown file with two required fields and it goes through the same review as your code. Install the TestMu AI skills for your framework, point your agent at a real suite, and see how much of the gap closes before you deploy any infrastructure. When the remaining gap is access to live builds, sessions, or devices, the MCP servers built for test automation are the layer to add next.