🛠️ A Practical Meta-MCP Architecture for Claude Code: Compressing 60+ Tools into Just Two

Introduction

When using multiple MCP servers in Claude Code (e.g., Notion, Playwright, Chrome DevTools),
the tool definitions alone can consume 36.6k tokens of context.

To reduce this overhead, I built a meta MCP server called Code Mode, which exposes only two tools:

• search_docs — search API definitions of child MCP servers
• execute_code — run TypeScript that calls MCP bindings

This reduced the token usage from 36.6k → 4.4k tokens (−88%).

This post explains the approach, the architecture, and the practical pitfalls I encountered when implementing it.

Background: Why a Meta-MCP?

The design is inspired by Anthropic's engineering post:

🔗 Code execution with MCP
https://www.anthropic.com/engineering/code-execution-with-mcp

Instead of giving the LLM a long list of explicit tool definitions,
you give it just enough machinery to:

1. look up available API bindings, and
2. execute code that uses them.

For this experiment, I connected three child MCP servers:

• Notion MCP
• Playwright MCP
• Chrome DevTools MCP

Playwright and Chrome DevTools overlap, but I wanted to compare their behavior.
(Yes, this inflates the original token count — but the reduction effect remains the same.)

The MCP Context Problem

Here’s what Claude Code loads when these MCP servers are enabled:

MCP tools: 36.6k tokens (18.3%)
└ chrome-devtools (26 tools)
└ playwright (22 tools)
└ notion (15 tools)

More than 60 tools are injected into the conversation context every time.

On a 200k context window, 18% was being consumed by tool definitions alone,
leaving less room for code, logs, or iterative reasoning.

The Code Mode Approach

Code Mode exposes only two tools:

Code Mode MCP
├─ search_docs: query API schemas of child MCP servers
└─ execute_code: run TypeScript that calls MCP bindings

The LLM workflow becomes:

1. search_docs → find the API
2. execute_code → perform the operation

search_docs

// List all bindings
await search_docs({})
// => notion, playwright, chrome, ...

// Search by keyword
await search_docs({ query: "navigate" })
// => returns schema for playwright.browser_navigate

execute_code

The core of Code Mode.

await execute_code({
  code: `
    await playwright.browser_navigate({ url: "https://example.com" });
    const snapshot = await playwright.browser_snapshot({});
    console.log(snapshot);
  `,
})

All available bindings (playwright, notion, chrome, etc.)
are injected into the execution environment automatically.

Implementation Notes

Choosing Deno for the Execution Environment

execute_code needs to run arbitrary TypeScript generated by the LLM,
but inside a sandbox.

Deno was the best fit because:

1. TypeScript runs without transpilation
2. Worker API is built-in and behaves like browser Web Workers
3. Permission model is strong and easy to restrict
4. The MCP TypeScript SDK works in Deno

Here’s how the sandbox worker is created:

const worker = new Worker(workerUrl, {
  type: "module",
  deno: {
    permissions: {
      net: false,
      read: false,
      write: false,
      env: false,
      run: false,
      ffi: false,
    },
  },
})

Execution Constraints

Everything must go through MCP tool calls, which are relayed to the parent process.

Connecting Child MCP Servers

Architecture:

Claude Code
↓ stdio
Code Mode (search_docs / execute_code)
├─ Notion MCP (SSE via mcp-remote)
├─ Chrome DevTools MCP (stdio)
└─ Playwright MCP (stdio)

If a child server fails to connect:

• It is omitted from search_docs
• Any attempt to call its bindings results in Unknown tool

Currently, reconnection is manual (/mcp restart).

Pitfall: “os error 35” When Nesting MCP Servers

When Code Mode launched another MCP server via StdioClientTransport,
I repeatedly hit:

Resource temporarily unavailable (os error 35)

Root Cause

StdioClientTransport defaults to:

stderr: "inherit"

Since the meta server itself communicates with Claude Code via stdio,
stderr inheritance causes I/O interference.

Fix

Always use:

const transport = new StdioClientTransport({
  command: "npx",
  args: ["-y", "@playwright/mcp@latest"],
  stderr: "pipe",  // REQUIRED for nested MCP
})

Do this for all child MCP servers.

Reducing the Tool Definition Size

Originally, the execute_code tool description included:

• all available bindings
• code examples
• server lists

It reached 1.3k tokens by itself.

After simplification:

description: "Execute TypeScript code that uses child MCP servers. Use search_docs to inspect available bindings."

→ 687 tokens.

Tool definitions now scale linearly regardless of how many child MCP servers exist.

Results

The difference in conversational “breathing room” is substantial.

Limitations

1. Less intuitive for an LLM

Normal MCP tools are self-descriptive.
Code Mode requires:

1. searching docs
2. writing code

LLMs need a short introduction before they can use it effectively.

2. Hardcoded configuration

Code Mode is not a plug-and-play npm package.

• Child server paths are hardcoded
• Users must adjust the code to their environment

This is an approach, not a product.

3. Weak reconnection handling

Once a child MCP disconnects (OAuth expiry, browser closure, etc.):

• There is no auto-retry
• Manual /mcp restart is required

This can be improved.

Conclusion

• MCP tool definitions consume significant context
• A meta MCP server can compress dozens of tools into two
• Deno provides a robust sandbox for executing TypeScript safely
• stderr: "pipe" is essential to avoid I/O conflicts in nested MCP setups
• The approach works well but isn’t universal or beginner-friendly

The full implementation (Deno + MCP SDK) is available here:

👉 https://gist.github.com/tgfjt/a3716f7b1651d7fd7df2d769efdf644e

Hope this helps anyone experimenting with multi-MCP setups or context-efficient tooling!

References

• Code Execution with MCP — Anthropic https://www.anthropic.com/engineering/code-execution-with-mcp
• modelcontextprotocol/typescript-sdk https://github.com/modelcontextprotocol/typescript-sdk