Thread

1. simonw · 1789935881 · 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. rsolva · 1789936220 · focus · HN ↗

      Exactly, in our company, we have built MCPs that simplifies interactions with internal tools we use a lot, which saves time and tokens. Sure, we could let the agent poke and fumble around with a not-so-ideal API too, but it makes sense to formalize it and give the agents quick access to what we want it to fetch 99% of the time.

      1. 0x445442 · 1789936867 · focus · HN ↗

         What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.

         1. piva00 · 1789937850 · focus · HN ↗

            I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed.

            Best of both worlds in my view.

         2. 0x696C6961 · 1789952192 · focus · HN ↗

            Yeah that's a good idea. Then we should standardize these tools and find an easy way for agents to discover and use them. ... Oh wait

            1. mjmas · 1789956766 · focus · HN ↗

               And call it not-closed API or something like that.
            2. 0x445442 · 1789997118 · focus · HN ↗

               Just tell the clanker to read the api documentation that should already exist. You dont need an MCP server for that.
            3. jimbokun · 1790001805 · focus · HN ↗

               Congrats you just invented the Unix shell!

               1. wezabis · 1790115032 · focus · HN ↗

                  [dead]

         3. locknitpicker · 1789968001 · focus · HN ↗

            > If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.

            The MCP is the deterministic program.

            You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.

            It's the interface for your deterministic program. That's it.

            1. 8note · 1789969572 · focus · HN ↗

               they were suggesting that you take the agent out of the run time tool usage

               1. locknitpicker · 1789976611 · focus · HN ↗

                  > they were suggesting that you take the agent out of the run time tool usage

                  That only applies if you are talking about a well established recurrent workflow. That's not how MCPs are used to begin with.

               2. themgt · 1789990831 · focus · HN ↗

                  It's easier if you started a while back shunning all human labor (including your own) in favor of fully deterministic systems. Reality is deterministic so your company or project logically can be run off a single compiled binary with formal verification of correctness for every possible scenario.

                  1. jimbokun · 1790001976 · focus · HN ↗

                     Heisenberg begs to differ with your view of reality.

                     1. shwaj · 1790019215 · focus · HN ↗

                        So does Gödel. Maybe it was a joke? Unclear.
            2. jimbokun · 1790001866 · focus · HN ↗

               A protocol is not a program.
         4. Sayrus · 1789987437 · focus · HN ↗

            Retrieving messages from Slack over MCP allows a shared read-only bot account accessible from the web browser and CLI. Setup is automated so users can just ask Claude to read them and do something.

            Sharing Slack with Claude:

            - Using the "normal" way, it shares too much, including privates messages.

            - Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more.

            - Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.

         5. lanstin · 1789998129 · focus · HN ↗

            Yeah. Like I had Claude code write an upload Slab script, and a few linear integration scripts, now it just runs these to interact with those systems. I had it write a redshift proxy that doesn’t take login creds and is just a logging read only account but it can just write sql to research to its hearts content (some columns hashed on replies) and I don’t need much trust but I get a lot of good analysis and verification done.
         6. jimbokun · 1790001717 · focus · HN ↗

            Yes, having LLMs write deterministic programs is still an under used solution.

            Less token spend, lower latency, more predictable results compared to having the LLM perform the task directly every time.

      2. deadbabe · 1789985088 · focus · HN ↗

         The simplified interactions are how it should have been designed in the first place.

         1. yorwba · 1789990801 · focus · HN ↗

            It's difficult to come up with the optimal workflow on the first try. So an API should typically start out flexible even at the expense of complexity, in order to enable experimentation, and then you can optimize to make the common case simple, once you know what the common case is.

            1. jimbokun · 1790001578 · focus · HN ↗

               Sure but that common case should go into the core APIs, not an MCP.

               1. dominotw · 1790001802 · focus · HN ↗

                  agreed lots of ppl writing mcp as a lipstick on the pig.

                  1. lazyasciiart · 1790006423 · focus · HN ↗

                     Yea my company is willing to pour money into an MCP but has concretely resisted attempts to improve or care about the API for years.
                  2. rsolva · 1790011751 · focus · HN ↗

                     MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.

                     1. cindyllm · 1790019194 · focus · HN ↗

                        [dead]

Unofficial Hacker News client; not affiliated with Y Combinator.