Your MCP Servers Are Eating Your Context

Mine were too. Then I found this.

I love MCP. Model Context Protocol is genuinely one of the best things to happen to Claude Code.

I also hate MCP.

Because every MCP server I add is another pile of tool definitions crammed into my context window. Supabase. Betterstack. Sentry. Playwright. Each one brings 5-15 tools. That’s 40+ tool definitions sitting there, burning tokens, even when I’m just asking Claude to fix a typo.

The technical term for this is “token bloat.” The accurate term is “I’m paying for tools I’m not using.”

The Obvious Solution (That Doesn’t Work)

“Just load MCPs on demand!”

Revolutionary concept. Except Claude Code doesn’t support hot-reloading MCP servers. You pick your MCPs at session start, and that’s your life now. Want to add Sentry mid-session? Restart. Lose your context. Start over.

Nobody should have to live like that.

The Agent Escape Hatch

Here’s where it gets interesting.

Claude Code has agents. Agents can spawn with specific tools. So naturally, I thought: what if I keep my main session lean, and spawn agents when I need MCP access?

Main session stays clean. Agent does the Supabase query. Returns results. Everybody’s happy.

Except.

The Inheritance Problem

Agents inherit MCP tools from their parent session.

Read that again.

If I want my debug agent to call Supabase, Supabase MCP must be loaded in my main session. The agent can restrict which tools it uses, but it can’t access tools the parent doesn’t have.

So I’m back to loading everything upfront. The bloat remains. The horror.

Poor Man’s MCP

Fine. If agents can’t get MCP tools independently, maybe they don’t need MCP at all.

Agents have Bash. Bash has curl. These services have REST APIs.

What if I wrote thin wrapper scripts?

debug-api sentry-issue PROJ-123
debug-api supabase-query users "id=eq.abc123"
debug-api betterstack-logs "error" --from "2024-01-15"

Each wrapper hits the API directly, returns JSON. Agent calls wrappers, correlates results, returns findings. Main session stays lean.

I even started designing a mini-spec. Self-describing tools via --tools. Consistent JSON envelope. Exit codes for quick status checks.

MCP-lite. Poor man’s MCP. Whatever you want to call it.

It would work. But I’d be rebuilding what MCP already does, just... worse.

Wait. Why Can’t Agents Just Call MCP Directly?

This is where my brain finally caught up.

MCP servers are just processes. They communicate via JSON-RPC over stdio. Claude Code starts them, maintains connections, sends calls.

An agent with Bash could do the same thing.

Start server. Send JSON-RPC. Parse response. Kill server.

No inheritance needed. The agent IS the MCP client.

The Tool That Already Exists

Before I started writing my own MCP client in bash (a decision I would have regretted), I searched.

mcptools exists.

brew install f/tap/mcp

# List available tools
mcp tools @supabase/mcp-server

# Call a tool directly
mcp call @supabase/mcp-server query '{"sql": "SELECT * FROM users"}'

Start server. Make call. Get result. Server shuts down.

This is the missing piece.

The Pattern I’m Testing

Main Session (ZERO MCP tools loaded)
    |
    └── spawn debug-backend agent
            |
            ├── mcp call @supabase/mcp-server query '{...}'
            ├── mcp call @sentry/mcp-server get-issue '{...}'
            └── mcp call @betterstack/mcp-server search '{...}'
            |
            Returns structured findings

Main session keeps full conversation context. Agent spawns with just Bash. Agent discovers and calls MCP tools on-demand. Zero token bloat.

For frontend debugging, same pattern with Playwright:

mcp call @playwright/mcp-server navigate '{"url": "..."}'
mcp call @playwright/mcp-server screenshot '{}'

What I’m Still Figuring Out

I haven’t battle-tested this yet. Open questions:

• Auth handling: Do all MCP servers pick up env vars correctly when spawned fresh?

• Cold start latency: Is spawning a server per-call too slow for rapid iteration?

• Error recovery: What happens when the MCP server crashes mid-call?

• Which servers play nice: Some MCP servers might not like the start-stop lifecycle.

If you try this pattern, let me know what breaks.

The Punchline

I spent hours designing “MCP-lite” before realizing I could just... call MCP directly from agents.

Learn from my suffering.

The tools exist. The pattern is sound. The token bloat is optional.

Now I just need to actually use this for a month and see what explodes.