Why MCP Was Always a Bad Idea
-
Premise and Context:
- Critiques the Model Context Protocol (MCP)—introduced by Anthropic to standardize how LLMs connect with external tools, APIs, and data sources.
- Argues that MCP is largely unnecessary, overhyped, and an awkward abstraction layer compared to simpler, direct integration patterns.
-
Core Arguments against MCP:
- Redundancy with Existing Tooling: Full-fledged modern coding/terminal agents (e.g., Claude Code, Codex) already possess general tools like Bash, curl, and file access; forcing interactions through MCP adds an extra layer of indirection.
- Context and Token Inefficiency: Schema definitions, capabilities, and tool descriptions in MCP must often be loaded into the context window, causing prompt bloat and unnecessary token consumption.
- Operational Overhead: Running, maintaining, and configuring dedicated MCP servers across environments introduces architecture complexity and another point of failure.
- Security and Isolation Concerns: Exposing broad tool capabilities over MCP creates risks around unintended ambient execution, prompt injection, and inadequate permission granularity compared to dedicated sandboxes.
- Superior Alternatives: The author favors lighter, more deterministic paradigms—such as pairing terminal agents directly with CLI tools, well-documented REST/GraphQL APIs, or lightweight execution scripts.
Hacker News Discussion
-
Defending MCP for Security and Governance (Simon Willison & others):
- Commenters argue that giving an agent unrestricted shell/curl access ("YOLO mode") is unacceptable in security-sensitive or production environments.
- MCP provides essential boundaries: fine-grained control over external service access, authentication management without exposing raw API keys/secrets to the LLM, and structured audit logs.
-
Standardization and SaaS Ecosystem Benefits:
- Centralized MCP servers (e.g.,
mcp.linear.app) offer zero-friction discovery and updates across multiple clients without having to install and maintain local CLIs. - Standardizing interfaces prevents service providers from needing to support ad-hoc, disparate agent conventions.
- Centralized MCP servers (e.g.,
-
Context Bloat vs. In-Context Efficiency:
- Some users report severe token bloat with poorly optimized MCP servers compared to targeted CLI commands or custom markdown instructions (e.g.,
SKILL.md). - Conversely, others note that well-architected MCPs return clean, structured JSON, saving tokens and parsing overhead compared to messy CLI standard output.
- Some users report severe token bloat with poorly optimized MCP servers compared to targeted CLI commands or custom markdown instructions (e.g.,
-
Abstraction Layer vs. "Lipstick on a Pig":
- Critics on HN argue that companies often build MCP servers to mask legacy, poorly designed APIs instead of fixing the root interfaces.
- Proponents point out that wrapping legacy or internal systems (such as Windows COM interfaces or legacy internal databases) in an MCP server is precisely where the protocol excels, turning awkward systems into cleanly consumable agent tools.
-
Emergence of Deterministic Code Generation:
- Multiple participants suggest using agents to write deterministic helper scripts for repetitive tasks rather than relying on dynamic runtime tool interpretation through MCP servers every time.
