What if you don't need MCP at all?

Original Article ↗ Hacker News Discussion ↗

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.