Hey folks - one of the Lead Maintainers for MCP. Happy that we got this release out the door today, this is an exciting change for those that wanted to roll out remove MCP servers into serverless hosts. There is, of course, more good stuff packed, so if you have questions or feedback - our team is here to help!
I can see the engineering benefits of removing the ID field (simplier engineering, easier to build with). However, this is a regression for stateful tool calling.
The workaround proposed is to have the model pass in an ID which is a waste of tokens if this could have been injected by the client.
Stateful tools make sense for long running conversations, where knowledge of previous tool results can improve the result OR where you want to use ephemeral conversation scoped IDs for entities referred to in the chat (for instance referring to search results as r1/r2/r3 rather than a UUID. Or for chaining together tool calls so that the results of a 'search' tool can be passed into a batch edit tool without the need to pass in a 100 strong list of UUIDs or have unneccesary duplicated arguments.
Will there be optional support for stateful tool calling? As with it removed it has made engineering easier, but performance and flexibility lower.
In the situation where we use MCP we already have a stateful AI assistant, and with this change we will have to support a seperate server just for MCP (rather than one that is the same as our AI assistant tools) that will never have performance parity with the assistant on our platform where we can guarentee state is maintained.
I would say that most people at the moment are still building simpler stateless MCP servers and AI assistants. As we as a field get better at doing this, stateful will become the standard as it is a superset of stateless and more performant.
Any new to share on file upload support? We have shipped a MCP server and it has been really frustrating to observe MCP clients fumbling around with base64-encodings, polluting their context window with binary data. SEP-1306 (Binary Mode Elicitation) was superseded by SEP-2356 (File input support for tools and elicitation), and that was in turn superseded by SEP-2631 (File Objects and Transfer) which is currently left in a draft state with little activity.
Allowing LLM-based agents to shuffle binary data around efficiently and reliably seems like a pretty big gap in the current specification, if you ask me!
I concur. Most of my MCP pain is dealing with client's differing ability to handle images. Some clients (old codex) would even truncate the base64 data regardless of how it was json-wrapped. And sometimes they just ingest the base64 date directly into their context window. Not sure if this is an MCP thing or a clients-poorly-implementing-MCP thing.
Hey I am the one Lead maintainer of the MCP protocol.
I agree and hear you that file uploads are a pain. As the core maintainer group we have deferred the work on this for this release and hope to pick it up soon.
Now is the moment to engage with the respective working group to make your case heard so we can ensure it’s on the roadmap.
Congrats mate - Great to see this and loved working with you all on a very very very tiny part of this! Looking forward to a lot more awesome releases and features!
The Java SDK is currently a Tier 2 SDK.. As a Tier 2 SDK they have up to 6 months to implement it. I know they are actively working towards support for the specification.
Best to join our community discord [1] and ask the maintainers !
What’s the best practice for tools where the upstream API only supports basic auth (username/password) and there’s no OBO option? In my case the login returns a token that’s only valid for an hour, so the user has to re-auth after that. Do you stash the credentials on the MCP server and silently refresh, or is there a nicer pattern people are using?
URL Elicitation works well if a human is driving the client. Unfortunately MCP client support is patchy but I expect that will change now the protocol is stateless.
There's theoretically nothing really stopping this integration from working in the consumer space - you just need to establish a trust relationship (e.g., if I am logged in with GitHub, also log me in to Sentry automatically). There is more work ahead here, but as you said - the most obvious _current_ use-case is enterprises, where admins do not want individual employees clicking around picking random credentials they have.
At the end of the day its wiring the flows to serve a purpose and can be wired in multiple ways. Some combination of client, IDP and resource server can come together to form a band and may provide this for consumer identity.
Reasons why this is a bad idea for consumer identity -
1. In Enterprise, the IDP is the single owner for the identity, so it essentially can do represent the user uniquely and sort of pretty much do anything it wishes for (includes deleting the identity)
2. In enterprise the IDP is the single authentication factor used by the downstream resource server (application), in other words the application just trusts the assertion
3. For consumer identity, the resource server owns the identity/user explicitly. Github may be one of the authentication factors that the user can use, but it may not be the only one.
4. For consumer identity, Github cannot delete the user account in downstream application.
Regardless, this protocol is going to create friction in adoption of new AI agents and MCP servers, to sell to enterprise they have to implement this and integrate with existing IDP's and resource servers. Using any new MCP server would require full evaluation lifecycle from security perspective. Its a good thing but its going to hurt the new players pretty bad in terms of adoption and discovery.
Hey - one of the lead maintainers of the MCP project here. There are a lot of scenarios where this simply won't scale (both from a usability and security standpoint). Cookies were made for the browser. MCP servers and clients often operate in environments where that is not a guarantee.
I've been working on an MCP for creating semi-deterministic flows in Claude code (essentially skills, but broken down into pieces). In order to track execution and state, I have the LLM pass the MCP a unique "execution id" with every call. This lets me programmatically step it through skills and know exactly where execution progress is.
I've been considering a similar approach for the web. Essentially, do a short-lived, one-time use token exchange for every single call back and forth.
* LLM: "I'd like to interact with your site"
* Site: "Great, here's first token. I will exchange it for a new one on the next call. Do not share with with another site. You can authenticate in your browser with this link: [example.com]"
* Then you can go back and forth.
It'd be rather annoying to auth in the browser every time, but it would enable a low-touch flow.
Long term, it'd be ideal to have some sort of out-of-band credential store/tool available, but this would start proving the concept out. Don't use it for highly sensitive stuff, but it would enable a lot of agentic flows that are currently blocked by high-lift MCP setup.
Many times what the server returns is dictated by what kind of client software a user is using. Cookies are obviously used by browser based clients, with full browser capabilities. MCP doesn't have those capabilities. How will the server know what to return?
I have separated handling for token based calls vs cookie based in my non-mcp projects.. because it suffers from the same issue.
Most of the endpoints, assuming the client talks to server using api's, work fine with cookies, some, do not.
FWIW, we never vibe-coded the spec to begin with, but yes - auth is a continuous learning process, and we're lucky to collaborate with some really talented folks both inside and outside the company (e.g., this launch we worked closely with Okta to see how we can best wire things up) to make this a smoother experience. Keep the feedback coming!
We're always looking at making it a smoother experience - it's a top pain point for developers and IT admins alike. If you have feedback - feel free to send it my way!
