What if you don't need MCP at all?

Original Article ↗ Hacker News Discussion ↗

Engineers argue over whether Model Context Protocol (MCP) meaningfully improves how large language models use external tools, or just adds complexity, latency, and context bloat on top of capabilities models already have via standard APIs, code execution, and CLI tools. Critics say MCP is mostly hype and vendor lock-in, better replaced by good documentation, small composable scripts, and direct tool/function calling, while supporters counter that it standardizes tool discovery, encapsulates auth and capabilities, and makes third‑party integrations more plug‑and‑play—especially for non-technical users. Many conclude MCP is useful in narrow cases (remote SaaS services, managed agent platforms), but suboptimal for bespoke, tightly scoped engineering workflows.

What MCP Is and How Tool Calling Actually Works

  • Commenters clarify that MCP is a protocol and JSON-RPC–style wrapper for exposing tools to agents, not something “built into” models.
  • Major models already support function/tool calling; the client/agent enforces schemas and interprets “tool_use” vs “text” outputs, then invokes external functions.
  • MCP’s core value is described as a standard manifest + lifecycle so agents can auto-discover tools from arbitrary servers.

Arguments That You Don’t Need MCP

  • Many argue you can achieve the same by:
    • Publishing good API docs or OpenAPI/Swagger and feeding them as context.
    • Letting the model call existing REST/GraphQL/CLI tools via function calling.
    • Having the model write code that uses normal libraries/APIs, then executing that code.
  • For bespoke, constrained agents, MCP is said to add complexity, fragility, latency, and security risk without much benefit.
  • Critics call it “just context pollution” and “a thin JSON layer,” often overused in enterprise because of hype.

Perceived Benefits and Defenses of MCP

  • Proponents see MCP as:
    • A plugin/distribution standard for tools across agents (like “OpenAPI for LLMs”).
    • A way to encapsulate authentication/credentials and constrain capabilities, especially for non-technical users.
    • Helpful for remote SaaS integrations (GitHub, Figma, Sentry, etc.) where users “add an MCP” instead of wiring APIs/CLIs.
    • A driver of better, higher-level, task-focused APIs because vendors had to design LLM-friendly interfaces.

Technical Limitations and Context/Token Concerns

  • Multiple comments highlight:
    • Large tool catalogs and verbose schemas overloading context windows and harming reliability.
    • Intermediate tool results flowing through the model, wasting tokens and introducing error opportunities.
    • Difficulty composing tools across multiple MCP servers; subagents and “project-specific” MCPs partially mitigate this.
    • Weak story for observability, awkward HTTP/SSE transports, and security issues with stdio-based local tools.

Alternatives and Hybrids

  • Suggested alternatives include:
    • Claude Skills (essentially markdown prompts + tools with progressive reveal).
    • Simple bash/CLI tools with good --help text, described briefly in a project README/CLAUDE.md.
    • Exposing MCP tools as libraries inside code interpreters so models can compose them in code rather than via chained tool calls.
  • Several see MCP’s role shrinking to a thin, secure gateway layer, with real work done by code and CLIs.