The auth story for MCPs is a complete mess right now, though, which is why people make ones to run locally.

That's ironic. I think local MCPs are an auth nightmare.

Just think of all those plaintext auth tokens sitting in well-known locations on your machine.

It's a black hat dream.

We'll see, but I think commercial use of local MCPs is going to be constrained to use cases that only make sense if the MCP is local (e.g. it requires local file access).

For everything else, the only commercially reasonable way to use them is going to be remote streamable HTTP MCPs running in isolated containers

And even then, you need some management and identity plane. So they're going to likely be accessed via an enterprise gateway/proxy to handle things like: - composition -- bundling multiple MCPs into one for easier connection - identities per-user / per-agent - generation of rotatable tokens for headless agents - filtering what features (tools, prompts, resources) flow through into LLM context - basic security features, like tool description whitelisting to prevent rug pulls

MCP is only a protocol, after all. It's not meant to be a batteries-included product.

This is why I think we should just be packaging tools into apps though.

Let ChatGPT/Claude/Cursor manage my Oauth tokens, and then just bring tools into those platforms without a whole MCP server in the middle.

...no, MCP was always designed to be run locally, the auth mess was the result of people trying to sidestep that design intent and getting grumpy that it didn't work well (surprise, of course not)