AGNTCon + MCPCon Japan 2026

Most MCP servers in production today are stateful- each client session is pinned to one server instance.

That works on a single node. Add a load balancer and scale horizontally, and sessions start breaking: Kubernetes routes a request to the wrong pod, a Fargate deployment rolls and drops active connections, and NGINX or AWS ALB need special configuration just to keep the server reachable.

The 2026 spec release candidate, locked May 21, fixes this at the transport layer through three SEPs.
- SEP-1442 removes the mandatory init handshake so negotiation folds into the first request.
- SEP-2322 makes elicitation stateless.
- SEP-2243 mirrors routing data into HTTP headers so load balancers can route without parsing the payload.

This session covers what each SEP changes, what breaks in the server you run today, and what to refactor before the spec ships. I'll also show how we externalize session state at Mem0, so a stateless server keeps the memory and context a real agent needs.

You'll leave with a migration checklist and an architecture for stateless-first MCP.

Authorization in MCP has been through a number of revisions in the past year. Some major (remember when the authorization server and resource server were expected to be the same?) and some minor. As the specification has stabilized, it can be difficult to know: Am I doing it right?

In this talk we'll briefly recap where MCP Auth came from and where it is now, and then we'll dig into Auth best practices based on evolving discussions and connecting Claude.ai to loads of MCP servers in practice.

We'll cover things like: client registration, progressive authz with challenges, and enterprise managed auth to leverage existing SSO connections.

We'll also explore the latest extensions in development and how to put them together into a cohesive solution for human-in-the-loop but also agentic and on-behalf-of flows.

Lastly, we'll cover how to leverage MCP's conformance testing suite to see how closely you're following best practices, using either client, server or authorization server test suites.

The MCP 2026-07-28 release candidate introduces a major shift in how agents connect, authenticate and manage state. With a stateless protocol core, first-class extensions and hardened authorization, the new spec improves scalability and interoperability, but it also changes the security model in ways that many builders may not fully anticipate. In this talk, I will examine the release candidate through a defender’s lens and highlight the practical risks that emerge when session state disappears, trust boundaries move and extension-based flexibility expands the attack surface. I will discuss failure modes such as broken state assumptions, capability confusion, unsafe cross-client behavior, and authorization mistakes in real deployments. The session will also cover concrete hardening patterns for secure MCP adoption, including least-privilege tool design, explicit state handling, authorization scoping, telemetry and rollout validation. Attendees will leave with a practical checklist for evaluating stateless MCP systems and defending agent runtimes in production.

The first wave of MCP adoption was defined by abundance. Every API endpoint became a tool, every workflow became a collection of tool calls, and many servers exposed hundreds of operations directly to agents. It worked, but at a cost: bloated context windows, slower tool selection, and increasingly unreliable agent behaviour.

But then Code Mode appeared!

With approaches Code Mode agents can search an API surface, generate code, and interact with services directly. If models can consume entire APIs and write code to acomplish a task, does tool design still matter?

In this talk, we'll compare three approaches to agent tooling: curated workflow-oriented tools, tool discovery and search, and Code Mode's search-and-execute model. Using real-world examples, benchmarks, and evals, we'll explore the trade-offs in reliability, latency, token usage, and task success.

Attendees will leave with a practical framework for deciding when to consolidate tools, when to expose APIs, and whether the future of MCP is better tools or fewer tools altogether.

Debugging eats 42% of developer time — $300B lost globally every year. On an average, fixing an issue takes 15 days. Debug Assist does it in 30 minutes — issue alert to validated, reviewable PR.

Most AI debugging tools stop at root cause analysis. Debug Assist goes much further: it writes a fix, validates it in a loop till correct, and creates the PR. Example, It caught a crash at 5% rollout, landed the fix the same day — preventing it from reaching thousands of users. Built on LangGraph with 11 MCP servers, 5 plugins, and parallel subagents: Sourcegraph for code search, crash analytics, Jira, feature flags, Jaeger, and logging — all one protocol.

