# Stateful tools in the Model Context Protocol Canonical: https://warmtransfer.net/knowledge/mcp-stateful-tools Last verified: 2026-09-30 The Model Context Protocol defines guidance for designing stateful tools within its server features specification[^21]. WarmTransfer's reading of the sources is that statefulness in Model Context Protocol tools functions as a design convention carried in ordinary tool arguments and results rather than a protocol mechanism[^24]. ## How stateful tools work The Stateful Tools section of the Model Context Protocol declares itself non-normative guidance for tool design[^21]. Furthermore, this section contains no RFC 2119 keywords; MUST, SHOULD, MAY, REQUIRED, and SHALL each occur zero times within it[^18]. The protocol itself has no concept of a state handle[^19]. Instead, from the perspective of the wire, a handle is simply an ordinary string returned in a tool result and passed as an ordinary argument to subsequent tool calls[^19]. The specification reconciles stateful tools with the baseline rule that a tool set must not vary per connection: the invariance rule applies strictly to the tools list operation, whereas handles vary the arguments of the tool call itself[^20]. However, the specification does not state what state a stateful tool holds, who holds it, how long it is retained, or what happens to that state when a connection drops[^23]. ## Protocol evolution and changes across revisions In the field, reports suggest that the Tools page grew by roughly half between the 2025-11-25 and 2026-07-28 revisions, with the expansion being almost entirely additive[^10]. Comparison across the revisions reveals several modifications to tool constraints and fields[^17][^13][^14]: - The requirement that a server's tool set must not vary per connection is new in the 2026-07-28 revision and does not appear in the 2025-11-25 revision[^17]. - The recommendation that servers return tools in a deterministic order is also new in the 2026-07-28 revision and is absent from the 2025-11-25 revision[^13]. - Execution and task support fields that were present in the 2025-11-25 Tools page were removed in the 2026-07-28 revision[^14]. ## Multi Round-Trip Requests and state handling Multi Round-Trip Requests are designed to function without requiring a shared storage layer across server instances or stateful load balancing[^15]. WarmTransfer's reading of the sources is that Multi Round-Trip Requests do not share the long-lived connection machinery used by [The MCP subscriptions listen stream and notification delivery](https://warmtransfer.net/knowledge/mcp-subscriptions-listen)[^16]. ## Deprecation policy discrepancies Sources disagree on the deprecation rules and timelines across specification sections[^12][^22][^11]. Sources disagree on the length of deprecation windows: the changelog announces a minimum twelve-month deprecation window[^12], yet the deprecated features registry gives HTTP with server-sent events an earliest removal of three months after a proposal reaches Final without publishing that date[^22]. In addition, this is disputed by internal registry statements: the deprecated features registry claims that no features have been removed under the policy yet, even while the changelog for that exact revision lists removals[^11]. ## Applicability Applies to: Model Context Protocol. Sources checked 2026-09-05. Specific rules and comparisons apply to specification revision 2025-11-25[^17][^13] and revision 2026-07-28[^21][^18][^19][^23][^20][^14][^15]. ## What remains uncertain The specific extension to which tasks moved following their removal from the Tools page is not covered by the sources below. Whether the corpus extractor drops diagrams or truncates code blocks during documentation processing is not covered by the sources below. Whether any [Webex published MCP servers for external AI clients](https://warmtransfer.net/knowledge/webex-mcp-servers) expose stateful tools is not covered by the sources below. Whether a state handle can be forged or replayed by an unauthorized party is not covered by the sources below. The contents and features of [Discovery in the Model Context Protocol](https://warmtransfer.net/knowledge/mcp-discovery) introduced as a new page in this revision are not covered by the sources below. The detailed protocol mechanism governing Multi Round-Trip Requests beyond its avoidance of shared storage is not covered by the sources below. The specification details surrounding [Model Context Protocol resources and the caching utility](https://warmtransfer.net/knowledge/mcp-resources-and-caching) are not covered by the sources below. How long a state handle lives and who stores it is not covered by the sources below. ## Sources [^1]: Because the Message Flow section of the Tools page is diagram-only in both 2025-11-25 and 2026-07-28, an extraction that removes mermaid blocks leaves that section empty in both revisions and a comparison of the two extractions shows no change there, although the diagrams differ (inferred). Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Message Flow (compared with the same section of mcp-spec-2025-11-25-server-tools). Checked 2026-09-30. [^2]: The Stateful Tools example on the 2026-07-28 Tools page is a jsonc block containing comments and three separate objects, so it is complete as published yet is not a single valid JSON document. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Stateful Tools, jsonc block. Checked 2026-09-30. [^3]: In the MCP 2025-11-25 Tools page, the Message Flow section consists of a single mermaid sequenceDiagram code block and contains no prose. Source: [Model Context Protocol specification 2025-11-25, Server Features: Tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools), Message Flow. Checked 2026-09-30. [^4]: The 2025-11-25 Tools Message Flow diagram shows the update steps without an opt block and without any subscriptions/listen or acknowledgement message: the server sends tools/list_changed and the client then calls tools/list. Source: [Model Context Protocol specification 2025-11-25, Server Features: Tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools), Message Flow, mermaid block, 'Updates' note. Checked 2026-09-30. [^5]: As served on 2026-09-30 the 2026-07-28 Tools page contained 23 json blocks, 1 jsonc block and 1 mermaid block, every fence was closed, and the document ended with the list item 'Log tool usage for audit purposes'. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), whole page; final line under Security Considerations. Checked 2026-09-30. [^6]: In the MCP 2026-07-28 Tools page, the Message Flow section consists of a single mermaid sequenceDiagram code block and contains no prose. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Message Flow. Checked 2026-09-30. [^7]: The 2026-07-28 Tools Message Flow diagram places the update steps inside an 'opt listChanged' block in which the client first sends subscriptions/listen (toolsListChanged: true) and the server sends notifications/subscriptions/acknowledged before notifications/tools/list_changed. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Message Flow, mermaid block, 'opt listChanged' group. Checked 2026-09-30. [^8]: Because legacy clients have no fall-forward mechanism, a server that must keep existing initialize-based integrations working while adopting 2026-07-28 has to be dual-era rather than modern-only, and it may serve both eras concurrently on one endpoint (inferred). Source: [Model Context Protocol specification 2026-07-28, Versioning and Compatibility](https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning), Compatibility Matrix; Backward Compatibility with Initialization-Based Versions. Checked 2026-09-16. [^9]: Because MCP is stateless and has no protocol-level sessions, servers that need state mint explicit handles, and servers implementing authorization MUST verify all inbound requests and MUST NOT treat possession of a state handle as authentication. Source: [Model Context Protocol specification 2026-07-28, Security Best Practices](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices), State Handle Hijacking. Checked 2026-09-16. [^10]: The Tools page grew by roughly half between the 2025-11-25 and 2026-07-28 revisions and the change is almost entirely additive (field report). Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools page compared across the two revisions. Checked 2026-09-05. [^11]: The deprecated features registry states that no features have been removed under the policy yet while the changelog for the same revision lists removals (disputed). Source: [Model Context Protocol specification 2026-07-28, Deprecated Features](https://modelcontextprotocol.io/specification/2026-07-28/deprecated), Deprecated Features registry compared with Key Changes. Checked 2026-09-05. [^12]: The specification changelog announces a minimum 12 month deprecation window (disputed). Source: [Model Context Protocol specification 2026-07-28, Key Changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog), Key Changes, deprecation policy. Checked 2026-09-05. [^13]: The recommendation that servers return tools in a deterministic order is new in the 2026-07-28 revision and does not appear in the 2025-11-25 revision. Source: [Model Context Protocol specification 2025-11-25, Server Features: Tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools), Tools page compared across the two revisions. Checked 2026-09-05. [^14]: The execution and task support fields present in the 2025-11-25 Tools page are removed in the 2026-07-28 revision. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools page compared across the two revisions. Checked 2026-09-05. [^15]: Multi Round-Trip Requests are designed to work without requiring a shared storage layer across server instances or stateful load balancing. Source: [Model Context Protocol specification 2026-07-28, Multi Round-Trip Requests](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr), Multi Round-Trip Requests. Checked 2026-09-05. [^16]: Multi Round-Trip Requests do not share the long-lived connection machinery that subscriptions use (inferred). Source: [Model Context Protocol specification 2026-07-28, Multi Round-Trip Requests](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr), Multi Round-Trip Requests. Checked 2026-09-05. [^17]: The requirement that a server's tool set must not vary per connection is new in the 2026-07-28 revision and does not appear in the 2025-11-25 revision. Source: [Model Context Protocol specification 2025-11-25, Server Features: Tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools), Tools page compared across the two revisions. Checked 2026-09-05. [^18]: The Stateful Tools section contains no RFC 2119 keywords at all; MUST SHOULD MAY REQUIRED and SHALL each occur 0 times within it. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > Stateful Tools. Checked 2026-09-05. [^19]: The specification states that the protocol has no concept of a state handle and that from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > Stateful Tools. Checked 2026-09-05. [^20]: The specification reconciles stateful tools with the rule that a tool set must not vary per connection: the invariance rule binds the tools list operation while handles vary the tool call. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > overview paragraph read together with Stateful Tools. Checked 2026-09-05. [^21]: The Model Context Protocol's Stateful Tools section declares itself non-normative guidance for tool design. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > Stateful Tools. Checked 2026-09-05. [^22]: The deprecated features registry gives HTTP with server-sent events an earliest removal of 3 months after a proposal reaches Final, and does not publish that date (disputed). Source: [Model Context Protocol specification 2026-07-28, Deprecated Features](https://modelcontextprotocol.io/specification/2026-07-28/deprecated), Deprecated Features registry. Checked 2026-09-05. [^23]: The specification does not state what state a stateful tool holds who holds it or for how long, nor what happens to it when a connection drops. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > Stateful Tools. Checked 2026-09-05. [^24]: Statefulness in Model Context Protocol tools is a design convention carried in ordinary tool arguments and results rather than a protocol mechanism (inferred). Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > Stateful Tools. Checked 2026-09-05.