MCP Is Eating Your Agent's Brain: Why OpenClaw Uses CLIs Instead of Schemas

You gave your agent 128K tokens. It spent 92,000 of them just figuring out what tools it has available.

That's the MCP problem. Apideck published a deep dive last week showing that MCP servers inflate token consumption by 4 to 32 times compared to CLI-based tool access. One team burned 72% of their context window before their agent ran a single line of useful work. The rest of the window went to schema injection — the MCP protocol dumping the full definition of every available tool into every single prompt.

OpenClaw doesn't do that. Here's why, and what it means for how you build agents.

What MCP Actually Does to Your Context

MCP (Model Context Protocol) was designed to standardize how agents talk to tools. The idea is sensible: give every tool a machine-readable schema, and the model knows exactly what it can call and how. In practice, this means tool definitions get injected into the prompt at session start.

A single MCP server with 20 tools can add 8,000–15,000 tokens to every request. Ten MCP servers? You've eaten half your context window before the agent does anything.

The problem compounds fast:

• The model can't read ahead. It doesn't know it'll only use 2 of those 20 tools.
• Every turn re-injects the schemas. Stateless prompts mean the full tool list comes back every time.
• Context compression doesn't help here. Tool schemas are dense JSON. Compression degrades them.

Apideck's team found that one production agent setup was spending $0.84 per query just on tool definition tokens — before the actual work. At scale, that's not a rounding error. It's your operating budget.

How OpenClaw's CLI Model Works Differently

OpenClaw agents access tools via CLI commands and shell scripts, not injected schemas. When an agent needs to run a shell command, it calls exec. When it needs to search the web, it calls web_search. The tool contract lives in a handful of lines in TOOLS.md — a human-readable description you write once and don't re-inject.

This is progressive disclosure by design. The agent knows the tool exists. It calls the tool with parameters. The tool runs. Results come back in the response. No schema explosion at the start of every turn.

Here's what that looks like in practice. In a typical TOOLS.md entry:

## web_search
Search the web using Brave. Returns titles, URLs, and snippets.
Use for: current news, competitor research, fact-checking.
NOT for: large file downloads or login-gated content.

That's 40 tokens. An equivalent MCP tool schema in JSON is 800–2,000 tokens, minimum.

Multiply across 10–20 tools and the difference isn't subtle. You're either spending context on housekeeping or you're spending it on work.

What This Means for Your Agent's Behavior

Context budget isn't just a cost problem. It directly affects how well your agent reasons.

Models don't have unlimited working memory. When you flood the early context with tool definitions, you push the actual task further into the middle of the window — where research shows models pay less attention. A context window stuffed with boilerplate JSON is a context window that's harder to reason across.

With CLI-based tools, your agent's context looks like this:

1. Identity and instructions from SOUL.md and AGENTS.md
2. Task or user message
3. Tool calls and results, in conversation order
4. Memory retrieved from MEMORY.md as needed

The signal-to-noise ratio is much higher. The model spends its budget on things that matter.

There's also a sandboxing benefit. Every tool an MCP server exposes exists as a callable schema in the model's awareness. The attack surface is proportional to the schema inventory. In OpenClaw, you control exactly which tools are accessible per agent by what you put in TOOLS.md and your config. No hidden capabilities. No ambient tool inventory for a prompt injection attack to exploit.

When MCP Makes Sense (and When It Doesn't)

To be fair: MCP isn't worthless. If you're building a multi-agent orchestration layer where agents need to discover and call each other's capabilities dynamically, a structured protocol has real advantages. Interoperability matters at that layer.

But most agents people are actually running don't need dynamic tool discovery. They have a fixed set of things they do:

• Read emails, summarize, flag important ones
• Monitor a server, detect anomalies, send alerts
• Pull data from an API, format it, write a report
• Answer questions using a knowledge base

For these agents, loading 20,000 tokens of tool schemas per request is like installing a full inventory management system in your kitchen because you sometimes need to find a spatula.

OpenClaw's model fits the 90% case: you define a stable tool set in plain text, the agent uses what it needs, and the context stays clean.

Practical Config: Keeping Your Tool Surface Lean

If you're setting up an OpenClaw agent now, here's how to structure your TOOLS.md to minimize context waste and maximize clarity:

1. Only document tools the agent will actually use.

Don't paste a full capability list. If your inbox agent doesn't need exec, don't mention exec. An agent that doesn't know it has shell access can't accidentally use it.

2. Write restrictions explicitly.

## exec
Run shell commands. Use ONLY for: checking disk usage, reading log files.
NEVER use for: network requests, installing packages, modifying configs outside /tmp.

This bounds behavior without requiring MCP-style schema validation.

3. Use AGENTS.md for tool usage rules.

The operating manual goes in AGENTS.md. Tool-specific behaviors, approval requirements, and frequency limits live there — not in a schema that gets injected into every prompt.

## Tool Policy
- exec: Ask before running any command that modifies files outside the workspace.
- web_search: Max 3 searches per task. Summarize before searching again.

4. Reference but don't reproduce.

If a tool needs detailed usage notes (API endpoints, auth patterns), link to a separate file rather than dumping it inline. Your TOOLS.md stays short. The detail is available when needed.

The Architectural Answer Was Already Here

The MCP context bloat problem is getting attention now because developers are running real workloads and seeing real bills. It's a design consequence of schema-first protocols — predictable once you're running at scale.

OpenClaw's CLI-based model was built for the opposite assumption: agents have a defined job, not an infinite tool inventory. The architecture keeps context clean, costs predictable, and the attack surface bounded.

If you want to build an agent that actually stays within budget and behaves consistently across a full working day, start with lean files and specific tools. The wizard at OpenAgents.mom walks you through exactly this: define your agent's job, choose its tools, and get a workspace bundle with a TOOLS.md that covers what you need and nothing more.

Build your first lean, production-ready agent workspace at openagents.mom — the guided interview takes under 10 minutes and includes a security-first TOOLS.md by default.