MCP Dev Summit North America

AI agents are quickly becoming the new browsers, changing how users consume content and get work done. That shift is increasingly powered by a new generation of agentic apps that don’t just present text but deliver interactive experiences within any MCP host. By standardizing interactive UI on MCP, the MCP Apps official extension (SEP-1865) is poised to become the new agentic app runtime, serving as the backbone of the future and removing adoption obstacles that previously hindered the protocol.

Join us to learn more about:

The new web -
How MCP Apps reshapes the traditional app landscape and transforms the way users interact with the web

MCP Apps -
- Architecture
- Real-world use cases
- What's ahead?
- Getting started (+community and #mcp-apps-wg)

Future vision

At HubSpot, we recognized that any RPC with a schema is already a tool definition, so we built our AI tooling infrastructure on top of our existing RPC framework instead of starting from scratch. Engineering teams can now expose any API to internal agents, public MCP clients, and customer-facing AI products with just two annotations, enabling rapid development and tool reuse across all of our AI systems. This talk covers the architecture, the tradeoffs, and how this approach let us ship agentic capabilities faster than we ever expected.

Most technical talks feel like a one-way street: I talk, you listen, and maybe you ask a question at the end if we have time. But the Model Context Protocol (MCP) isn't about one-way communication; it's about creating a living connection between a "brain" (the LLM) and the "world" (your data and tools).

To prove this, we aren't going to look at static slides. Instead, we are going to use a Live Audience Agent.

At the start of the talk, a QR code will go up on the screen. Anyone in the room can scan it and access a simple web interface. You can send in "Live Vibe Checks"—short text snippets, emoji reactions, or "Heckles"—that feed directly into a database. My MCP server is the bridge. It connects my LLM assistant to that live database of your thoughts.

This is a high-stakes demo. If the protocol works, the AI will be my co-speaker, responding to the room's energy in real-time. If I break the protocol, which I plan to do, repeatedly, the AI will lose its connection to you. We're going to perform "Selective Sabotage" to see exactly which parts of the MCP spec keep the lights on.

The best MCP server is the one you didn't have to build.

At Cloudflare we have a lot of products. Our REST OpenAPI spec is over 2.3 million tokens. When teams started building MCP servers, they did what everyone does: cherry-picked important endpoints for their product, wrote some tool definitions and shipped a separate service that covered a small fraction of their API.

This was driven by a fundamental context limit of the end users' agent. And tools use a bunch of context just to describe themselves. MCP felt like a Mega Context Problem (and a separate service to maintain).

I think we got it all wrong.

The context limit is not an MCP problem. It's an agent problem. Tools should probably be discovered on demand and clients are coming around to this. But maybe we can also do it on the server?

CLIs get this for free, self-discoverable and documented by design. APIs just need a little help.

This talk will cover some of the techniques we've been exploring at Cloudflare, such as codemode and tool search, to make complete APIs accessible to agents through MCP.

I'll also cover some of the work we are doing with the MCP Typescript SDK to make stateless servers the default.

The MCP security conversation focuses heavily on prompt injection, tool abuse, and session hijacking. These matter. But if you're running a registry of MCP servers, your most likely breach won't be complicated. It will be a compromised server you trusted too quickly.

Supply chain attacks aren't new, and neither are the defenses. But the speed of MCP adoption has outpaced basic hygiene: validation, provenance, versioning, and review processes that mature package ecosystems learned the hard way.

This talk argues that before you harden against novel agent-based attacks, you need to treat your MCP registry like critical infrastructure. We'll cover practical approaches to vetting servers, establishing trust boundaries, detecting drift, and building review workflows that scale.

Prompt injection is a real threat. But the server you added last week without review is a more immediate one.

Healthcare providers lose 30-60 minutes per insurance claim error, with the industry wasting $250B+ annually on administrative overhead. At Kustode, we built a multi-tenant RCM platform processing thousands of daily EDI transactions (837P claims, 835 remittances, 270/271 eligibility). While we automated the EDI pipes, intelligent workflow orchestration—denial management, prior authorization, claim intervention—remained manual until we integrated MCP.
You'll learn:
- Integrating MCP into existing production systems vs. greenfield builds
- Multi-tenant MCP architecture with PHI isolation and compliance
- Orchestrating long-running workflows (45+ day denial cycles) with state management
- Real workflows: automated denial resolution, prior auth orchestration, intelligent claim intervention
- Security patterns for MCP in regulated environments
- Production metrics: time savings, denial reduction, deployment challenges
- When MCP beats traditional API orchestration
This talk shares production lessons from deploying MCP workflows in a HIPAA-compliant healthcare platform

You give an agent a complex task. It says "Absolutely!" Then it deletes your production database.

As engineers adopt AI agents, a common frustration is emerging: agents confidently make the wrong move. The response has been "skill issue," "write better prompts," "add more context," "make a plan first." But not everyone wants to master prompt engineering or maintain context files just to get an agent to understand them.

The missing layer is Intent. Unlike context, intent is ambiguous, implicit, and dynamic. Users don’t always know what they want upfront, and they change their minds once they see options. Forcing that complexity into a one-way text prompt is brittle by design and leads to "context rot."

This talk introduces intent engineering: designing agent workflows that don’t require perfect prompts or perfect context, but instead discover, confirm, and align user intent over time.

Using goose, Rizel will show how MCP Elicitation, MCP Sampling, and MCP Apps let agents ask what you mean, reason about what you might mean, and show you what they think you mean before acting.

Together, these patterns move us beyond mono-directional prompts and toward genuine collaboration.

Model Context Protocol servers are increasingly granted access to critical infrastructure from observability systems and databases to code repositories. This access introduces new supply chain security challenges for teams operating MCP servers in real-world environments.

In this talk, we share lessons learned from Chainguard’s experience building MCP infrastructure for production. Starting with mcp-grafana, our first hardened MCP server, we reduced known CVEs to 0 at publish time while shrinking image size by 65%. We developed repeatable security patterns for MCP delivery, including automated rebuilds, attack surface minimization, SBOM generation, and SLSA provenance.

We then applied these same patterns to a different use case: a documentation MCP serving over 1,500 container image guides, enabling secure access through AI assistants. These implementations demonstrate how consistent supply chain controls can support both infrastructure-integrated and content-focused MCP servers.

Attendees will learn practical approaches to threat modeling MCP servers. We’ll also share our challenges and failures, along with open-source workflows the community can adopt across the MCP ecosystem.

Here's what's going to happen: MCP takes off. Hundreds of MCP servers get built. Most of them end up unmaintained within two years and then issues pile up, PRs go stale, the original author moves on.

I have spent time digging through MCPZoo, a dataset of 56,000+ MCP servers, and the warning signs are already there. Repos with READMEs that just say "install and run." Projects with one contributor and no activity in months. Issues sitting unanswered. The ecosystem is growing fast, but a lot of what's being built has "abandoned in 6 months" written all over it.

I'm sure some of you have tried contributing to these projects. Couldn't run the tests. Couldn't understand the structure. Couldn't tell if anyone was still around. That friction isn't just annoying, it's why maintainers burn out and contributors disappear.

In this talk, I'll break down what makes an MCP server thrive or die. Projects die when newcomers can't onboard, can't run tests, can't understand the structure. The ones that survive do specific things: working CI from day one, a README that gets someone running in under 5 minutes, clear contributor guidelines. I'll show you how to set up your own projects to last.