Building Production MCP Servers: What the Spec Won’t Tell You

Author(s): Can Demir Originally published on Towards AI. The token bill, the tool-count cliff, and the “expected behavior” security handoff — three costs MCP delegates without naming them. Scroll through developer forums this month and you’ll see the same obituary in every thread: MCP is dead. Eric Holmes’ “MCP is dead, long live the CLI” hit the top of Hacker News. Pieter Levels called MCP “just as useless of an idea as LLMs.txt.” Thoughtworks put “naive API-to-MCP conversion” in the Hold ring of their Tech Radar. After the lead, the article argues that MCP isn’t really a protocol so much as a cost model disguised as JSON-RPC: each turn forces the model to pay a token “manifest tax” for every tool, large tool lists create a discontinuous “tool-count cliff” where tool selection collapses due to attention/selection saturation, and—per Ox Security—STDIO execution pushes sanitization risk to developers as an “expected behavior,” enabling command injection unless you sanitize before launch. It also highlights an operational failure mode (“stdout corruption”) where stray logs/prints break JSON-RPC framing. Finally, it lays out practical design guidance (limit tools, use progressive disclosure, sanitize at every layer you control, log to stderr only), when MCP is worth the overhead (multi-user/enterprise governance), and what remains uncertain (whether progressive disclosure becomes default, how Anthropic’s stance evolves, and whether model-tool selection cliffs are intrinsic or training artifacts). Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI