The MCP spec stateless update, released on July 28, 2026, removes the requirement for persistent streams in remote MCP servers, so any request can be routed to any machine behind a load balancer. Clare Liguori, a Senior Principal Engineer at AWS and a core MCP maintainer, described the change and the new extensions framework that surrounds it.
What the stateless MCP spec release changed
The mcp spec stateless release of July 28, 2026 removes the requirement that a remote MCP server hold a persistent stream open, so each request can be processed independently and routed to any machine behind a load balancer. Clare Liguori, a Senior Principal Engineer at AWS and a core maintainer of the specification, described it as a change aimed mainly at server developers, not client developers.
Before the release, a remote MCP server that wanted to use interactive features had to build stateful streaming into its own code. That design forced sticky sessions at the load balancer, which makes horizontal scaling awkward and is a common source of operational trouble. Liguori's claim is that dropping that requirement should make remote MCP servers easier to publish, including for SaaS providers that currently ship standard input/output servers for developers to download onto a laptop.
The Model Context Protocol specification is the canonical place to check the exact revision language, because the transcript's description is a summary and the specification text is what a client or server implementation must follow.
How a stateless MCP server handles elicitation
Elicitation lets an MCP server ask the client for more information mid-call, and under the stateless design it works by closing the request and resuming in the next one. The server returns the elicitation rather than pushing it down a stream, and the client includes that elicitation plus the user's filled-in values in its following request.
The pattern resembles how applications talk to a model. Each request carries forward the accumulated context from previous requests, so the server never needs memory of an earlier connection. Liguori's description is a loop: call the server, receive an elicitation, close the request, then send the next request with the elicitation and the answers attached. In sequence:
- The client calls the stateless MCP server.
- The server returns an elicitation instead of pushing it down a stream, and the request closes.
- The client sends the next request carrying that elicitation plus the user's filled-in values.
A practical consequence is that the negotiation between the client and the server stays outside the model's own conversation context. Only the final result of that exchange is handed back to the model, which matters if you are counting tokens on a small context window.
What server and client developers each have to do
The change lands differently depending on which side of the connection you build:
| Role | What changes | What it unlocks |
|---|---|---|
| Server developer | No server-side memory of an earlier connection is needed | Spec features that were hard to support over HTTP, including elicitation |
| Client developer | Mostly an updated MCP SDK, or an updated framework that wraps one | Ability to speak the new capabilities |
| Gateway operator | Configures which revisions the gateway supports | Version negotiation across old and new clients |
Liguori said the AWS managed MCP gateway, AgentCore Gateway, was updated on the same day as the specification release. A gateway can negotiate which version of the specification a client speaks, so existing clients using the older revision can keep connecting while newer clients use the new capabilities, and administrators can configure which revisions a gateway supports.
Skills, Tasks and Events as MCP extensions
MCP extensions are the mechanism the project now uses to ship a feature before it becomes part of the official specification. Liguori said extensions existed before this cycle but were ad hoc, and that the formal framework means most new features will start as extensions, get adopted, and only then graduate into the specification itself.
The stated reason is durability. MCP is widely implemented, so a breaking change in the core specification is expensive for everyone downstream. An extension can evolve or be dropped without the same cost.
- Skills over MCP bundles a workflow description together with the set of tools it needs, in the same server. It targets a common problem where a server wraps an existing API one tool to one endpoint, leaving the model to work out that tools A, B and C must be called together for a useful result.
- Tasks handles long-running jobs. A server can start a build or another lengthy operation, return, and deliver the result later instead of blocking the agent on the work.
- Events lets an external signal wake an always-on agent. Liguori said she built an MCP server that notifies an agent when earthquakes occur, and that Slack-based experiments are running alongside it.
Strands Agents Harness SDK and the TypeScript 1.0 release
The Strands Agents Harness SDK packages context management, compaction and out-of-the-box file tools so that an agent arrives more capable without the developer assembling every piece. Strands Agents is AWS's open source agent framework, and Liguori is one of the people behind it.
The design goal she described is model portability inside one framework. When a new model arrives with better reasoning and tool selection, changing the model identifier in the code should be enough for the agent to improve, because the framework's tool and context handling stay the same.
Liguori said the Strands Agents TypeScript SDK reached version 1.0 in the month before the recording. The team had tried an earlier experiment in which an agent translated changes from the Python SDK into TypeScript, and it did not work well at the time. A newer version of that experiment is now running to keep the two SDKs in sync.
A third language depends on how that synchronization experiment goes. Liguori said Java is the most requested language and Rust comes up occasionally, with Rust likely harder to translate into agentically.
What Strands Shell is, and where it runs
Strands Shell gives an agent a minimal bash environment backed by an in-memory virtual file system, so scripts can run without touching the real disk on the machine. It is written in Rust, which is why it works across platforms rather than being limited to macOS and Linux, and it currently ships for Python.
The intended use differs from a code interpreter. Liguori described the common case as a scratchpad: giving an agent file read and file write tools so it can keep a to-do list or research notes, without granting access to a laptop's actual disk and without running arbitrary Python.
She also placed Strands Shell as a tool an agent can choose rather than a sandbox that wraps the whole agent. In a narrow use case it can be swapped in where a bash tool would otherwise be used, and it can mount a single directory when in-memory storage is not enough.
Strands Labs and the robot agents inside it
Strands Labs is where AWS experiments with agent ideas that are not yet stable enough for the production framework. The reasoning is that the Strands Agents SDK carries a stability expectation, so experimental work needs somewhere else to live.
Physical AI is one of the areas there. The pattern Liguori described pairs a small vision-language-action model running on the robot for low-latency motor control with a frontier model in the cloud for longer-range planning, coordinated through Strands. A local model small enough to move motors quickly cannot do multi-step planning, and a Claude Code is too slow for motor control, so the two are split by role.
Kiro's clients, 1.0 releases and shared harness
Kiro now ships as three clients on one shared harness: the IDE, the CLI and web. Kiro is AWS's agentic coding tool, and Liguori said the company released Kiro IDE 1.0 and Kiro CLI v3, with global hooks and a unified permission system distributed across all clients at once.
Kiro web is in preview. Liguori said it gives a session a cloud sandbox that Claude Code from a GitHub or GitLab repository, holds a conversation with an agent, and can OpenAI pull request when the work is ready. Liguori said the iOS app is available for people to sign up for preview access to the same web sessions.
The shared harness is what makes the release cadence possible. Specs, hooks and skills previously differed between clients; the harness consolidates them, so a capability is built once and shipped to IDE, CLI and web together. Policy presets are one result, giving a user a starting permission set such as reading anything or trusting tools a developer would normally enable, rather than requiring every tool to be trusted individually.
Ambiguity detection and property-based testing in Kiro
Kiro uses automated reasoning techniques to flag ambiguous or conflicting requirements and to test whether stated properties hold, adding proofs and checks around specification-driven development. Liguori said the work comes from the automated reasoning group at AWS, whose background includes formal verification of hardware.
The two named applications are property-based testing and requirement analysis. Property-based testing takes a property that must always hold, such as credentials never being stored in plain text, and generates many inputs to check it. The requirement analysis detects ambiguity and conflicts between requirements, which Liguori illustrated with a pair of statements that contradict each other about encryption.
| Mechanism | What it acts on | What it produces | Guarantee type |
|---|---|---|---|
| Property-based testing | Properties that must always hold, e.g. credentials never stored in plain text | Generated inputs exercising the property | Checks, not proofs |
| Requirement analysis | Requirements text | Flags for ambiguity and conflicting requirements | Detection, not correction |
| Cedar-based permissions | Authorization policies | Policy evaluation for the permission system | Formally verified policy language |
The permission system draws on the same group's work. Liguori said permissions are based on Cedar, an authorization policy language that has been formally verified, which is a different kind of guarantee from a hand-written allowlist.
What the constraint does and does not cover
These checks operate on requirements and on stated properties. They do not turn generated code into verified code, and Liguori described the direction of the work as improving confidence in agent-generated output rather than providing a blanket correctness proof.
Where Kiro is on CURRENT DATE
On September 15, 2026, Kiro web and the Kiro iOS app are both in preview, while Kiro IDE 1.0 and Kiro CLI v3 are released products on a shared harness. Kiro itself remains AWS's coding assistant, and Liguori named it first among the agentic AI products she works on.
The transcript is from September 3, 2026, so it describes the state of these products twelve days before this article. The current canonical source for the tool is Kiro, where preview status and availability are stated directly rather than inferred from the interview.
Two things in the transcript are notable precisely because they are dated. Liguori said Kiro web was in preview and had recently gained the ability to display files, and that the iOS app had opened preview signups. Both statements reflect the September 3, 2026 position, not a permanent product state.
How specs are written and sized in practice
Specs are checked into the repository, reviewed by pull request, and treated as a dated record of what a team intended to build. Liguori said her teams find that history useful because decisions otherwise disappear, and that Kiro web lets a spec be shared and commented on outside the repository workflow.
On sizing, her practical signal is how long the design is getting. Two symptoms point to splitting the work into multiple specs:
- The design has stopped growing and still lacks the required detail.
- The generated task list settles around a dozen or so steps but sits at the wrong level of detail.
| Signal | What it looks like | Suggested move |
|---|---|---|
| Design stalled | Growth stopped, detail still missing | Split into multiple specs |
| Task list plateaued | About a dozen steps, wrong level of detail | Split into multiple specs |
| Coarse tasks in practice | Tasks like "build a CRUD endpoint" | Add a definition of done to each task |
Her account of building an earthquake application with specification-driven development is the concrete counterexample. The tasks were coarse, such as build a CRUD endpoint, and adding a definition of done to each task let the work stay on track instead of drifting before a final review. Liguori's reconstruction of that work is her own experience using the tool, and the published repository she pointed to is the place to see the spec itself.
FAQ
- What does the MCP spec stateless change mean for server developers? It removes the requirement for persistent streaming in remote MCP servers, so elicitation and similar interactions work by closing one request and resuming in the next. Servers no longer need sticky sessions at a load balancer and can scale across many machines. Client developers mainly need an updated MCP SDK.
- What are MCP extensions such as Skills, Tasks and Events? Extensions are how MCP now ships features before they enter the official specification, so they can stabilize without breaking existing implementations. Skills over MCP bundles a workflow with its tools, Tasks covers long-running jobs, and Events lets an external signal wake an always-on agent.
- Is Strands Shell a replacement for a full code interpreter? Not generally. It provides a minimal bash environment with an in-memory virtual file system, intended for scratchpad uses such as file read and file write without access to the real disk. Cases that need arbitrary Python execution still call for a heavier sandbox.
- Is Kiro web generally available? As of September 15, 2026, Kiro web is in preview, and the Kiro iOS app had opened preview signups. Kiro IDE 1.0 and Kiro CLI v3 are released. Check the official Kiro site for current availability rather than relying on a dated description.
Turning a long interview into a written article
The useful detail in this episode was spread across a long conversation, from protocol design through agent sandboxes to authoring conventions. Anyone who has recorded something similar knows how much of that reasoning ends up nowhere except the video itself, and how hard it is for a reader to find the one paragraph they need.
Skalablog turns that raw material into something readable. You paste a YouTube URL, the video is transcribed, and an article draft comes out. That fits an interview like this one, where the value is in the explanations rather than the timeline. Start at Skala Blog and bring a video you already recorded.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits