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.

___________________________
Presentation Language: English

___________________________
Presentation Language: English
Captioning will be available for attendees in 50+ languages through Wordly. See instructions in each room to utilize captioning.

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.

___________________________
Presentation Language: English

Captioning will be available for attendees in 50+ languages through Wordly. See instructions in each room to utilize captioning.

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 built a paid MCP server on Cloud and ran it end to end, live, settling real payments on a public testnet. We put the agent behind an identity provider and a policy gateway, to see what a paid tool call has to carry before anyone would run one in production. We gave the same work to two competing vendors to see who really decides which one gets bought. And we varied the system prompt, to see how much of a model's spending behaviour is a property of its instructions rather than of the request.

The result is practical guidance for maintainers: how to price a call, where the payment flow breaks, which model behaviours to expect, and whether per-call payments can realistically fund an open-source MCP server.

___________________________
Presentation Language: English

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.

___________________________
Presentation Language: English

In the 2026-07-28 MCP spec, Tasks graduated from an experimental core feature to a full extension, and the redesign reflects hard lessons from production use. For teams building agentic systems, this isn't a minor API tweak. It changes how long-running work, the kind agents constantly trigger (data pipelines, multi-step workflows, async approvals) gets modeled, tracked, and scaled across a stateless protocol.

This session is a field report on what it takes to build agentic systems around the new Tasks lifecycle.

We'll cover:

1. Why Tasks moved from core to an extension, and what that signals about MCP's evolution philosophy
2. The new server-directed task model: how a tools/call returns a task handle, and the client drives it via tasks/get, tasks/update, and tasks/cancel
3. Why tasks/list was removed entirely, and what that means for how agents discover and track in-flight work
4. Patterns for orchestrating dozens or hundreds of concurrent tasks across a fleet of agents without sessions to lean on
5. Migration lessons from the experimental 2025-11-25 Tasks API, including what broke and how we handled the transition without downtime.

___________________________
Presentation Language: English

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?

___________________________
Presentation Language: English

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.

___________________________
Presentation Language: Japanese