Skip to main content

MCP Gives Agents Tools. Agent Skills Gives Them Runbooks.

7 min readDora NodaDora Noda
Share
On this page

One team measured what happens before their agent even reads a prompt: seven MCP servers loaded their tool definitions into context and burned 67,300 tokens — a third of a 200K context window — before the user typed a single word. Anthropic's own GitHub MCP server alone accounts for 17,600 tokens of tool schemas. Every MCP tool a server exposes costs somewhere between 550 and 1,400 tokens just to describe itself: name, JSON schema, parameter docs, enum values.

That's the price of connectivity — an agent knowing a tool exists and how to call it. It says nothing about competence — an agent knowing what to do when that tool call fails in one of the six ways it usually fails. Today, teams solve competence the same way they solve connectivity: they cram the troubleshooting steps into the tool's description, and pay for it on every single session, whether or not anything ever breaks. Anthropic's Agent Skills format, released as an open standard in December 2025, exists specifically to stop paying that tax. For a deploy-from-chat MCP server — where a deploy or rollback tool call routinely needs a real debugging runbook behind it — that distinction is the whole ballgame.

What a Skill Actually Is

A Skill is a folder. At minimum, it contains one file, SKILL.md, which opens with YAML frontmatter and a name and description:

markdown
---
name: debug-failed-deploy
description: Use when a bex deploy fails or a rollout gets stuck. Walks through reading build logs, identifying the failure class, and choosing between a fix-and-redeploy or a rollback.
---
 
## Diagnosing a failed build
 
1. Pull the last 200 lines of build output with `fleet_logs(app, phase="build")`.
2. Match against the signature table in `reference.md` — OOM-killed builds,
   missing buildpack detection, and dependency-resolution failures each have
   a distinct log fingerprint.
3. If the failure is transient (network timeout pulling a base image),
   retry once before touching anything else.
...

The rest of the folder can hold whatever the task needs: a reference.md with a table of build-error signatures, a fetch-logs.py script, a template for a rollback confirmation message. Anthropic's design for how an agent consumes this is deliberately three-tiered, and the tiering is the entire point:

  1. Discovery — at startup, the agent loads only the name and description of every installed Skill into its system prompt. Tens of tokens, not thousands.
  2. Activation — when a task matches, the agent reads the full SKILL.md body into context.
  3. Execution — the agent follows the instructions, pulling in bundled scripts or reference files only as it needs them.

Nothing about a build that succeeds ever pays for the troubleshooting runbook. Nothing about a support ticket for the billing tool ever pays for deploy debugging. The cost shows up exactly once, exactly when it's relevant.

The Worked Example: What a Runbook Costs, Three Ways

Take a concrete case that maps directly onto a deploy-from-chat platform: a "how to debug a failed deploy" runbook, written out at a realistic ~2,500 words — roughly 3,300 tokens once tokenized. Every infra MCP server needs something like this; the question is where it lives.

Option A — inline in one tool's description. You fold the runbook into the deploy tool's description so the model has it on hand when a build fails. Using the measured 550–1,400-token-per-tool range as a baseline for a plain tool, a deploy tool bloated with an embedded runbook lands closer to 3,300–4,000 tokens on its own. That cost is paid on every call to list available tools, for every session, whether the deploy that runs is the platform's ten-thousandth successful one or its first failure.

Option B — duplicated across the tool surface. This is the realistic failure mode, not a strawman: nobody centralizes documentation on day one, so pieces of the same runbook end up pasted into deploy, rollback, fleet_status, fleet_logs, and a couple of others — because each tool's author reasonably wants the model to know what to do when their tool's failure mode shows up. Six tools, each carrying a meaningful slice of that ~3,300-token runbook, pushes total schema overhead for this one concern into five figures of tokens — paid at the start of every session, again regardless of whether anything ever breaks.

Option C — a bundled Skill. The deploy, rollback, and fleet_status tools stay plain MCP tools: a name, a schema, a one-line description, in the 550–1,400-token range each. The debugging runbook lives in a debug-failed-deploy Skill instead. At discovery, that costs the name + description shown above — roughly 20–40 tokens. The full 3,300-token runbook loads exactly once: in the session where a build actually fails and the agent recognizes the Skill applies.

Where the runbook livesCost paid every sessionCost paid when a deploy fails
A — inline in deploy's description~3,300–4,000 tokens(already paid)
B — duplicated across ~6 tools10,000+ tokens(already paid)
C — bundled Skill~20–40 tokens~3,300 tokens

The gap isn't a rounding error — it's the difference between paying for a runbook once, in the one session that needs it, versus paying for it on every deploy that goes fine. Multiply Option C's discovery cost by however many other runbooks a platform eventually wants an agent to have — rollback safety checks, TLS-renewal troubleshooting, a "reading a stuck Cluster API machine" guide — and the schema-bloat curve for tools stays flat while the agent's actual competence keeps growing.

Why This Isn't Just a Token-Saving Trick

The reason this split works is architectural, not just economical. Anthropic is explicit that MCP and Agent Skills solve different problems: MCP provides secure connectivity to external tools and data — the deploy call itself, authenticated and schema-validated. Agent Skills provide the procedural knowledge for using that connectivity well — what to actually do with the tool once you're allowed to call it. One is about access; the other is about judgment. Treating a debugging runbook as a Skill instead of a tool description isn't a workaround for context limits — it's putting the knowledge in the layer that was designed to hold it, and getting the token savings as a side effect of a cleaner separation of concerns.

What a Deploy-From-Chat MCP Server Should Borrow

For a bex-style MCP server, the split is concrete. The tool surface — deploy, rollback, fleet_status, fleet_logs — stays thin: Render-compatible calls with tight schemas, exactly what MCP is for. The judgment calls that surround those tools become bundled Skills instead of ballooning the tool descriptions:

text
skills/
  debug-failed-deploy/
    SKILL.md          # when to use it, the diagnostic steps
    reference.md       # build-error signature table
    fetch-logs.py       # pulls + filters the last N lines by phase
  safe-rollback/
    SKILL.md          # pre-rollback checks, confirmation wording
  domain-tls-troubleshooting/
    SKILL.md

An agent driving a deploy that fails discovers debug-failed-deploy is relevant (from its one-line description, already in context), reads the full runbook, and — only if the log signature calls for it — runs fetch-logs.py or opens reference.md. An agent driving a deploy that succeeds never touches any of it. That's the deploy tool surface staying exactly as lean as its schema requires, with all the operational knowledge a support engineer would want an agent to have living where it only costs something when it's used.

A Fast-Moving Standard, Not a Claude Quirk

This is worth building for regardless of which agent a user drives bex from. Agent Skills launched in October 2025, and Anthropic published the format as an open specification at agentskills.io on December 18, 2025 — no longer a Claude-only convention. By June 2026, roughly 40 products across the ecosystem had adopted it, including OpenAI Codex, GitHub Copilot, Cursor, VS Code, Gemini CLI, and Goose. A SKILL.md folder bundled with bex's MCP server isn't a bet on one vendor's client — it's a bet on a format most of the coding-agent market converged on within a single quarter.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP server designed for agents as first-class operators, not an afterthought bolted onto a human dashboard. Star the repo on GitHub or deploy your first app today.

Sources

All figures cited above are drawn directly from the linked sources.

Related articles

Give your agents a chain backend

Autonomous agents hit RPC endpoints very differently than people do. See what bex router handles on their behalf.

Read the agents guide