4 ms·

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

by dend 2mo ago

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!

checker 2mo ago
Thank you for your work! I was looking forward to the stateless update.
Oras 2mo ago
Thank you! 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?
- dan-kwiat 2mo ago
  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.
- Sattyamjjain 2mo ago
  [flagged]
cidd 2mo ago
When will java sdk come out with latest changes from spec?
- somnium_sn 2mo ago
  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 ! [1] https://modelcontextprotocol.io/community/communication https://modelcontextprotocol.io/community/communication
dan-kwiat 2mo ago
Great work! Any word on when to expect support across claude clients?
- dend 2mo ago
  We are actively working on this - the support is rolling out across the ecosystem: https://claude.com/blog/bringing-mcp-2026-07-28-to-claude https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
ihsw 2mo ago
[dead]
jakobgm 2mo ago
Congrats at shipping the new specification! 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!
- colinator 2mo ago
  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.
- somnium_sn 2mo ago
  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.
flashgordon 2mo ago
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!
whitew1994 2mo ago
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.

by dend 2mo ago

checker 2mo ago

Thank you for your work! I was looking forward to the stateless update.

Oras 2mo ago

Thank you! 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?

dan-kwiat 2mo ago
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.
Sattyamjjain 2mo ago
[flagged]

cidd 2mo ago

When will java sdk come out with latest changes from spec?

somnium_sn 2mo ago
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 ! [1] https://modelcontextprotocol.io/community/communication https://modelcontextprotocol.io/community/communication

dan-kwiat 2mo ago

Great work! Any word on when to expect support across claude clients?

dend 2mo ago
We are actively working on this - the support is rolling out across the ecosystem: https://claude.com/blog/bringing-mcp-2026-07-28-to-claude https://claude.com/blog/bringing-mcp-2026-07-28-to-claude

ihsw 2mo ago

[dead]

jakobgm 2mo ago

Congrats at shipping the new specification! 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!

colinator 2mo ago
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.
somnium_sn 2mo ago
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.

flashgordon 2mo ago

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!

whitew1994 2mo ago

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.