No, it's not fair at all. You can't add security afterwards like spreading icing on baked cake. If you forgot to add sugar to the cake batter, there's not enough buttercream in the world to fix it.
There is no need to implement a new form of authentication that's specific to the protocol because you already have a myriad of options available with HTTP.
Any form of auth used to secure a web service can be used with MCP. It's no different than adding authN to a REST API.
Please just read the spec. It just builds on top of JSON-RPC, there's nothing special or inherently new about this protocol.
https://modelcontextprotocol.io/specification/2025-03-26
There are way too many commentators like yourself that have no idea what they are talking about because they couldn't be bothered to RTFM.
It's not no security vs security but not standardized vs standardized.
Agree though that's it's not ideal and there will definitely be non zero harm from that decision.
I would think authZ is the trickier unhandled part of MCP as I don’t remember any primitives for authorization denial or granularity, but, again, HTTP provides a coarse authZ exchange protocol.
You can use whatever authN/authZ you want for the HTTP transport. It's entirely up to the client and server implementers.
But when you are running things in any kind of multi-user/multi-tenant scenario, this is much harder and the protocol doesn't really address this (though also doesn't prevent us from layering something on top). As a dumb (but real) example, I don't want a web-enabled version of of an MCP plugin to have access to my company's google drive and expose that to all our chat users. That would bypass the RBAC we have. Also I don't want to bake that in at the level of the tool calls, as that can be injected. I need some side channel information on the session to have the client and server to manage that.