# Yes, we do need MCP

Ben Hindman, reboot.dev | Coding Agents Conference 2026 | 26:32

Source: https://www.youtube.com/watch?v=4TFSGycIsNA
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/yes-we-do-need-mcp
Published: 2026-02-24
Tags: mcp, reliability, testing

## TL;DR
- Statefulness is necessary for AI conversations that can survive dropped connections and server restarts.
- MCP currently has uneven client support for resumability, redelivery, elicitation, sampling, retries, and idempotency.
- Conformance test suites should give MCP implementations a shared interpretation of the specification.

## Summary
Ben Hindman argues that statefulness, usually treated as a liability in distributed systems, is necessary for useful AI applications. Chat-based systems need context from other software and the ability to take actions, so their conversations must survive client failures, broken connections, and server restarts. MCP includes resumability and redelivery mechanisms, but Hindman says client support is incomplete and inconsistent. Retries create a further risk because a repeated tool call could charge a credit card or complete another side effect twice. His demo uses durable MCP, Goose, and MCP UI to show a checkout that completes after a server failure, then gets repeated because the client and model cannot resume the original request safely. Hindman calls for first-class retry and idempotency support, broader client implementation, and conformance testing. He also discusses elicitation, sampling, durable data structures, and scaling MCP servers across many sessions.

## Key ideas
### AI applications need statefulness because conversations must survive interruptions
[00:51](https://www.youtube.com/watch?v=4TFSGycIsNA&t=51s)
Hindman expects chat, whether typed or spoken, to remain a main interface for interacting with AI. Models alone are insufficient for high-value tasks, so applications need context from other software and agency to perform actions. Those conversations must tolerate disruptions. He compares an AI interaction with a phone call: if the call drops and you dial back, you expect to continue near where you stopped rather than explain everything again. Traditional software often tries to avoid state because state complicates scaling and failure recovery. Hindman argues that AI changes this tradeoff. For AI applications, statefulness is a feature because it supports a continuing, human-like conversation.

### MCP client support is broad for tools but incomplete for other protocol features
[05:23](https://www.youtube.com/watch?v=4TFSGycIsNA&t=323s)
Hindman describes MCP as a comprehensive specification that has grown through several iterations and is gaining adoption. He also points to immature and incomplete implementations. In the client support matrix, most clients implement tools, while many other MCP features are missing. Among ChatGPT, Claude, Cursor, Goose, and VS Code, he says VS Code is the only client that implements the full set shown in his comparison. This makes it difficult to build a server that behaves consistently across clients. Features such as elicitation and sampling may work in one environment and fail or behave differently in another.

### Resumability and redelivery exist in MCP, but support and interpretation differ
[08:08](https://www.youtube.com/watch?v=4TFSGycIsNA&t=488s)
For fault tolerance, Hindman separates client failure, connection failure, and server failure. The Streamable HTTP specification includes resumability and redelivery, which can help after a broken connection or server reboot. In his experience, however, only VS Code appears to implement these features. He says VS Code's approach also differs from the interpretation used by people working on MCP transports and from the SDK test cases. His comparison to early web browsers explains the practical problem: servers may need to identify the client and adapt their behavior. Hindman sees an opportunity to make resumability and redelivery standard and consistent across clients.

### Retries require idempotency because a repeated tool call can repeat a side effect
[11:08](https://www.youtube.com/watch?v=4TFSGycIsNA&t=668s)
A retry is unsafe when the original request may already have reached the server. Hindman uses charging a credit card as the example. A system needs a unique identifier, such as an idempotency key, so the same request is performed only once. MCP has a rule about request IDs within a session, but Hindman says the specification is close to providing the needed session and request identity without making it a reliable standard. He also says the official Python MCP SDK does not consistently follow the practice. Current clients often time out and retry, which can be worse than normal web behavior because MCP clients or models may repeat operations with side effects.

### The demo shows how missing resumability can buy the same item twice
[13:28](https://www.youtube.com/watch?v=4TFSGycIsNA&t=808s)
Hindman's demo uses durable MCP, a durable context, Goose, and MCP UI. The application presents a shopping experience inside chat, with React components for the cart and checkout. He adds a server hook that hangs during checkout, then restarts the server without the hang. The server completes the checkout, but Goose does not resume or redeliver the interrupted operation. When Hindman asks to see his orders, the model decides to continue the previous checkout and performs it again. The result is two purchases of the leather watch. The example shows why a durable server alone is insufficient when the client and model cannot preserve the original operation's state.

### Conformance testing should give MCP implementations one shared interpretation
[21:24](https://www.youtube.com/watch?v=4TFSGycIsNA&t=1284s)
In the question period, Hindman says the most useful first step is a conformance and compliance test suite for MCP. A specification provides a source of truth, while an SDK implements that specification. A test suite would give different implementations a common basis for deciding whether they behave correctly. Passing the same tests would reduce differences in how clients, servers, and SDKs interpret features such as retries and fault tolerance. He expects this to expose conflicting interpretations and help the community converge. After that shared foundation exists, the open-source community can propose changes from the same starting point.

### MCP clients should not retry unless the request is clearly idempotent
[23:34](https://www.youtube.com/watch?v=4TFSGycIsNA&t=1414s)
Hindman explains that a browser generally cannot know whether a server began processing a request when the response is lost. A browser therefore leaves retry decisions to application logic, where the developer knows whether the operation is safe. MCP clients should follow a similar rule and avoid retrying unless the request is clearly idempotent. The model creates another complication because it may decide to retry a tool call after a failure. Hindman says MCP needs a way to tell the model that an operation can only happen once. He believes the protocol can address this through specification work and clearer request semantics.

## Notable quotes
- "But really for AI statefulness is going to be a feature not a bug." (04:40)
- "We don't want to charge a credit card more than once." (11:28)
- "So, um, hopefully that's a demonstration of where, you know, we're close, but we're really not there yet." (17:43)
- "If it passes, if your code passes the conformance test suite, then it's doing the thing that it should be doing." (22:09)

## Tools & references mentioned
- Apache Mesos
- Mesosphere
- D2iQ
- CNCF
- reboot.dev
- Model Context Protocol
- MCP
- Streamable HTTP
- ChatGPT
- Claude
- Cursor
- Goose
- VS Code
- durable MCP
- MCP UI
- React
- Microsoft MCP gateway

## Who should watch
- You are building MCP servers that must survive client, connection, or server failures.
- Your tools perform side effects such as purchases, payments, or other operations that cannot safely run twice.
- You need to understand why MCP client compatibility and conformance testing matter before depending on elicitation, sampling, or resumability.

## Related talks

- [MCP is not going to change everything (yet)](https://mlopstalks.com/talks/mcp-is-not-going-to-change-everything-yet) (Sam Partee, Arcade AI & Rahul Parundekar, AI Hero, 1:04:43)
- [Responsible Autonomy: Building Governance Frameworks for AI That Act in the Real World via MCP](https://mlopstalks.com/talks/responsible-autonomy-building-governance-frameworks-for-ai-that-act-in-the-real) (Saurabh Mishra, Optum, 27:55)
- [MCP Goes Stateless](https://mlopstalks.com/talks/mcp-goes-stateless) (John Dellenbaugh, Early-stage AI startup & Pankaj Kumar, Amazon, 22:41)
- [MCPs for Observability Stacks](https://mlopstalks.com/talks/mcps-for-observability-stacks) (Diana Todea, VictoriaMetrics, 24:28)
- [Stateless, Yet Durable: MCP Tasks v2](https://mlopstalks.com/talks/stateless-yet-durable-mcp-tasks-v2) (Cornelia Davis, Temporal, 26:23)