Anthropic's MCP Playbook Is for Builders. Defenders Need the Next Layer.
Anthropic published yesterday what reads as the production playbook for MCP. The title does the work: Building Agents That Reach Production Systems with MCP. Server design, tool grouping, remote transports, standardised auth, the skills-plus-MCP pairing. Read it as the first chapter of a book Anthropic is writing for the teams wiring agents into the systems that actually matter.
The numbers underneath are the part worth sitting with. MCP SDK downloads exceeded 300 million a month, up from 100M at the start of the year. MCP sits under Claude Code, Claude Cowork, and Claude Managed Agents. Millions call MCPs through Claude every day. When Anthropic says agents are reaching production, this is what they mean — it’s already happening, at scale, through the protocol they are now prescribing patterns for.
The playbook is excellent. And it ends one layer above the question defenders have to answer.
What the playbook covers
The advice is aimed at builders — teams standing up MCP servers. The recommendations are specific and sound:
- Build remote servers. Only remote configurations reach web, mobile, and cloud agents. Stdio-only is a dead end for distribution.
- Group tools by intent. A single
create_issue_from_threadbeats four primitives an agent has to compose. Fewer, higher-level tools outperform exhaustive API mirrors. - Code-orchestrate large surfaces. For Cloudflare, AWS, and Kubernetes-scale APIs, expose thin tools that accept code. Cloudflare’s MCP server covers ~2,500 endpoints through ~2 tools in 1K tokens. That number is the whole argument for the pattern.
- Ship MCP Apps. Return interactive interfaces inline — charts, forms, dashboards — rather than bouncing the user to a separate surface.
- Standardise auth. CIMD for first-time OAuth, credential vaults for token storage and refresh, agents never touching raw tokens.
- Pair skills with MCP. Skills carry procedural knowledge, MCP carries tools and data, and the most capable agents use both.
Each of these is a real improvement over what most MCP servers look like today. Each of them also enlarges the surface an agent can reach through a single connection.
Where the playbook stops
The playbook answers three questions well: how does the server work, what capabilities does it expose, who is allowed to connect. All three bottom out at the same point — once the agent is authenticated and the tool call is issued, the playbook is silent.
That silence was already expensive when MCP servers looked like thin API mirrors. The code-orchestration pattern makes it sharper. Cloudflare’s graphql_query and api_request can, legitimately, do anything Cloudflare can do. The agent submits a snippet, the server evaluates it, an upstream call goes out. The tool is uniform. The behaviour is the argument.
Server-level auth can say “yes, this agent may talk to Cloudflare.” It cannot say “this agent may read DNS records but not delete zones.” Tool-level allowlists can say “yes, api_request is permitted.” They cannot say “api_request is permitted except when the payload calls DELETE /zones/:id.” Once the surface behind a single tool becomes a programming language, the only governance primitive that still means anything is the argument.
The same logic compounds with skills. A skill is procedural knowledge that teaches the agent how to use a set of tools to get something done. Pair it with an MCP server and the agent composes tool calls more fluently, more often, across more systems. The playbook calls this a feature. It is — and it makes the behaviour-control question the dominant one, not a trailing concern.
What the missing layer looks like
Move the primitive down. The tool call is the unit. The arguments are the object of governance. Policy evaluates before the upstream request goes out, deterministically, with state.
version: "1"
default: deny
tools:
graphql_query:
rules:
- name: "read-only"
match:
args.query.contains_any: ["mutation", "delete", "purge"]
action: deny
api_request:
rules:
- name: "zones-read-only"
match:
args.method: ["POST", "PUT", "PATCH", "DELETE"]
args.path.matches: "^/zones/"
action: deny
create_issue_from_thread:
rules:
- name: "rate-limit"
rate:
per_agent: 20/hour
Three properties matter. It is deterministic — same call, same decision, every time. It is stateful — rate limits, spend caps, and running totals live in real storage, not conversation history. It is physically preventive — the model can generate whatever tokens it likes, but the upstream request does not happen unless policy allows it.
This is the layer the playbook does not cover. Not because Anthropic missed it — because it is not the model maker’s job to solve. Anthropic ships the protocol and the patterns. The enforcement primitive sits between the agent and the server, evaluates arguments against policy, and belongs in its own product with its own vocabulary.
Two chapters, one stack
The playbook chapter is necessary. Thin, well-designed tools over code orchestration, remote transports, standardised auth, skills-plus-MCP pairing — this is what production agents need to be useful. Every enterprise adopting agents will end up following most of it.
The chapter underneath is the one defenders have to write. Once the plumbing is excellent and the access is governed, the question left is what agents are allowed to do through that plumbing. That question is not answered by better server design. It is answered by deterministic policy on the tool call, evaluated on arguments, enforced before the call reaches upstream.
PolicyLayer is the control plane for AI agent tool use. It proxies MCP traffic and evaluates every tool call against policy before execution. Anthropic has written the playbook for wiring agents into production. The part underneath — what those agents may actually do once they are in — is the next layer.
Ready to add policy enforcement to the MCP stack?
- Get started with Intercept — open source, Apache 2.0
- Policy templates — Stripe, GitHub, Cloudflare, AWS, and more
- Read the Anthropic post — the playbook in full
Protect your agent in 30 seconds
Scans your MCP config and generates enforcement policies for every server.
npx -y @policylayer/intercept init Or read the MCP Security reference