Debug Assist even works on user-reported bugs which have minimal information attached. A user complained of battery drain, and Debug Assist traced it to a hot-looping code path, producing an RCA from behavioral evidence alone.
Domain knowledge lives in markdown skill files in a plugin marketplace — any developer can contribute fix patterns with no code, no redeployment.

We'll share how we built this from ground up, scaled to 5,000 RCAs/month across 6 languages, the challenges we hit, and how we improved the acceptance rate from 5% to 30%

What happens when an AI agent has to pay for its tools? Today, nobody knows. Open-source MCP servers run for free, and their maintainers quietly absorb the cost. The x402 protocol changes the model: a server can charge a small payment for each tool call, with no accounts or API keys needed. The plumbing works. The open question is how agents behave once tools have a price.

We put it to the test. We ran a paid MCP server for several weeks and watched agents act as customers. We changed prices to find the point where agents stop calling a tool. We offered the same tool free and paid, side by side, to see whether agents compare prices or just call the first match. We let spending budgets run out mid-task to see what agents do when money gets tight. And we compared all of this across four agent clients: Google ADK, LangGraph, the OpenAI Agents SDK, and Claude Code.

The result is practical guidance for maintainers: what to charge, where the payment flow breaks, which framework behaviors to expect, and whether per-call payments can realistically fund an open-source MCP server.

MCP UI lets servers return interactive application surfaces instead of plain tool results. But it raises a new question: what happens when the interface inside that surface is generated at runtime by the agent?

This talk shares lessons from building a Generative UI layer within MCP UI. MCP UI provides the app/resource boundary and host communication model, while frameworks like OpenUI provide the generated interface inside that boundary: a component registry, model-friendly UI language, streaming validation, form state, and explicit actions that route back to MCP tools.

The key shift is that MCP UI does not have to mean one fixed widget per tool result. A server can expose capabilities and context, the agent can generate the right interface for the task, and the host can still control rendering, permissions, actions, and observability.

The demo uses a data-dashboard workflow: an agent connects to a datasource, inspects data, generates an interactive dashboard with filters and drilldowns, then turns the result into persistent artifacts such as reports, documents, or slide decks.

The MCP spec is clear about how one client and one server talk to each other. It says much less about what happens when the client is itself a distributed system, serving millions of people across thousands of third-party MCP remote servers.

At Anthropic, we run a proxy between our products and a large, growing set of remote servers. At that scale, we started running into problems the spec doesn't answer.

This talk is about three of them:

- Authentication: How do we make authentication work across servers that all implement it a little differently? How do we keep people connected when connections drop and credentials expire, without making them sign in again?

- Caching: How do we avoid hammering the MCP remote servers, and which caching strategies make that possible?

- Monitoring: How do we monitor a system where the servers vary widely, from stable production ones to unstable ones still in development? When something breaks, how do we tell whether the fault is ours or the server's?

A web service exposes /health; a phone line exposes nothing. The telephone is the oldest telecommunication tool still in production — and our LLM voice agents answer customer calls over it, with no way to know whether they are answering, hearing, and behaving correctly right now.

So we gave a frontier model a telephone.

Our MCP server gives any LLM a phone: dial PSTN numbers, speak via TTS, and read the other side via silence-detected transcripts. A frontier model becomes the caller, phoning our production voice agents in an agent-calls-agent loop — one mechanism covering the whole testing spectrum: ping-style health checks, deep evaluation via scripted and adversarial conversations, and load testing with concurrent caller fleets.

We cover the MCP tool design for a domain the spec wasn't written for — tools that block for tens of seconds, turn-taking over live audio, per-call session state — where the spec fought us and what we would feed back, plus what broke: timeout cascades and evaluations that flap.

We are open-sourcing the server. You'll leave knowing how to connect your own agent to the PSTN — and how to ping, probe, and load-test anything that answers a phone.