MCP (Model Context Protocol) defines the wire protocol — how agents discover and call tools. It’s the plumbing. Standardized, well-adopted, essential.
ACR (Agent Capability Runtime) manages what goes into the agent’s context window — which capabilities are loaded, at what resolution, with what budget. It’s the OS layer on top of the plumbing.
They solve different problems:
| Concern | MCP | ACR |
|---|---|---|
| Tool discovery | ✅ Server listing | ❌ Not its job |
| Tool execution | ✅ JSON-RPC | ❌ Not its job |
| Context budget | ❌ | ✅ LOD, eviction, promotion |
| Dynamic loading | ❌ | ✅ Triggers, mount/unmount |
| State persistence | ❌ | ✅ Serialize across eviction |
| Multi-resolution | ❌ | ✅ index/summary/standard/deep |
MCP tells the agent what tools exist. But MCP doesn’t answer:
Which tool instructions should be in context right now? An agent with 50 MCP tools doesn’t need all 50 instruction sets loaded. ACR provides LOD-based loading — full instructions for active tools, one-liners for the rest.
What happens when context gets full? MCP has no concept of context pressure. ACR manages budget, evicts low-priority capabilities, demotes resolutions, and preserves state across eviction.
How do tools compose? MCP tools are independent endpoints. ACR capabilities declare dependencies, co-activation rules, and provide/require contracts.
An ACR capability can wrap one or more MCP tools:
name: linear
requires:
tools:
- mcp-linear-create
- mcp-linear-search
- mcp-linear-update
When the linear capability is mounted, ACR ensures:
For agents with many MCP servers, ACR provides the missing orchestration:
index level (~10 tokens each)Without ACR, agents load all MCP tool instructions at once — burning context budget on tools they may never use.
MCP standardizes the wire. ACR standardizes the context. Together, they give agents:
ACR is not a replacement for MCP. It’s the layer that makes MCP-equipped agents smarter about what they load, when they load it, and how they manage the finite resource of the context window.