agents / mcp / cli

Quandri Engineering tested Model Context Protocol (MCP) on a real stack and finds it costly: MCP tool schemas consume substantial LLM context windows (e.g., 77 tools ≈ 21k tokens, using 10.5% of a 200k-token Claude window and 16.5% of GPT-4o’s 128k), reducing space for actual prompts. They measured large per-tool sizes (Linear definitions alone ~12.8k tokens) and report reliability and performance problems—init failures, crashes, slower responses due to extra process round-trips, and opaque permissions. MCP also duplicates functionality available via CLIs/APIs, losing composability, debuggability, and human parity. An update notes Claude Code’s Deferred Loading mitigates context bloat, but Quandri argues performance, debugging, and architectural drawbacks remain relevant.

Quandri Engineering analyzed the Model Context Protocol (MCP) and found it impractical for production use: MCP consumes substantial LLM context, introduces reliability and latency problems, and duplicates existing CLI/API capabilities. Measurements on a Quandri stack show 77 tools from four MCP servers consuming ~21k tokens (10.5% of a 200k-token Claude window, 16.5% of a 128k GPT-4o window), with individual tool schemas like linear/save_issue using ~619 tokens. Operational issues include init failures, process maintenance, slower round-trips (benchmarks show multix slower than direct REST), mid-session crashes, and opaque permissions. Quandri argues CLI/API paths remain more composable, debuggable, and efficient; note: Claude Code’s deferred loading later reduces context bloat but other concerns persist.