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

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.

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

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

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.

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.

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.

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.

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

And call it not-closed API or something like that.

Congrats you just invented the Unix shell!

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.

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.

> 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.

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

> 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.

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.

Heisenberg begs to differ with your view of reality.

So does Gödel. Maybe it was a joke? Unclear.

A protocol is not a program.

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.