Doing a workshop this week on MCP for an enterprise client and explaining the 406 returned by GET against /mcp w/o text/event-stream is exactly one of the things that I have to bring up when I do these.
The specification still leaves a lot to be desired, especially as it relates to auth. There are lots of bad ways to do auth with MCP and only a couple of good ways. It also puts a lot of pressure on the various IdP vendors and relies on lesser used areas of OAuth 2.0/2.1 (like DCR, token exchange, etc.). It started out in a place where the assumption was you were running an MCP Server on a laptop or you were a SaaS provider serving lots of individual users -- somehow DCR in the initial spec iteration seemed like a good idea (spoiler: it wasn't) and fortunately, the latest revision has somewhat addressed that. XAA/ID-JAG & CIMD should continue to round-out some client management and auth solutions for the enterprise.
Gateways are another area that needs to be addressed in the spec. There isn't a formal definition of one in the spec, and yet, there are lots of "gateways" out there. What a gateway is and what it should do is an open question and it means different things to different people depending on who you ask. For example, who does token exchange: the MCP server or the MCP gateway? Both are valid answers right now depending on the implementation or your opinion of which is best.
More spec iterations should be coming this year. I'm still pretty optimistic about MCP as a whole, as it remains a good way to standardize tool calls across agents and some of the other entities that it provides like resources and prompts are genuinely useful to add more determinism to an agent. Interceptors and skills will be good, too.
If you're interested in helping to evolve the spec further, the MCP Contributors Discord is active. There are lots of IGs/WGs that solicit feedback and you can participate in meetings with your feedback.
We build a gateway (MintMCP) and I’d love to connect and exchange notes.
We’re excited about XAA, it will simplify many flows
Hey thanks for the note about the discord!
I have also been finding the MCP auth story to be really lacking was excited to see OAuth 2 support until I tried to get it to work at work and realized our idp implementation didn't support 2.1, and went into the spec and started wondering if anyone had a good experience yet. Luckily most of our environment can settle on a OAuth token env var standard until that's all in order.
A lot of how well it works or won't work depends on your clients, as not all clients have support for things like RFC 9728 (Protected Resource Metadata). Assuming your client has good support for most of the OAuth 2.0 standards that MCP uses (you don't need DCR as you can statically register clients, assuming that is viable for your environment), then it is possible now with most IDPs to get an OAuth 2.0 auth code flow working just fine. You would then do a token exchange to the upstream to ensure to get the appropriate new audience and rescope/downscope as necessary. Gateways can also help here a lot as instead of baking in all of the auth concerns into your MCP Servers and upstreams, you delegate that to the MCP Gateway. Again, gateway here means different things to different vendors, but Kong, for example, has the ability to act as an MCP proxy (gateway), expose tools based on consumer role or group, apply OAuth 2.0 to it and do an upstream token exchange, while also acting as a regular API gateway that can protect an endpoint with OAuth 2.0/OIDC.
[dead]