At Snyk, we've been working on this for a while. Here's our flagship open source project consolidating a lot of the MCP risk factors we've discovered over the last year or so into actionable info: https://github.com/invariantlabs-ai/mcp-scan
The MCP landscape is a huge frothing septic tank. Go on, try to create a simple MCP server that is protected by a password and connect it to ChatGPT or Claude. Or even the one that uses your local SSO system for authentication.
I tried and failed after about 3 days of dealing with AI-slop-generated nonsense that has _never_ been worked. The MCP spec was created probably by brainless AI agents, so it defines two authentication methods: no authentication whatsoever, and OAuth that requires bleeding-edge features (dynamic client registration) not implemented by Google or Microsoft.
The easiest way for that right now is to ask users to download a random NodeJS package that runs locally on their machines with minimal confinement.
Had an almost identical experience. Even if you don’t need anything with auth, no one has yet made an mcp that wasn’t ultimately worse or the same as a cli but with a lot more song and dance. Security is also a bit of a joke when half the time it’s installing docker and phoning home. I wanted to like mcp and vend out remote mcp but this spec is not ready.
My understanding is that it can upgrade to an SSE connection so a persistent stream. Also for interprocess communication you usually prefer a persistent connection. All that to reduce communication overheads. The rationale also is that an AI agent may trigger more fine-grained calls than a normal program or a UI, as it needs to collect information to observe the situation and decide next move (lot more get requests than usual for instance).
Using SSE was far too inconvenient in theory despite that being how nearly all of the MCP that gained traction was working, so instead the spec was switched to being better in theory but very inconvenient in practice:
There are a million "why don't you _just_ X?" hypothetical responses to all the real issues people have with streamable http as implemented in the spec, but you can't argue your way into a level of ecosystem support that doesn't exist. The exact same screwup with oAuth too, so we can see who is running the show and how they think.
It's hard to tell if there is some material business plan Anthropic has with these changes or if the people in charge of defining the spec are just kind of out of touch, have non-technical bosses, and have managed to politically disincentivize other engineers from pointing out basic realities.
“Ok, how do we do customer auth” has become my go-to question to kill MCP projects. There is no working solution which makes any kind of enterprise exploration into the space pointless.
The initial remote MCP specification was pretty painful, but the June spec and the upcoming November spec are much more workable - MCP auth is (mostly) just OAuth now. MCP Clients are OAuth clients and can be granted access tokens and managed just like any other 3rd party app integration.
I'd love to hear more about the specific issues you're running into with the new version of the spec. (disclaimer - I work at an auth company! email in bio if you wanna chat)
Serious question, as I’m starting to go through this process myself -
Is it possible for the customer to provide their own bearer tokens (generated however) that the LLM can pass along to the MCP server? This was the closest to a workable security I’ve looked at. I don’t know if that is all that well supported by Chat GUI/web clients (user supplied tokens), but should be possible when calling an LLM through an API style call, right (if you add additional pass thru headers)?
The LLM doesn't intervene much actually, it just tells what tool to call. It's your MCP implementation that does the heavy lifting. So yeah you can always shove a key somewhere in your app context and pass it to the tool call. But I think the point of other comments is that the MCP protocol is kinda clueless about how to standardize that within the protocol itself.
I think an important thing to note is the MCP client is a distinct thing from the ‘LLM’ architecturally, though many LLM providers also have MCP client implementations (via their chat ui or desktop / cli implementations).
In general, I’d say it’s not a good idea to pass bearer tokens to the LLM provider and keep that to the MCP client. But your client has to be interoperable with the MCP server at the auth level, which is flakey at the moment across the ecosystem of generic MCP clients and servers as noted.
You've obviously got some substantive points to make here, which is great, but indignant putdown rhetoric has a destructive effect on the threads. If you could just make your substantive points thoughtfully, we'd appreciate it.
MCP works best for tool calling that doesn't require auth (so tools that are trusted on your own machine). The whole pitch that you should be using it for business facing tools and things that require auth is a terrible idea.
Even if you're doing local only - MCP tools can mostly be covered by simply asking Claude Code (or whatever) to use the bash equivalent.
> MCP works best for tool calling that doesn't require auth (so tools that are trusted on your own machine).
In other words, downloading random crap that runs unconfined and requires a shitty app like Claude Desktop.
BTW, Claude Desktop is ALSO an example of AI slop. It barely works, constantly just closing chats, taking 10 seconds to switch between conversations, etc.
In my case, I wanted to connect our CRM with ChatGPT and ask it to organize our customer notes. And also make this available as a service to users, so they won't have to be AI experts with subscriptions to Claude.
At Snyk, we've been working on this for a while. Here's our flagship open source project consolidating a lot of the MCP risk factors we've discovered over the last year or so into actionable info: https://github.com/invariantlabs-ai/mcp-scan
The MCP landscape is a huge frothing septic tank. Go on, try to create a simple MCP server that is protected by a password and connect it to ChatGPT or Claude. Or even the one that uses your local SSO system for authentication.
I tried and failed after about 3 days of dealing with AI-slop-generated nonsense that has _never_ been worked. The MCP spec was created probably by brainless AI agents, so it defines two authentication methods: no authentication whatsoever, and OAuth that requires bleeding-edge features (dynamic client registration) not implemented by Google or Microsoft.
The easiest way for that right now is to ask users to download a random NodeJS package that runs locally on their machines with minimal confinement.
Had an almost identical experience. Even if you don’t need anything with auth, no one has yet made an mcp that wasn’t ultimately worse or the same as a cli but with a lot more song and dance. Security is also a bit of a joke when half the time it’s installing docker and phoning home. I wanted to like mcp and vend out remote mcp but this spec is not ready.
I'm still confused as to how mcp is better that say a Fastapi endpoint and it's generated swagger docs?
In the cases I’ve tried building/integrating they are the same thing…
I think the only difference is the statefulness of the request. HTTP is stateless, but MCP has state? Is this right?
I haven’t seen many use cases for how to use the state effectively, but I thought that was the main difference over a plain REST API.
My understanding is that it can upgrade to an SSE connection so a persistent stream. Also for interprocess communication you usually prefer a persistent connection. All that to reduce communication overheads. The rationale also is that an AI agent may trigger more fine-grained calls than a normal program or a UI, as it needs to collect information to observe the situation and decide next move (lot more get requests than usual for instance).
Using SSE was far too inconvenient in theory despite that being how nearly all of the MCP that gained traction was working, so instead the spec was switched to being better in theory but very inconvenient in practice:
https://blog.fka.dev/blog/2025-06-06-why-mcp-deprecated-sse-...
There are a million "why don't you _just_ X?" hypothetical responses to all the real issues people have with streamable http as implemented in the spec, but you can't argue your way into a level of ecosystem support that doesn't exist. The exact same screwup with oAuth too, so we can see who is running the show and how they think.
It's hard to tell if there is some material business plan Anthropic has with these changes or if the people in charge of defining the spec are just kind of out of touch, have non-technical bosses, and have managed to politically disincentivize other engineers from pointing out basic realities.
I'm still laughing on how the error handling for tools is done, it's just a boolean field IsError.
https://modelcontextprotocol.io/specification/2025-06-18/ser...
“Ok, how do we do customer auth” has become my go-to question to kill MCP projects. There is no working solution which makes any kind of enterprise exploration into the space pointless.
The initial remote MCP specification was pretty painful, but the June spec and the upcoming November spec are much more workable - MCP auth is (mostly) just OAuth now. MCP Clients are OAuth clients and can be granted access tokens and managed just like any other 3rd party app integration.
I'd love to hear more about the specific issues you're running into with the new version of the spec. (disclaimer - I work at an auth company! email in bio if you wanna chat)
Serious question, as I’m starting to go through this process myself -
Is it possible for the customer to provide their own bearer tokens (generated however) that the LLM can pass along to the MCP server? This was the closest to a workable security I’ve looked at. I don’t know if that is all that well supported by Chat GUI/web clients (user supplied tokens), but should be possible when calling an LLM through an API style call, right (if you add additional pass thru headers)?
The LLM doesn't intervene much actually, it just tells what tool to call. It's your MCP implementation that does the heavy lifting. So yeah you can always shove a key somewhere in your app context and pass it to the tool call. But I think the point of other comments is that the MCP protocol is kinda clueless about how to standardize that within the protocol itself.
I think an important thing to note is the MCP client is a distinct thing from the ‘LLM’ architecturally, though many LLM providers also have MCP client implementations (via their chat ui or desktop / cli implementations).
In general, I’d say it’s not a good idea to pass bearer tokens to the LLM provider and keep that to the MCP client. But your client has to be interoperable with the MCP server at the auth level, which is flakey at the moment across the ecosystem of generic MCP clients and servers as noted.
Lol yeah, lots going on that will hopefully make it better though.
https://github.com/modelcontextprotocol/modelcontextprotocol... https://github.com/modelcontextprotocol/modelcontextprotocol... https://github.com/modelcontextprotocol/modelcontextprotocol... https://aaronparecki.com/2025/05/12/27/enterprise-ready-mcp https://github.com/modelcontextprotocol/modelcontextprotocol... https://www.okta.com/newsroom/press-releases/okta-introduces... https://github.com/modelcontextprotocol/ext-auth/blob/main/s... https://github.com/modelcontextprotocol/modelcontextprotocol... https://github.com/modelcontextprotocol/modelcontextprotocol... https://github.com/modelcontextprotocol/modelcontextprotocol...
[flagged]
Can you please stop posting unsubstantive/fulminatey comments? We've already asked you this multiple times:
https://news.ycombinator.com/item?id=45022004 (Aug 2025)
https://news.ycombinator.com/item?id=44396920 (June 2025)
https://news.ycombinator.com/item?id=43028401 (Feb 2025)
https://news.ycombinator.com/item?id=39337678 (Feb 2024)
You've obviously got some substantive points to make here, which is great, but indignant putdown rhetoric has a destructive effect on the threads. If you could just make your substantive points thoughtfully, we'd appreciate it.
https://news.ycombinator.com/newsguidelines.html
MCP works best for tool calling that doesn't require auth (so tools that are trusted on your own machine). The whole pitch that you should be using it for business facing tools and things that require auth is a terrible idea.
Even if you're doing local only - MCP tools can mostly be covered by simply asking Claude Code (or whatever) to use the bash equivalent.
> MCP works best for tool calling that doesn't require auth (so tools that are trusted on your own machine).
In other words, downloading random crap that runs unconfined and requires a shitty app like Claude Desktop.
BTW, Claude Desktop is ALSO an example of AI slop. It barely works, constantly just closing chats, taking 10 seconds to switch between conversations, etc.
In my case, I wanted to connect our CRM with ChatGPT and ask it to organize our customer notes. And also make this available as a service to users, so they won't have to be AI experts with subscriptions to Claude.