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 callin

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.