undefined | Better HN

0 pointsbravura1mo ago0 comments

The last time I looked at MCPs closely, they appeared to pollute context and just hang there consuming context constantly. Whereas a self-documenting API or CLI tool enabled progressive discovery.

Has this changed?

My uncharitable interpretation is that MCP servers are NJ design for agents, and high quality APIs and CLIs are MIT design.

0 comments

anon70001mo ago

There has been some improvement in that area.

But at the end of the day, MCP is about making it easy/standard to pull in context from different sources. For example, to get logs from a CI run for my PR, or to look at jira tickets, or to interact with GitHub. Sure, a very simple API baked into the model’s existing context is even better (Claude will just use the GH CLI for lots of stuff, no MCP there.)

MCP is literally just a way for end users to be able to quickly plug in to those ecosystems. Like, yeah, I could make some extra documentation about how to use my CI provider’s API, put an access token somewhere the agent can use… or I could just add the remote MCP and the agent has what it needs to figure out what the API looks like.

It also lets the provider (say, Jira) get some control over how models access your service instead of writing whatever API requests they feel like.

Like, MCP is really not that crazy. It’s just a somewhat standard way to make plugins for getting extra context. Sure, agents are good at writing with API requests, but they’re not so good at knowing why, when, or what to use.

People get worked up over the word “protocol” like it has to mean some kind of super advanced and clever transport-layer technology, but I digress :p

bravuraOP1mo ago

You're making the convenience argument, but I'm making the architecture argument. They're not the same thing.

You say "a very simple API baked into the model's existing context is even better". So we agree? MCP's design actively discourages that better path.

"Agents are good at writing API requests, but not so good at knowing why, when, or what to use". This is exactly what progressive discovery solves. A good CLI has --help. A good API has introspection. MCP's answer is "dump all the tool schemas into context and let the model figure it out," which is O(N) context cost at all times vs O(1) until you actually need something.

"It's just a standard way to make plugins" The plugin pattern of "here are 47 tool descriptions, good luck" is exactly the worse-is-better tradeoff I'm describing. Easy to wire up, expensive at runtime, and it gets worse as you add more servers.

The NJ/MIT analogy isn't about complexity, it's about where the design effort goes. MCP puts the effort into easy integration. A well-designed API puts the effort into efficient discovery. One scales, the other doesn't.

j / k navigate · click thread line to collapse