‹ BackHN Continuity

Thread

MCP was always a bad idea?

335 points · 331 comments · maharshi365

  1. simonw · · focus · HN ↗
    This article entirely misses the value that MCP brings today.

    Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.

    If you want to operate something that's less YOLO than that, you'll find yourself wanting:

    1. Control over exactly which external services it can access

    2. A way to handle authentication that doesn't allow the agent to directly access API keys

    3. A sensible UI to allow users to connect and authenticate further services

    4. Strong audit logging for what's going on

    MCP makes all of that so much easier to provide.

    Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.

    1. 0x696C6961 · · focus · HN ↗
      Even if your agent has internet access, why waste tokens having it re-discover and re-implement its own API client each time? It doesn't make any sense.
      1. hypercube33 · · focus · HN ↗
        For me, I have a service that has multiple vectors of what would be called an API - PowerShell Modules, WMI, RESTFUL Web Services, some are available, some can do some things, some are more direct, some are not allowed with enterprise security etc.

        Either way, I don't do what you suggest. I have self-learning rules and have the models build a well-rounded API engine once, then re-use it with query scripts through skills. Its portable and flexible in many environments.

        1. 0x696C6961 · · focus · HN ↗
          No one is saying to wrap your local power shell modules in an MCP. That would be pointless and stupid.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.