Long Live MCP – a recap of MCP Dev Summit NY

By Ross Williams, Director of Application Engineering

If you’ve been paying attention to the dev conversation online the last couple of months, you’ve seen some version of the “MCP is over” take. Claude Code is just CLI calls. Security folks carved up the auth spec at RSAC. Every few weeks some new protocol lands promising to eat MCP for breakfast.

Short answer: no, MCP is not dead. MCP Dev Summit NA 2026 pushed back on the death narrative, mostly quietly, through who showed up and what they were running. More importantly, the summit laid out a concrete 2026 roadmap that directly addresses the valid concerns the critics had: scaling MCP on serverless, and getting auth off bearer tokens without DCR pain.

The event drew roughly 1,200 attendees to the New York Marriott Marquis on April 2 and 3. It was also the first summit under the new Agentic AI Foundation at the Linux Foundation, after MCP was donated there in December 2025. Jim Zemlin drew the CNCF comparison directly from the opening stage: CNCF took about 13 months to become infrastructure currency for cloud-native. MCP did the same in about 13 weeks.

“MCP is dead” met the people with it in production

James Hood at AWS made the point most directly in his “MCP @ Amazon Scale” keynote. One of his slides had the Mark Twain line on it: “the reports of my death have been greatly exaggerated.” The self-described former AI skeptic put it in his own words: “There’s a flurry of social media posts or articles proclaiming the death of MCP. I can tell you at Amazon, that is not true.” The enterprise keynote roster across both days read the same way: Uber, Duolingo, Datadog, Docker, Nordstrom, Bloomberg, PwC, WorkOS, Workato. OpenAI’s Nick Cooper landed the cleanest framing on Day 2: “MCP is an API for AI,” specifically designed assuming the consumer is a model, not a human developer. On CLIs versus MCP, his answer was “you clearly want both. The most powerful systems combine them.”

DSP’s 2026 roadmap

Every session from the summit is now on the Agentic AI Foundation YouTube channel. If you only have time to watch one, 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 going 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 (designed for serverless runtimes like AWS Lambda and Cloudflare Workers), hardened long-running tasks (SEP-1686, for async jobs that take minutes or hours), and enterprise auth via Cross-App Access (XAA, covered below). All three directly address the valid concerns the critics had been pointing at.

Beyond June, DSP flagged a number of things on the horizon. Triggers are basically webhooks for MCP, so servers can wake up clients when new data arrives, opening up reactive agentic workflows that today you have to poll for. Native streaming will replace all-or-nothing tool results with incremental output, which matters as models kick off tool calls that produce a lot of data. Skills over MCP gives you a way to ship skill libraries alongside MCP servers. Interceptors give the protocol standard hook points for observability, policy, and telemetry, and Bloomberg already has a production implementation. And composability through code lets the model write a small program that chains several tool calls in sequence on the server side, so A→B→C becomes one exchange instead of three round-trips back to the LLM.

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: phone calls become email threads

The most important change in the June release for anyone running remote MCP servers on serverless is MRTR, Multi Round-Trip Requests (SEP-2322). The simplest way to explain it:

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 from an audience, 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 AWS Lambda or Cloudflare 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.

For any team that has tried to make elicitation, sampling, or long-running tasks work on a horizontally-scaled backend, MRTR moves those features from “impossible on our architecture” to “just a normal email thread.”

The official SDKs are moving in parallel with the spec. Max Isbey at Anthropic laid out the shape in “Path to V2 for MCP SDKs”: TypeScript V2 alpha is out now, Python V2 beta is Q2, and both stable releases ship alongside the June spec. The architectural headline is a clean dispatcher pattern that 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. TypeScript V2 also runs natively on Cloudflare Workers, a strong signal that the ecosystem is treating serverless as a first-class deployment target. Go joined TypeScript, Python, and C# in the tier-1 SDK list.

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, or just watch the sausage get made, it is a good place to hang out.

The auth story: CIMD for clients, XAA for enterprise

Two things landed in the auth track, and both matter for anyone trying to deploy MCP to real users.

CIMD (Client ID Metadata Documents) is the fix for Dynamic Client Registration. If you have tried to put OAuth in front of a remote MCP server, you have hit DCR, 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. 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. No registration table, no silent expiry, no impersonation risk. Claude Code shipped CIMD support two weeks before the summit. CIMD and DCR can coexist on the same authorization server, so adoption is additive rather than rip-and-replace.

Cross-App Access (XAA) is the enterprise security story, and it’s the one to watch if you’re deploying MCP inside a company. Demoed live across Claude Code and Cursor into a real Figma MCP server with zero consent screens visible to the user, XAA lets the workforce IdP handle authorization centrally so end users stop drowning in per-app OAuth prompts. For enterprise deployments of MCP, XAA is how the “every user has to approve every tool integration” problem gets solved without rolling your own SSO layer.

Aaron Parecki, co-author of the OAuth 2.1 draft, tied the whole auth story together in one line: “Most of OAuth works fine for MCP. It’s three specific gaps.” Client identification (CIMD). Bootstrap discovery from one URL (Protected Resource Metadata, now RFC 9728). Enterprise consent fatigue (XAA).

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 communicate bidirectionally over postMessage. Within four months every major host adopted it: Claude, ChatGPT, VS Code with Copilot, Cursor, Goose, Postman. The fastest extension adoption I have seen in this ecosystem.

Chat became the default 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. Any server can ship an interactive view that renders in any compatible host, and because the host sits between the UI and the model, the agent stays in the loop and knows what the user just did. The Day 2 keynote by Ido Salomon (creator of MCP-UI) and Liad Yosef (co-creator of MCP Apps) made the case plainly: 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.

The next frontier is closing the bidirectional gap in production. A lot of current implementations render something nice from the server and stop there. The interesting work is when the UI fires events back through the host, triggering new agent turns, and letting the model reason about what the user just did.

Tasks in practice

One Day 1 session resonated with me for a personal reason. In “Durable, Asynchronous, and Tricky: Implementing MCP Tasks in Practice,” 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 we are not alone in that experience. 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.”

The short version

A year of workarounds, half-built fixes, and skeptical social media threads got answered on stage by people with working code. The June 2026 spec release is the inflection point. If you’ve been waiting for MCP to grow up before betting on it, the wait is basically over.

The next North American AAIF event is AGNTCon + MCPCon North America in San Jose on October 22 and 23. See you there.