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.
