Long Live MCP - the Dev Summit recap
Running remote MCP servers on Lambda, Workers, or any horizontally-scaled runtime just got meaningfully easier. A field report of the latest MCP Dev Summit in NY for AWS builders.
I've spent the past year building agentic tools across AWS. A lot of that work has been figuring out how to run remote MCP servers on serverless runtimes without fighting the protocol every step of the way. MCP was originally designed around stateful sessions, which fit beautifully on a long-lived server and poorly on anything that spins up per request, which is most of the AWS surface area I care about.
At MCP Dev Summit NA 2026 earlier this month, the MCP co-creator stood on stage and said the protocol is about to fit serverless natively, starting with the June 2026 spec release. That alone would have made the trip worth it. The auth story got a credible answer the same week, and the SDKs are catching up fast. Here is what changed, and what it means for anyone building MCP on AWS.
Quick context on the event
MCP Dev Summit NA 2026 ran April 2 and 3 in New York. Roughly 1,200 attendees, 17 keynotes, 95+ sessions. Diamond sponsors included AWS, Docker, WorkOS, Workato, and Obot. The governance story briefly: MCP was donated to the Linux Foundation in December 2025 as a founding project of the new Agentic AI Foundation, which AWS chairs the governing board of. AWS is bullish on MCP, and they put that on stage in multiple ways, including James Hood's Principal-Engineer keynote on how Amazon uses MCP internally at scale.
The MCP Dev Summit is retiring in its current form. Going forward the AAIF runs combined AGNTCon + MCPCon events, with Amsterdam in September and San Jose October 22 and 23.
The "MCP is dead" narrative, briefly
Worth addressing in one paragraph. The death narrative was loud in the weeks before the summit, mostly driven by the observation that Claude Code is very effective running CLI commands and doesn't appear to need MCP for most of what it does. That is true for coding agents. For most enterprise use cases, CLIs are not how agents reach systems, and MCP is exactly the right shape for giving an AI model access to resources it couldn't otherwise call. OpenAI's Nick Cooper gave the cleanest framing of the debate in a Day 2 keynote: "MCP is an API for AI," and on CLI-versus-MCP, "you clearly want both. The most powerful systems combine them." If you are reading this thinking the CLI-only takes feel incomplete, they are. The summit moved on quickly.
DSP's 2026 roadmap
If you only watch one recording from this summit, make it David Soria Parra's "MCP: The Integration Protocol" keynote. DSP is the MCP co-creator, and his twenty minutes on stage laid out where MCP is headed in 2026. Almost everything else at the summit was implementation work on that roadmap.
Three things are landing in the June 2026 spec release: stateless transport by default (covered in detail in the next section), hardened long-running tasks (SEP-1686, for async jobs that take minutes or hours), and enterprise auth via Cross-App Access (covered further down). All three directly address the valid concerns the critics had been pointing at.
Beyond June, DSP flagged several items on the horizon that matter for AWS builders:
- Triggers are webhooks for MCP, letting servers wake up clients when new data arrives. For anyone building event-driven agentic workflows on SQS, SNS, EventBridge, or S3 event notifications, this is the primitive that makes reactive agents possible without polling.
- Native streaming replaces all-or-nothing tool results with incremental output, which matters for long-running tool calls that produce a lot of data.
- Skills over MCP lets servers ship skill libraries alongside their tools.
- Interceptors are standard hook points for observability, policy, and telemetry, and Bloomberg already has a production implementation. For AWS deployments, this is where your CloudWatch, OTEL, or PII-redaction logic plugs in at a standards-based layer rather than custom middleware.
- Composability through code lets the model write a small program that chains several tool calls in sequence on the server side. A→B→C becomes one exchange instead of three LLM round-trips, a direct cost and latency win for anyone paying Bedrock by the token.
DSP also addressed the most common criticism of MCP head-on: context bloat. The complaint goes "you connect an MCP server with a thousand tools and now your context window is blown out just reading the tool list." DSP was empathetic but direct: that's a client problem, not a protocol problem. Claude Code already solved it with progressive tool discovery, loading tool definitions only when the model actually needs them, with about an 85% reduction in token usage on real workloads.
The scaling unlock: stateless transport and MRTR
This is the section I would read first if I were you.
The MCP transport has gone through three generations. The original design (stdio) assumed a local server talking to a desktop process. The first remote generation (Streamable HTTP, launched in early 2025) assumed a stateful session between client and server, which scaled poorly on anything horizontal. Every team I know who tried to deploy MCP on Lambda or Fargate or Cloudflare Workers in the past year ended up writing workarounds to fake statelessness.
Three SEPs land in the June 2026 spec release, all from the transport working group led by Kurtis Van Gent at Google and Shaun Smith at Hugging Face:
- SEP-1442 removes the initialization handshake. Protocol version negotiation happens inline on the first request. No stateful session required to start a conversation.
- SEP-2322 is the big one. It introduces MRTR, Multi Round-Trip Requests, which is the mechanism that makes elicitation, sampling, and long-running tasks work without held sessions.
- SEP-2243 moves routing-relevant metadata into HTTP headers so load balancers can route without parsing JSON-RPC payloads.
MRTR is worth explaining in plain English, because it is the change most AWS builders will feel:
Today, a tool call is like a phone call. The client and server stay on the line the whole time. If the server needs to ask the user something mid-call, say to confirm deletion of 1.2 million records, it holds the line open until the user answers. If the connection drops, the call is lost. This is fine on a long-lived server. It is structurally incompatible with any runtime that spins up per-request, like Lambda or Workers.MRTR turns the phone call into an email thread. Each message carries the full context of prior messages. When the server needs to ask a question, it sends a reply with the question and closes the thread. The client comes back later, maybe five seconds later, maybe five minutes later, with a new message that includes the prior exchange. Any server can pick up the new message and respond. No held connections. No sticky routing. No shared memory.
If you've been writing workarounds to keep elicitation or sampling alive across Lambda invocations, MRTR moves those features from "impossible on our architecture" to "just a normal email thread." If you've been avoiding tasks (SEP-1686) because long-running jobs didn't map cleanly onto serverless, the stateless transport plus MRTR plus the tasks primitive make them practical. The spec is finally coming to where a lot of us were building.
The auth unlock: CIMD replaces DCR
If you have tried to put OAuth in front of a remote MCP server, you have hit Dynamic Client Registration, and you probably did what most of us did: looked at it, calculated what a production deployment actually required, and quietly went back to bearer tokens instead. DCR was a structural problem at scale. Bearer tokens became the universal workaround, and the workaround became permanent for a lot of teams.
The fix came from Den Delimarsky at Anthropic, in a session titled "Demistifying Client ID Metadata Documents in MCP." CIMD replaces DCR with DNS-rooted trust. A client hosts a JSON metadata document at a well-known URL, and that URL is the client ID. The authorization server fetches it, verifies the redirect URIs match the origin, and proceeds. No registration table. No silent expiry. No impersonation risk. Claude Code shipped CIMD support about two weeks before the summit. Claude.ai and VS Code support it as clients. Importantly, CIMD and DCR can coexist on the same authorization server, so adoption is additive.
The framing talk came from Aaron Parecki, co-author of the OAuth 2.1 draft at IETF. His three-gap framing is the mental model to take home: "Most of OAuth works fine for MCP. It's three specific gaps." Client identification, answered by CIMD. Bootstrap discovery from one URL, answered by Protected Resource Metadata, now RFC 9728 (also co-authored by Parecki). Enterprise consent fatigue, answered by Cross-App Access (XAA / ID-JAG), demoed live by Paul Carleton at Anthropic and Max Gerber at Twilio with a working flow across Claude Code, Cursor, and a real Figma MCP server, zero consent screens visible to the user.
If you run an MCP server on AWS and have been using bearer tokens as a stopgap, CIMD plus normal OAuth 2.1 is the path off the workaround. You do not have to rewrite your server. You add CIMD support to your authorization server alongside your existing bearer token path and migrate clients over.
SDK V2: serverless validation hiding in the release notes
Max Isbey's "Path to V2 for MCP SDKs" was the third most important talk of the summit. Most of the internals only matter if you write SDK-adjacent code, but there are four flags worth raising for AWS builders.
TypeScript V2 alpha is out right now. You can
npm install it today. Python V2 beta is Q2, with both stable releases tied to the June spec drop. If you are writing TypeScript, you can start experimenting with the new APIs immediately.The architectural headline is the dispatcher pattern. V2 finally separates MCP semantics from wire format and transport, which makes pluggable transports practical for the first time. A custom serverless adapter, gRPC, or WebSockets can slot in without reimplementing the protocol. For AWS builders who have been writing custom transport glue to make MCP fit a serverless runtime, this is the abstraction layer you have been waiting for.
Cloudflare Workers is a first-class target. This is the signal I cared about most. The TypeScript V2 release explicitly lists Cloudflare Workers as a supported runtime, runtime auto-detected, zero config. That is the official MCP SDK now validating serverless edge runtimes as a primary deployment target, not an edge case. If you have been running MCP on Lambda or Workers and feeling like the official SDKs did not quite fit your runtime assumptions, the June release closes that gap. You were early, not weird.
Go joined the tier-1 SDK list alongside TypeScript, Python, and C#. If you were writing Go and hedging against SDK completeness, you don't need to anymore.
Most of this work is community-driven. The spec discussions, SDK development, and extension proposals all live on Discord, and most of the SEPs landing in June came out of those conversations. If you want to contribute to the work, or just watch the sausage get made, it is where to hang out.
A quick note on Bedrock AgentCore
If you're an AWS builder working in agentic AI, you are probably also looking at Bedrock AgentCore , AWS's fully managed agentic platform. AgentCore bundles a scalable agent runtime, persistent memory, a secure browser sandbox, a code interpreter, and a Gateway service that turns APIs and Lambda functions into agent-compatible tools. The part that matters for this article: AgentCore Gateway has native MCP support. You can connect existing MCP servers through it and unify them behind a single interface with OAuth, semantic tool discovery, and standardized security. That means AgentCore is not a replacement for MCP. It's a managed platform that speaks MCP as one of its primary tool protocols. Everything in this post about the MCP spec evolving applies regardless of whether you build directly against MCP, use AgentCore Gateway to front your MCP servers, or mix both approaches.
Gateways and registries became the architectural consensus
Every enterprise speaker running MCP at scale had built the same thing. A centralized gateway plus registry, serving as the control plane for all agent interactions. Uber auto-exposes thousands of internal services through a Go-based gateway with PII redaction built in. Amazon expanded their internal registry to treat agent configurations as first-class primitives. Alex Salazar at Arcade.dev gave the cleanest framing: separate the reasoning layer (where LLMs operate) from the action layer (where governance, auth, and mutations live).
The AWS-specific find from the expo floor. I met Amit at the AWS open source booth, who maintains agentic-community/mcp-gateway-registry , an Apache 2.0 deployable project that runs on ECS Fargate and DocumentDB, integrates with Bedrock AgentCore, supports multi-provider IAM across Keycloak / Entra ID / Okta / Auth0, does fine-grained OAuth 2.0/3.0 at the tool and method level, handles semantic tool discovery via FAISS, and federates with the Anthropic MCP Registry via a Registry Card spec. Observability is OTEL push to Datadog, New Relic, Honeycomb, or Grafana. The README is worth reading even if you don't deploy it. The design doc is a good reference for what a production gateway should do.
MCP Apps: the future of the internet
MCP Apps is the first official MCP extension, shipped on January 26. Servers return tool results that point at HTML/JS/CSS bundles, the host renders them in a sandboxed iframe, and UI and host talk bidirectionally via JSON-RPC over postMessage. Within four months every major host adopted it: Claude, ChatGPT, VS Code with Copilot, Cursor, Goose, Postman. The architectural principle is that the UI talks back to the server through the host, not directly, so the agent stays in the loop.
The Day 2 keynote from Ido Salomon (creator of MCP-UI) and Liad Yosef (co-creator of MCP Apps) made the larger case: chat became the dominant UI for AI, which is great for conversation and limiting for everything else. MCP Apps brings rich interactive components back into the conversation in a standards-based way. This is the future of the internet. The chat-box era is opening back up into rich, interactive, agent-driven surfaces, and the standard for how that works is being set right now. If you build an MCP server that surfaces rich data, MCP Apps is how you expose interactive views of that data to any compatible host without building your own UI for each one. It is worth watching for any AWS builder touching an MCP server.
Tasks in practice
One Day 1 session resonated with me for a personal reason. "Durable, Asynchronous, and Tricky: Implementing MCP Tasks in Practice," by Cornelia Davis at Temporal, walked through implementing the SEP-1686 tasks primitive. She said along the way: "There are no off-the-shelf agents today that support the task protocol. None. Claude doesn't. Claude Desktop doesn't. Goose doesn't. I thought Goose might."
She had to build her own client from scratch to demo anything. Nice to know I am not alone in that experience. When the big-name agents haven't caught up with a spec feature you need, you either wait or you build. Davis closed her session with a line that ties the tasks work back to the transport story:
"Doing async over a stateful transport protocol is really tricky. I was over the moon excited this morning when I heard at least one, if not two, people in the keynote say we want to work on a transport protocol that is stateless."
What's worth watching
Every session from the summit is now on the Agentic AI Foundation YouTube channel . If you only watch a handful, I'd prioritize:
- David Soria Parra's "MCP: The Integration Protocol" for the spec direction
- Max Isbey's "Path to V2 for MCP SDKs" for what's changing under the hood
- Van Gent and Smith's "Stateless: The Future of MCP Transports" for the SEP walkthrough
- Den Delimarsky's "Demistifying Client ID Metadata Documents" for the actionable DCR replacement
- Carleton and Gerber's "Putting the Single Back in Single Sign-On" for the live XAA demo
- Cornelia Davis's "Durable, Asynchronous, and Tricky" for the bridge between tasks and stateless
Takeaways for AWS builders
Four things worth internalizing if you are building MCP on AWS:
- The June 2026 spec release is the inflection point. Plan your roadmap around it. If you have been writing stateful-session workarounds on serverless, stop doubling down. The fix is months away.
- TypeScript V2 is shippable today. If you are OK with alpha code, you can validate your architecture against the new APIs right now.
- CIMD is the path off bearer tokens. You don't have to rewrite your server. Add CIMD to your authorization server and migrate clients over. Claude Code already supports it.
- The gateway pattern is the emerging architectural consensus. If you're going to run multiple MCP servers in production, start thinking about an aggregating layer. Amit's open-source project is a credible starting point.
If you're building MCP on AWS and want to compare notes, especially on serverless patterns or auth, find me on LinkedIn. I am always happy to talk with builders solving the same problems. See you in San Jose.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article