Schedule

MCP arrived when connecting data and applications to AI systems required bespoke implementations and a fragmented ecosystem of plugins, desktop applications, and makeshift proxies. Since its release in late 2024, a tectonic shift has occurred, and server by server, client by client, the protocol became the de-facto substrate for agents to access anything – every tool call, resource access, or asynchronous task can now be managed through one standard, with an established collection of cross-platform SDKs, avoiding the need to rebuild everything from scratch for every LLM vendor. In this session, we will examine the driving forces that made it all happen.

Let us show you what a full enterprise MCP practice looks like end to end, built at TELUS over the past year.

The tour: IRIS, an n8n-based AI operations agent exposed as an MCP server — with a Slackbot front end — that routes real operational requests; n8n workflows that call MCP tools to automate the boring parts of running a platform; a shared "ai-dev" registry that catalogs the MCPs most useful across the org, so teams discover and reuse instead of rebuilding the same connector multiple times; and finally remote MCP hosting on Gizmos, our last-mile platform built on Cloudflare Workers — plus the OAuth wall every enterprise slams into. Dynamic Client Registration is the usual answer, and the usual disappointment; we'll cover why we went with Client ID Metadata Documents instead, and the tradeoffs behind that call. No product pitch — reusable patterns for any stack.

You'll leave with a map of the whole enterprise MCP stack — registry, workflow automation, agent front ends, remote hosting — the failure modes we hit, and where the spec and tooling are still rough.

What happens between a user typing "Show me AR aging by customer" and a fully interactive dashboard appearing on screen? This talk pulls back the curtain on a production agentic system that turns natural language into deployed dashboards — complete with KPIs, charts, and filterable tables — powered by live enterprise data.

At the core is a ReAct agent loop that reasons about data needs, discovers available tools at runtime, and iterates through up to 10 cycles of thought-action-observation to produce a structured DashboardSpec. The agent connects to enterprise ERP data through MCP (Model Context Protocol) servers, an open protocol for dynamic tool discovery across multiple transports (SSE and Streamable HTTP), with a Redis caching layer that cuts repeated query latency by 50x.

The architecture is built on portable, open technologies: LangGraph for agent orchestration, FastAPI for the service layer, and Strawberry GraphQL for the subscription API. This is a live demo talk. You'll watch the system handle ambiguous prompts, recover from MCP server failures, and validate outputs through structured tool schemas.

On July 28, the MCP spec removed server-side sessions entirely. If you maintain an MCP server, this probably already broke something for you (or it will when your users update their clients).

I spent three weeks going through the 2026-07-28 spec diff line by line and mapping every change against the tool handler patterns in 100+ MCP servers I'd already audited with MCPeek. The short version: SSE streaming is gone (replaced by Streamable HTTP, which handles long-running tool calls differently), servers can no longer hold conversation context between requests, and OAuth token binding without session affinity is genuinely harder than the spec changelog makes it sound. That last one is the thing I see nobody talking about yet.

This talk is the migration guide I had to write for myself. Each breaking change comes with the code diff in both the TypeScript and Python SDKs and the migration path I'd recommend.

MCP servers are proliferating, but the infrastructure to deploy, discover, and route to them on Kubernetes remains fragmented especially for enterprise AI platforms where multiple teams need self-service access to curated tools, governed by policy and isolated by tenant.
This talk presents three building blocks that together form a complete MCP server lifecycle on Kubernetes, drawn from our experience building a multi-tenant MCP ecosystem on an enterprise AI platform.
Lifecycle: A declarative CRD for MCP servers giving platform teams a single resource to manage deployment, health validation, and safe rollouts

Gateway: Approaches to tool aggregation, JSON-RPC-aware routing, and auth enforcement between clients and upstream servers.

Catalog: Patterns for making servers discoverable, from lightweight Kubernetes-native approaches to dedicated registries and how catalogs feed into both lifecycle and gateway.
Integration: The hardest problems live at the boundaries. We'll ground these in lessons from wiring these components together across multiple tenants and personas, sharing patterns that worked, friction points that didn't, and what the ecosystem needs to standardize next.

Most MCP demos stop at hello world. Then you try to wrap a real system at work and hit everything the tutorials skip: authentication, secret handling, deciding which actions an agent may take, and what happens when a tool call fails.
This session closes that gap. Starting from an empty editor, I'll build an MCP server live with FastMCP in Python, wrapping a small FastAPI service that stands in for an internal company API, then harden it into something you'd actually deploy. We'll cover authenticating the server, keeping secrets out of the model's reach, scoping dangerous actions so an agent can read without being able to delete, and handling failures so one broken call doesn't derail the agent. We'll test it live with MCP Inspector.
You'll leave with a clear mental model and a practical checklist for exposing your own systems to agents over MCP. The patterns are shown in Python with FastMCP and portable to any official MCP SDK.

MCP became the default way enterprise agents reach tools and data in barely a year. Will it last?

For a Linux Foundation Research and Agentic AI Foundation study, we interviewed 22 leaders building and running agentic systems: open source contributors and enterprise operators in regulated industries across the globe.Almost all of them use MCP. Few agree on its future.

Some think better models and skills will make it less necessary, and one retail Head of AI told us it might disappear altogether. They agreed more on what MCP doesn't cover: agent-to-agent communication, identity, and discovery, the layers that decide whether agents from different vendors can work together.

Two patterns came up again and again: 1) A gateway sitting between agents and models for governance and cost control, and 2) guardrails enforced below the model rather than through prompts, since a model can't police the same channel used to hijack it. The recurring point: trust, not capability, is what separates a demo from something a company will actually run in production. I'll walk through what our findings mean for where developers should spend their effort.

We deployed an MCP agent to investigate seller support issues across 8 AWS accounts. In its first month: 20,000+ tool invocations, investigation time reduced from 10 minutes to 30 seconds. Then a single input validation regex in our tool pipeline silently zeroed inventory for 70+ sellers — a Sev-2 incident caused by the system designed to protect them.

This talk covers three production failure patterns unique to multi-tool MCP architectures: (1) Validation boundary mismatches – when tool-level schemas disagree with upstream data formats, creating silent data corruption. (2) Credential scoping in multi-account routing – how we handle 8 AWS accounts with one agent session without cross-tenant leakage. (3) Observability gaps at the transport layer – why our agent's reasoning traces missed the failure (it happened in API Gateway VTL, outside the MCP tool boundary) and the anomaly detection patterns we now enforce.

Built with MCP's open protocol, running against Bedrock. No vendor pitch – just patterns, anti-patterns, and the three rules we'd enforce from day one if we started over.

Most MCP authors have figured out that one-tool-per-endpoint is a dead end. The smart ones now compress dozens of endpoints into a handful of well-designed tools. That's real progress.

But the bloat just moved up a level. If your agent needs to do real work, it ends up loading five, ten, twenty MCP servers – and the tool list is bloated again, one floor up.

The way out is one MCP that can reach anything. I'll show how: a single server backed by search + execute over an embedded OpenAPI spec, with Keycard handling identity end-to-end. Because the upstream APIs are already protected by Keycard, the auto-generated MCP can safely reach all of them – RFC 8693 token exchange, per-operation scopes pulled straight from the spec, Cedar policies for who's allowed what. Zero upstream secrets on the server.

The first call is a bit slow – the agent has to search the spec and figure out the shape. But the MCP ships with a skill, so the agent learns how to call it once, then every call after skips the discovery and goes straight to execute. Over a session it gets faster, not slower.

One MCP. Any API. Real identity. Skills that compound.

Modern AI agents can act through many execution surfaces: MCP servers, direct APIs, CLIs, and browser automation. The same workflow can often be accomplished through any of them – but the interface you choose determines how safe, reliable, observable, and governable the agent will be.

This session proposes a practical decision framework for selecting the right interface based on structure, least privilege, auditability, failure modes, and blast radius. We compare MCP, APIs, CLIs, and browser-driving across real production concerns: permissions, policy enforcement, idempotency, retries, logging, secrets exposure, UI brittleness, and operational risk.

The core principle: use the most structured, narrowest interface that can complete the task – purpose-built tools and APIs first, MCP as a reusable integration layer, constrained CLI for developer workflows, and browser automation as a last resort. Attendees leave with a clear rubric and patterns for hybrid architectures that combine MCP discovery with safe write paths and human approval where needed.

My MCP server had green CI. Every unit test passing, every integration test passing. Then I watched an agent use it, grab the wrong tool, garble the parameters, and spend forty thousand tokens on something that should have cost three. My suite never flagged it, because it was testing my code. But the thing using the server isn't me, it's a model, and the model was never in the room when I wrote those tests.
So now I let the evals drive. Before I lock in a tool, I write the eval first: what the user asks, the call I expect back, the result I want, and the token budget. The eval and the tool grow up together, so when a name is vague or a description is mushy, the eval catches it long before code review.
Once you have a real eval suite, swapping models stops being risky too. A new model ships, you run the suite, and you know whether your server still works instead of guessing.
That's what I want to walk through: an MCP server and an eval framework, how to run these on a PR without the cost getting out of hand, why the same server behaves differently depending on the model, and why tokens-per-task should fail a merge the same way a broken test does.

MCP is designed for composition, but composition creates a security gap: individually permitted calls can together violate user intent, amplify authority, or move sensitive data to an untrusted server. This session presents a vendor-neutral, zero-trust verification method for composed MCP systems. It complements MCP authorization by checking not just each call but the entire end-to-end plan.

Using a three-server example, I will show how to represent delegated identity, capabilities, policy snapshots, data provenance, side effects, and evidence. We will test global invariants: authority never grows across hops; capability is not permission; tokens are audience-bound; restricted data cannot reach an unapproved sink; every effect has a prior decision; retries and partial failures remain safe; and the run is replayable.

An intelligent layer generates adversarial compositions and prioritizes risky paths, while deterministic policy and evidence checks remain the root of trust. Attendees leave with compositional questions, a zero-trust test matrix, and a conformance workflow for MCP hosts, clients, gateways, and servers.

Drawing on experience building plugin submissions at OpenAI, this talk builds on how we can use extensions to build interactive UI that gives users a reason to use your plugin again & again in ChatGPT and Codex.

While the Model Context Protocol (MCP) has seen strong enthusiasm and rapid iteration in the developer community, translating that success into broader industry adoption, particularly among small and medium enterprises, remains a major challenge.

Many SMEs run AI agents locally to keep sensitive data on premises. These deployments typically use mid-sized open-weight models in the 8B to 32B parameter range. In practice, tool calling and MCP performance degrade sharply for these models under realistic contextual overload.

In this session we present a systematic benchmarking study of tool calling and MCP behavior across multiple models. We evaluate performance on two benchmarks: τ²-bench and CEO-Bench.

A key finding is that introducing standardized MCP OAuth and RBAC alone improves task completion accuracy by over 60%. We also demonstrate how combining MCP with skill and routing LLMs, together with targeted context engineering techniques such as context cleaning and context mutation, significantly boosts overall reliability, reduces tool-use errors in multi-turn scenarios, and markedly improves interpretability.

Chopping municipal regulations (or other highly structured content) into flat chunks for RAG just gives you a fancier search engine, no matter how many dimensions the embeddings have. But regulations carry meaning in their structure and cross-reference: a subsection means nothing without its parent, the definitions it leans on, the sections that reference it, and who enforces it.

We'll walk through our development of an MCP server that helps AI agents navigate a large U.S. city's regulations through a property graph. We modeled the corpus with several different kinds of node and edge types to map hierarchy, entities, entities, authorities, and more. What makes the graph useful for an agent are intent-specific tools: resolving a citation, finding similar entities, showing areas of accountability, and so on.

We'll be honest about how entity extraction and community-building really went; what worked and what very much didn't. We'll share lessons for anyone exposing graph data via MCP, and demonstrate queries that plain RAG gets wrong and the graph gets right.

Single-agent systems struggle when asked to plan, execute, and interface across diverse enterprise tools. Join this hands-on workshop to build AI Creative Studio, a production-grade multi-agent platform powered by Google ADK, Model Context Protocol (MCP), and the open Agent-to-Agent (A2A) protocol . You will implement five specialized agents—from a multimodal Designer generating visual assets to a Project Manager syncing tasks via an MCP server with dynamic schema discovery. You will package these agents as independent microservices, connect them to an orchestrator over A2A, and observe the live protocol handshakes using the A2A Inspector. Leave with a concrete understanding of where MCP ends and A2A begins, and how to scale distributed agent architectures to production

Join us for a deep dive into the evolution of the Model Context Protocol (MCP) as we explore the shift from stateful, session-heavy architectures to stateless, cloud-native deployments.
In this session, we will examine how the latest updates to the MCP specification introduce a stateless HTTP foundation, enabling MCP servers to function as lightweight, independent microservices. We’ll discuss the operational advantages of this paradigm shift, including simplified load balancing and the ability to scale down to zero when traffic stops.
Additionally, we will demonstrate how combining this stateless architecture with cloud-native Java—specifically using Quarkus—creates the ultimate stack for high-density AI infrastructure. You’ll learn how to leverage Ahead-of-Time (AOT) compilation and reactive routing to build highly specialized, memory-efficient MCP tools that start instantly. Whether you are building database-lookup tools or internal API proxies, you'll walk away with the knowledge to design predictable, scalable, and reliable AI systems for enterprise production environments.

The MCP spec defines a tool's description as nothing more than "human-readable description of functionality." That's it. It's free text, and the model reads all of it. Annotations get an explicit warning to treat as untrusted; description doesn't – it happens to be exactly the field tool poisoning attacks target, hiding instructions in that text for an agent to follow with no sanitization or provenance check.

At WRITER, we ended up solving this the same way we solved a completely unrelated problem: bad descriptions hurting tool selection. Both come down to running an LLM over the whole catalog in batches, not one call per tool, so checking most of it stays cheap. When a batch flags something, we go back and check each tool in it individually. One classifier scores descriptions and pulls in live web search to rewrite the weak ones. The other flags likely poisoning.

Batching creates its own attack surface: a bad description can go after the batch prompt itself. Newlines forging fake catalog entries. Padding to blow past a fixed character budget. I'll walk through those failure modes, the fail-open vs fail-closed call we made, and where detection stops and enforcement takes over.

Building one agent is easy. Building agents that stay reliable as they grow in number, capability, and complexity is the hard part — and where most teams hit a wall.

This talk is a practical tour of agent architecture and orchestration from the trenches of shipping production agents. We’ll cover the decisions that actually matter: when to use a single agent versus orchestrating several, how to route work and manage context across steps, how to handle tool selection and failure gracefully, and how to keep the whole system observable and debuggable.

MCP runs through all of it as the integration backbone — the layer that lets agents discover and use capabilities consistently. I’ll share how treating MCP servers as reusable, well-bounded building blocks keeps an entire agent fleet maintainable, and how orchestration patterns change once your capabilities are standardized behind MCP.

You’ll leave with concrete architecture patterns, orchestration trade-offs, and MCP design choices you can apply immediately. Aimed at engineers already building agents who want to move from working prototypes to systems that hold up in production.

The MCP spec recommends servers not to reinvent the access control wheel. Now the question is: what OSS building block will emerge as the access control foundation of choice for the MCP ecosystem, to avoid fragmentation?

The CNCF project Cedar Policy offers a declarative language and engine for attribute-, relation- and role-based access control policies, making it easier to audit, version, reason about and share policies across applications. ToolHive recognized Cedar's utility and uses it to enforce consistent access control across MCP servers.

Cedar is grounded in mathematical logic, which means you can analyze, compare, and query policies themselves, not just evaluate them. Did your refactored policies change any decisions? Is an allow policy actually dead code, always overridden by a stronger deny? Who can access this resource? What can this agent do in the system? Could an AI agent exfiltrate private data to an external sink? These questions Cedar can answer statically and always correctly (unlike LLMs), across all your policies.

After this talk, the audience knows how Cedar could be used to promote ecosystem-wide consistency, and how ToolHive already uses it in production.

Building an MCP server is getting easier. Monetizing one is not.

At first, usage-based billing looks simple: count tool calls, aggregate them monthly, and send an invoice. But once MCP servers move into production agent workflows, the definition of “usage” becomes much harder. Was that one tool call or ten? Should you bill for tokens, API calls, records retrieved, compute time, successful outcomes, or prepaid credits consumed? What happens when an agent retries, chains tools, streams results, or calls the same resource through multiple clients?

In this session, we’ll dive into the infrastructure behind trustworthy metering and pricing for MCP-native products. We’ll cover how to design a billing pipeline that can:

Count usage once and only once, even with retries, failures, and agent loops
Handle high-volume event streams from MCP tool calls
Give customers real-time visibility into current-period usage
Support pay-as-you-go, prepaid credits, drawdown models, and hybrid pricing
Preserve developer trust by making usage explainable and auditable

MCP standardizes how agents reach tools, but it does not solve what those agents should remember, how that memory is queried, or how teams debug cross-tool behavior after a run.

This talk proposes a practical memory architecture for MCP-based agents: model tool calls, resources, prompts, embeddings, user feedback, and outcomes as local analytical data; query it in-process; and promote only the right context back into the model. We will walk through design patterns for session history, semantic retrieval, eval loops, and auditability without turning every agent into a distributed system.

Attendees will leave with a concrete blueprint for building MCP servers and clients that can remember safely, explain what happened, and improve over time.

OpenClaw’s first-party MCP bridge only supports stdio, so hosted clients such as ChatGPT and Claude cannot connect to it. Making it available over Streamable HTTP solves the transport problem, but raises a harder question: how do you preserve authenticated user identity all the way into OpenClaw?

This talk shows how OpenClaw’s trusted-proxy authentication mode, https://docs.openclaw.ai/gateway/trusted-proxy-auth, a Gateway feature I implemented upstream, can bridge that gap. An identity-aware proxy handles the MCP OAuth flow, evaluates access policy, and rejects unauthorized requests before they reach the bridge. The bridge then carries the authenticated identity into OpenClaw through trusted-proxy auth mode, instead of bypassing authentication or falling back to a shared token.

I will live-demo the full flow using Pomerium, an open core identity-aware proxy: hosted MCP client, OAuth and policy enforcement, Streamable HTTP bridge, and an unmodified OpenClaw Gateway. Attendees will leave with an open source blueprint for securely exposing a self-hosted assistant as a remote MCP server.

"Give me 20 minutes and I'll explain why investing in MCP is existential."

What happens when an open source developer turned tech educator to millions around the world is pulled out of their teaching job and dropped into an enterprise engineering team to help them build and ship an MCP App to millions of users?

Meticulously Controlled Pandemonium is what.

And what does a tech educator do when they learn something new? They share it with the world, even when the "it" they share are the kind of things the enterprise rarely allows anyone to talk about.

In this talk you'll learn:
– Why the Misunderstanding of MCP is a bigger barrier than anyone seems to realize
– How AI coding tools transform the product development process and upend the power structures of engineering-driven companies
– What the possibility space opened by MCP has to offer (and why it remains largely unexplored)
– How to develop a healthy disrespect for the sanctity of technology!

But most importantly: How to build the future we want with MCP and coding agents.

Enterprise adoption of the Model Context Protocol is accelerating, and MCP has become the primary way agents connect to enterprise tools and data. But MCP is only part of how agents act. Agents also run CLIs, execute Skills, and generate code that calls APIs directly. Governing MCP well matters. Governing everything else agents can do matters just as much.

Building MCP servers and writing Skills isn’t particularly hard. The real challenges are deciding which actions agents are allowed to take, controlling who can take them, and proving it all later. These are architectural questions, and they need answers before agents scale across an organization.

In this workshop, we will:

1. Show how to control agent actions with policies that apply across MCP servers, CLIs, Skills, and agent-generated code, including allowlists, access control by users and groups, and human-in-the-loop approvals.
2. Explain why enterprises need managed registries for MCP servers and Skills, and how admin review and approval change the trust model.
3. Work through audit and compliance requirements: capturing complete logs of agent and tool activity, exporting to enterprise storage, and generating reports.
4. Demonstrate how to discover shadow AI, including unmanaged agents, MCPs, and Skills already running in your organization, and how to block them or bring them under management.
5. Look at token usage and spend visibility by agent, user, and group.

You’ll leave with a clear picture of the architectural decisions ahead of you, and a better sense of what your security team will require before signing off on scaling AI agents across your organization.

When you build MCP servers you must've noticed your agent makes more tool calls than it should or gets stuck halfway "even" when you gave it every tool it needs. The problem is not the server, it's the way we design it. Most of us build MCP servers like we build APIs: expose endpoints as tools and let the agent figure out the rest. Exactly the "figuring out" part is the problem.

We're handing agents too many planning responsibility instead of giving them exact intent. We'll test the idea by building same workflow in 2 different ways and you will see see how a simple chnange in our design made one process leading to unnecessary planning or tool calls while other is more effortless .

You'll leave knowing how to design from the agent's perspective instead of the developer's so next time you're deciding what tools to expose and how much abstraction your server needs, the answer is obvious instead of a guess. And hopefully you can make your agent's life easier (work smarter, not harder!!!) 🙂

MCP standardizes how an AI application discovers and calls tools, but it does not decide how a multi-step job should be planned, remembered, retried, or recovered.

This session builds a small incident-response agent that uses three MCP servers: observability to inspect alerts and logs, Kubernetes to examine a failed deployment, and GitHub to retrieve the change that caused it. We will follow one workflow from alert to diagnosis to an approved rollback, showing where orchestration must sit outside the protocol.

The session will cover tool routing, compact state, deterministic checkpoints, retry policies, idempotency, timeout handling, and recovery when one server returns incomplete data or disappears. Attendees will see why a single unconstrained agent loop becomes unreliable and how a thin workflow layer can keep MCP-based systems understandable, testable, and resumable without turning the design into a maze of agents.

MCP authorization is specified for a simple pair: one client, one server, one token. Production deployments are chains: an agent fanning out across five MCP servers, three identity providers, and a user whose consent was granted once, far upstream. Somewhere along that chain, acting on behalf of the user degrades into acting with a shared, over-privileged credential.

This talk follows a single user request end to end, through host, gateway, and multiple MCP servers, examining each hop as a point where identity context is propagated, narrowed, dropped, or silently replaced. We cover the mechanics of propagation: token exchange, audience restriction, and credential brokering across identity providers. These controls do not scale when embedded in every server. Drawing on lessons from building an AI gateway, we show how a gateway layer becomes the natural enforcement point: exchanging and downscoping tokens, brokering credentials, and producing audit trails that separate user intent from agent action.

Attendees will leave with a decision framework for delegation vs. impersonation at each hop, and patterns for preserving user identity end to end.

Most MCP servers are built on top of a richer underlying type system — GraphQL, OpenAPI, protobuf, a database schema — but the hand-off into JSON Schema usually gets treated like a mechanical detail. It really isn't. How well that translation preserves meaning is what determines whether an agent can call your tool correctly on the first try, and the failure modes are sneaky: the schema validates, the tool registers, and the agent quietly guesses at semantics the original type system encoded but JSON Schema can't express.
This talk gives the MCP ecosystem some shared vocabulary around that problem, plus a live demo to make it concrete. We'll use GraphQL → JSON Schema as the case study and walk through what happens to custom scalars, enums, nullability, and precision inside the Apollo MCP Server. The demo shows the same prompt failing on an unmapped custom scalar, then succeeding once a mapping file fills the semantic gap. The takeaways generalize: anyone building an MCP server on top of a typed API hits the same class of problem, and the same patterns apply — explicit type mappings, auditing where translation is lossy, schema annotations as agent guidance.

This session shows how to carry caller identity all the way to your MCP tool. Using Teleport OSS Core, to attach a short-lived JWT to each MCP request. AgentCore validates the token at the edge via OIDC/JWKS, then a lightweight REQUEST interceptor forwards trusted identity claims (user, roles) into the tool invocation. From there you can enforce per-tool rules (including Cedar policies via Amazon Verified Permissions) before any sensitive action runs.

The payoff is auditability: every tool call is tied back to a real user, with a clear chain across Teleport session logs, policy decisions, and the resulting AWS activity. We close with a live demo end-to-end on Lambda.

MCP is part of the beating heart of technology that powers AI-Q and NVIDIA’s broader agent tooling. This session covers the history, evolution, and operational patterns that we’ve found work “in prod”. We’ll cover authorization and tool filtering, multi-user deployments, guardrails, and how the evolving spec has interacted with building dope technology. You’ll leave knowing which patterns we’ve found crush it.

"How many users do we need to support on MCP?" "Possibly all of them. Maybe 750,000." That was the start of a conversation about deploying MCP at a scale matching frontier SaaS services. Our demo was amazing — one minute, one agent, one tool, MCP in between. Then came the real engineering. Nobody had really said yes to any of it. There was also nowhere to say no.
That exposed us to the world this session covers: a registry as the source of truth for which servers exist, who owns them, and what an agent may discover. A gateway as the single path between agents and tool… identity, authorization, rate limiting, and policy enforced once instead of rebuilt per server. An AI gateway as the governed route to inference. Then the rollout: phased, control plane in GitOps, admission control so an unsanctioned server can't land, runtime detection on the tool-execution surface, and workload identity so the gateway knows which agent is calling.
We close on what the gateway caught, what slipped past us, how we handled scale and security, and everything on the road to 200,000 deployed internal users at a single company. We counted. The number was horrifying.

It's tempting to point your coding agent at your REST API, have it port every endpoint, and ship it. Don't. Tools that mirror your API one-to-one make agents slower, more expensive, and likelier to do the wrong thing.

We built the MCP server for a connected-worker manufacturing platform, dozens of tools across many domains. Our first pass was a straight port, and it failed badly enough that we built our own skills to fix and vet every new tool. This talk is the craft that came out of that:

• Helping agents find the right tool among dozens through progressive discovery;
• Pruning a tool's twenty parameters down to the handful an agent should reason about;
• Stripping response bloat (signed media URLs alone were 40% of a payload) so it doesn't crowd the context window;
• Guardrails on destructive and unbounded operations, so an agent can't delete an entire factory or pull a million rows;
• Returning errors an agent can recover from, instead of "it failed".

Every point comes from a decision we made, and often remade. You'll leave able to tell a real MCP tool from a wrapped API endpoint, and how to design one that's agent-friendly.

Developer Experience defined the last two decades of platform competition: companies won or lost on time-to-first-API-call, docs quality, and SDK ergonomics. Agent Experience(AX) is the next frontier, and most infrastructure products are not ready.

When your primary user shifts from a human developer to an AI agent, product design assumptions quietly break. Docs optimized for human scanning waste an agent's context window. Error messages written for humans give agents nothing to recover with. API surfaces built for exploration become expensive, ambiguous tool catalogs. And permissioning, a supposed agent problem, is often one your access model already solves.

This talk draws on hands-on evaluations pointing coding agents and MCP clients at real provisioning, scaling, and configuration workflows across major cloud platforms. I will share a practical AX framework: discoverability, context economics, error design as prompt design, idempotency and retries, and evals as the new docs testing. You leave with a checklist for auditing your platform's AX and a clear view of which agentic gaps are real and which are hype.

As agentic systems grow more complex, getting them to communicate efficiently is half the battle. While the Model Context Protocol (MCP) has revolutionized how AI models connect to their data sources, what happens when your agents need to talk to each other?

Enter the Agent2Agent (A2A) protocol. But with multiple tools at our disposal, how do we avoid crossing the streams?

In this session, we’ll break down the specific strengths of MCP and A2A, demonstrating why picking the right protocol for the right task is the secret to optimal agent orchestration. We’ll explore architectural patterns, real-world use cases, and how to seamlessly combine these protocols without forcing a square peg into a round hole. Join us to learn how to build a streamlined, multi-agent ecosystem that actually scales.

Your agent needs eight tools to do its job. So why give it two hundred?

If you have connected your agent to MCP servers, you may have noticed the vast number of tools that become available to it. But what if you could give your agent access to tools from multiple servers, and only the tools it needs for the task?

In this workshop you will learn how to use Agent Router, an Agentic AI Foundation open-source router for agent traffic, for tool aggregation, tool access authorization, and monitoring every tool call.

Three hands-on labs, each ending with your agent making a real tool call through the router.

Bring a laptop and your agent, or use the sample agent I will bring, and let's configure its tools.

When your mum said don't talk to strangers, she meant that last MCP server you installed. It came with good references. And a copy of your keys.

An MCP server runs code you didn't write, with the credentials it needs to act for you. Teams install them from community registries and never stop to treat them as hostile. They should.

I play the attacker. A tool you trust turns on you four ways: stealing your credentials outright, doing more than you authorized, pivoting from one tool to every tool, and riding in on a single poisoned dependency. The usual fixes (environment variables, secrets managers, handing the tool a token) all leave the same door open.

Plenty of talks cover the injection tricks that get an attacker inside. This one follows what they walk out with.

You'll leave with a threat model for the agent tools already in your stack, and criteria to judge any credential-handling approach, so the next tool you install has to earn its access instead of being handed the keys.

Networks are the last mile of AI adoption in operations: high-stakes, stateful, and unforgiving of hallucination. NetClaw is an open source (Python) network engineering agent that puts MCP at the center of how an agent safely reasons about and acts on real infrastructure. Rather than exposing raw device access as a pile of tools, NetClaw structures its capabilities as MCP skills — interface analysis, BGP path-selection explanation, configuration auditing, topology discovery, and documentation generation — built on foundations like pyATS and validated against real gear in Containerlab.

This session walks through the architecture decisions that came out of building and running NetClaw in real lab and edge environments: how structured skills constrain agent behavior compared to raw tool exposure; how spec-driven development keeps an autonomous loop predictable; how the agent detects when it's stuck and recovers safely instead of looping; and how NetClaw instances peer with each other over BGP and GRE to form a self-assembling mesh — something we've demonstrated live across machines on different networks.

This session introduces a pattern I call Model Context Protocol Control Plane (MCP-CP). In this architecture, MCP and the control plane operate together inside a secure agentic enclave: MCP gives agents a standard way to reach tools, while the control plane provides structure, policy, approvals, privacy controls, credential protection, and auditability.

A key design choice is that agents do not need to authenticate directly into MCP through an external IdP, which can add complexity and attack surface. Instead, the control plane spawns or brokers agent sessions inside the enclave and keeps them on the governed path. Agents are issued platform-specific credentials or scoped API keys, but the real secrets remain protected by the control plane. Authentication and authorization are validated before any downstream credential is applied.

Rather than giving agents broad access and trying to secure actions later, MCP-CP places controls directly in the path the agent must use. Using lessons from hosted and self-hosted workflows, including Google Workspace through an open-source MCP server, this talk explores how MCP-CP can support safer enterprise agents.

Many agentic AI demos succeed because they operate within well-defined scenarios and clear boundaries. Enterprise systems become harder when agents must divide work, coordinate decisions, recover from ambiguity, and operate across tools with different trust, latency, and failure profiles. Adding more agents is easy; designing how they work together can be challenging.

Grounded in extensive real-world implementations across multi-agent architectures and MCP-enabled environments, this session distills core orchestration patterns that have consistently shaped reliability, scalability, and control. We will examine what each pattern enables, where it breaks down, and how to choose the right model based on task complexity, coupling, autonomy, and governance.

Through real-world experiences and lessons learned from our implementations, attendees will gain a practical decision framework and tested design principles to move beyond impressive demos toward production-ready, governable, agentic systems.

Model Context Protocol is becoming the critical layer for interoperable AI agents, but moving to production in regulated finance introduces extreme challenges in security, governance, and auditing. We are deploying MCP to power AI agents for financial analysts handling market data, risk assessment, and trade execution. It provides a deep dive into how we built our internal MCP gateway and server registry to solve the "lethal trifecta" of financial enterprise concerns: identity management, data exfiltration prevention, and privilege escalation. We will walk through how we integrated SPDX for governance.

You will learn the "Gateway Registry" pattern pairing a central registry for server discovery with a gateway for unified security controls, plus strategies for integrating OAuth2, role-based permissioning, and threat modeling. We will demonstrate using SPDX SBOM to create for MCP servers, tracking components and licenses to meet financial audit requirements. We will share our experience building on the FastMCP framework and how we tackled "context bloat" using loading to reduce LLM context usage from over twenty percent to near zero, even with dozens of financial data servers.

Building one MCP server teaches you the protocol. Building five teaches you what MCP actually is.

Over the past year I've built and published multiple open-source MCP servers across different domains — cloud infrastructure, developer tooling, AI workflows. Each one taught me something the previous one didn't. This talk is about what I learned across all of them.

We'll get into the patterns that showed up again and again: how tool design evolves as your server grows beyond 3 or 4 tools, what's worth sharing across servers and what isn't, how to write a README that means developers can actually use your server without asking you for help, and the one thing that keeps biting me — discoverability. Where does someone find your MCP server today? Honestly, there's no great answer yet. We'll talk about that too.

All the servers are open source at markusvankempen.github.io — this is a practitioner's talk, not a whiteboard session.

If you're building your second or third MCP server and want to go faster, this one's for you.

Corporate actions at a global custodian is where good data goes to die. Voluntary offers, mandatory reorganizations, dividend elections each one touching dozens of systems, counterparties, and deadlines that don't forgive mistakes. For years, we've duct-taped these workflows together with file drops, manual reconciliation, and a whole lot of hope.
Then MCP walked in.
This session shares what happened when we brought the MCP into the corporate actions lifecycle at a major custodian. Not theory real implementation. You'll see where MCP connected what was previously stitched together by spreadsheets, where it exposed fragility we'd been ignoring, and where it genuinely stopped things from breaking.
We'll cover the integration patterns that worked across legacy custody platforms, the design decisions that mattered in a regulated environment, and the moments where MCP surprised us both good and bad.
If you're an enterprise architect, technologist, or ops leader wondering whether MCP belongs, this talk gives you an practitioner-level answer. Just what we learned walking a new protocol into one of the oldest, most complex corners of capital markets and what stopped breaking when we did.

Your agent connects more MCP servers, and every tool call slows down. Most teams assume the fix is faster protocol handling. We put that assumption on a GPU and measured it, and the result surprised us.

Profiling real agent tool-call chains on an AMD MI300X, we found the MCP data plane (JSON-RPC parsing, schema matching, result injection) is 0.06 percent of wall-clock time.
The chain is inference-bound. GPU-offloading the protocol moved end-to-end latency by 0.003 percent, so we stopped optimizing the protocol.

The real cost is the tool registry itself. At about 204 tokens per tool, 1000 tools burn 204k prefill tokens and blow past the context window. Selection is mandatory, not optional. GPU-resident selection is essentially free and 3x to 6.6x cheaper than a CPU index at 10k tools, with dynamic updates 500x cheaper than a rebuild.

The honest catch: selection speed is solved, but quality is not. With an off-the-shelf embedder, recall on paraphrased queries is low; fine-tuning and two-stage reranking recover it at small registries but not at 10k tools. You leave with a measurement method, an open-source substrate, and a precisely scoped open problem.

In July 2026, MCP shipped its biggest revision since launch: the transport layer went stateless. The initialize handshake and Mcp-Session-Id header are gone — any server instance can handle any request. Great for scaling. But it quietly removed the architectural crutch a lot of identity and audit assumptions were leaning on.

Three practitioners unpack the fallout from three different seats:

Auth flows & policy enforcement — Zach on what changes when there's no session to anchor a trust decision to, and the gateway-vs-agent-runtime tradeoff when every request has to prove itself independently.

Enterprise permissioning & auditability — Lorie on what "prove who did what" means when session-level tracing is gone and state lives in explicit handles — and what that does to the audit trails compliance already promised leadership.

Remote server security & threat models — Joe on the attack surface stateless transport and the Tasks extension open up: who can spawn a task, hold its handle, and drive its lifecycle with no persistent connection to anchor to.

If you're building or securing remote MCP servers, this is the plumbing change that bites first.

You built an MCP server. It has clean code, typed schemas, and great test coverage. However, you don't have a clear signal on how well agents can actually use your MCP server. How can you prove that LLMs actually understand the semantic interface you've built?

In this hands on workshop, we are moving from theory to practice. Attendees will learn how to build automated integration tests specifically designed for the agent-MCP interface using mcpchecker, an open source MCP evaluation framework used in production by MCP servers like the Kubernetes MCP Server.

Bring your own MCP Server (or use our provided reference server). Together, we will step through writing tasks for the agent to accomplish with your server, how to verify that the agent did the correct thing, and assert it used your server efficiently. You will walk out of this session with a working, automated evaluation suite for your own server.

This talk shares what the ML Platform team at Kensho, the AI arm of S&P Global (Fortune 500 firm) learned from multiple teams building and operating MCP across the company.

The Good: MCP delivers on its core promise. The protocol's simplicity makes it remarkably easy to expose data and capabilities to third-party agentic applications through a single standard. Industry adoption was very quick and high, which in turn makes engineering integration easy.

The Bad: Building on a moving spec has real costs. We'll cover shipping against shifting standards, an auth story that took multiple iterations, discoverability gaps, and why granular observability deserves higher priority on the roadmap.

The Ugly: Not all MCP servers are created equal. We'll share cautionary tales: teams blindly wrapping REST APIs with no thought to context engineering, servers that are just parameterized table queries, and the wide quality variance that emerges when a protocol is easy to implement but hard to implement well.

Multi-agent MCP systems make a hard question unavoidable: when an agent produces an answer by calling several tools across several servers, when do you trust it, when do you retry, and when do you escalate to a human? Most setups answer with static rules that don't improve.

I'll demonstrate a confidence-gated coordination pattern for this, built as a working reference over real MCP servers. The agent routes each result by a confidence-and-correction signal: a confident, human-confirmed answer reinforces that path; a corrected answer triggers a different one — retry, reroute, or adapt. Reinforce when right, retrain when wrong — a routing-and-failure-handling policy that sits over your MCP tool calls.

I'll walk the reference end to end on one concrete case — a customer-care agent deciding a billing credit across account, policy, and issuance servers — showing where the gate lives in the MCP topology, how state flows across servers, and how retries and human escalation are handled. I'll be honest about its limits and where it breaks.

You'll leave with a coordination pattern, and a working reference you can adapt into your own multi-server MCP architecture.

Not every AI integration needs an MCP server. Sometimes a direct API or SDK call is enough, and adding a protocol layer introduces complexity without solving a meaningful problem.

This talk will use an independent Java demonstration project to compare MCP-based and direct API integrations. Starting with the same task, I’ll explore what each approach requires and where the tradeoffs appear: authentication, deployment, latency, tool design, and maintenance.

The examples will examine when reuse across AI clients justifies an MCP server, when the resource model helps, and how to choose tool granularity. I’ll distinguish design expectations from observations gathered through the demonstration.

Attendees will leave with a practical checklist for deciding when to build an MCP server, when to use an existing one, and when a direct integration better fits their needs.

MCP authorization gets a client to a protected remote server. The harder question arrives at tools/call: may this user, through this client, refund this order with these arguments?

We'll trace that request through MCP's authorization flow: Protected Resource Metadata, authorization-server discovery, PKCE, resource indicators, delegated scopes, and audience-bound access tokens. Then we cross the protocol boundary. The MCP server maps identity and scopes to tool-level policy, validates arguments against business rules, and preserves the user's identity when it calls the upstream API. Tool annotations can help a client present risk, but the server never treats them as authorization. The client owns human approval for the irreversible action.

Finally, we'll test prompt injection that selects an unintended tool, a confused-deputy request, and token reuse against the wrong MCP server. Attendees leave with an MCP-specific control map and an audit record that ties a tools/call request to the user, client, resource, policy, and result.

Everyone connected an MCP server this year. Almost nobody has shipped an MCP app – a full, interactive UI that renders inside Claude or ChatGPT via a ui:// resource and holds a two-way conversation with the agent. I'll build one on stage: a component editor that lets a non-developer redesign a live production widget from within a chat, with a preview, an inspector, and one-click rollout.
The interesting part isn't the pixels – it's the boundary. The app and the agent share a screen but not a brain, and that boundary is gated: only model-initiated tool calls reach the model's context; the results of app-initiated calls, and messages you try to "push," do not. That one constraint quietly rewrites how you architect everything – where state lives, how the app asks the agent to act on its behalf, and why "just send the data to the model" doesn't work. I'll show the patterns that survive contact with production.

Alice asks her agent to send $2,000 to her daughter in Lisbon at the best FX rate. It calls four tools, compares three providers, and transfers the money. The winner advertised zero fees. The markup was buried in the exchange rate, and no human ever saw the fine print.

ChatGPT Plugins, Claude Marketplace, and personal agents like OpenClaw and Hermes Agent can now call your existing Shop, Search, Filter, and Sort APIs as tools. You ship an MCP server, skills, and a plugin manifest. Whoever runs the agent owns everything else: the model, the ReAct loop, context, memory, hooks, and the sandbox. When your API becomes a tool inside someone else's agent, your schema has to carry every promise your website used to make.

Agents don't write bad product or service reviews: if your storefront is a token hog that reduces agents to a lethargic crawl, scrape, and screenshot, they quietly take their customer to a store that answers in schema, and you never see the sale you lost.

This talk covers three shifts. (1) Page to payload: the agent calling your tool never sees your webpage, so fees, rate markups, unit prices, and Sponsored labels must travel in the Tool response (payload) itself. (2) Disclosure survival: your tool can return the fee, and the model's summary can still drop it. You'll learn to test for that game of broken telephone on platforms you don't control. (3) The Ranking Receipt: a machine readable record of what was paid for, what was compared, evaluated, and weighed, and why the agent chose a rival over you.

Includes a live agent readiness scan, and four moves you can make Monday morning.

A valid OAuth token does not establish that a verified human approved a specific consequential action. We’ll present an MCP architecture for user-delegated agents that combines verified identity with passkey confirmation of high-risk actions, without treating passkeys alone as proof of humanity. The server pauses execution until it receives an approval result linked to the exact action. Using LoginID’s AI Gateway as an example, we’ll cover payments, refunds, campaign sends, and bulk data changes while preserving existing authorization controls and avoiding unnecessary prompts.

MCP gives agents a clean interface to the world, but it can't fix what happens when the world changes between tool calls.

Most agent failures in production aren't model failures. They're data failures. An MCP tool returns information that was accurate at 6am. By 9am, the situation changed. The agent acts confidently on stale context, and in multi-agent systems, that wrong answer propagates before anyone catches it.

The gap between demo agents and production agents isn't intelligence. It's freshness. Batch-refreshed RAG and polling loops cover a lot of ground, but they break down the moment your agent needs to respond to something that happened 20 minutes ago.

This talk makes the case for event-driven architecture as the missing layer under MCP, not as a theoretical nice-to-have, but as the practical difference between agents that hold up in production and ones that don't. We'll walk through specific failure modes from stale MCP tool responses, the design decisions around event-triggered execution, streaming context delivery, and agent-to-agent communication patterns.

In this hands-on hour you build a multi-agent MCP workflow that does 3 things. You create a MCP server with a catalog of services or tools, connect to a master payment-enabled MCP server, and give your agent a non-custodial identity that can publish to the catalog as well as hold, receive, and spend funds. Any purchasing agent can call a paid tool, watch the payment settle, then hand custody to a second agent — and finish with a verifiable record of every step you can open and inspect.

You leave with:
– a running multi-agent workflow that publishes tools, searches and pays for tools, and transfers custody between agents
– a clear model of how identity and payment attach to an MCP server with no login and no server-side session
– one real failure handled live: an agent that runs out of funds mid-workflow, and how the protocol recovers
– the code and the audit log, yours to fork

Prerequisites: comfort with one MCP client (Claude Desktop, Cursor, or a small Node/Python client), basic command line, an empty GitHub repo, and the workshop repo cloned in advance. No identity- or payment-protocol background needed.

TRM Labs began its AI journey with the ambitious goal of leading their category in agent adoption. Early in their journey, they encountered a hard operational problem: local MCP servers were fragile, difficult to maintain, and often required secrets to live on developer laptops. In this session, TRM Labs will share how it overcame these challenges and drove company-wide MCP adoption with an agent-agnostic approach for connecting employees to MCP servers:

• Why TRM decided to centrally host MCP servers
• How TRM created a consistent layer that could support new agents without rebuilding integrations
• What TRM did to make internal MCP servers easily discoverable in their developers’ everyday tools.

Attendees will learn how to design an AI enablement strategy that improves developer experience, AI governance, auditability, reduces operational sprawl, and avoids tying critical enterprise integrations to one model or interface.

A registry entry that was reviewed once at submission time tells you almost nothing about whether the server behind it is safe to run six months later. Static review catches the obvious problems and misses everything that happens after publication: a maintainer account takeover, a quietly updated tool description, a dependency the server itself pulls in in the background. This session covers the specific technical components a trustworthy MCP registry needs beyond submission time review: build provenance and publisher verification so a server's origin is attestable, versioning and pinning strategies so consumers are not silently exposed to unreviewed updates, and revocation mechanisms that actually propagate when a server is found to be compromised. It also covers what gateway level permission scoping and sandboxing can contain even when registry level vetting misses something, because no registry will catch everything, and the architecture has to assume that from the start.

This talk follows a single handwritten line (ex. @k8s map: the kagent namespace ) through its entire journey captured by a penstroke.

Using a reMarkable as my input device with OCR'd communications using A2A integrations to kagent agent with 50+ MCP tools, and getting back the results as a hand-drawn mind map, or configuration output or results.

I'll show the three layers that make it work, all open source: the MCP server side (Kubernetes, F5, Foritgate, Helm tool servers exposing real infrastructure), agentgateway routing requests and injecting credentials so the tablet never holds a key, and an on-device C app doing panel takeover to capture handwriting and draw answers as native ink. Along the way: how MCP, A2A, and an LLM gateway compose into one pipeline.
What attendees will learn

How MCP, A2A, and an LLM gateway compose — where each boundary sits and why (MCP for tools, A2A between agents, gateway for routing + auth injection).
A pattern for thin, keyless clients — the tablet carries no API keys; agentgateway injects credentials at the edge. Applies to any constrained device.

https://youtube.com/shorts/1B90gMgRn64?si=Jxnon5y26BTZ-Vbc

Most people manage their financial lives across six or more disconnected apps — a banking app for balances, a brokerage for stocks, a mortgage portal, a credit card dashboard, a savings tracker, and a news feed. None of these talk to each other, and none of them tell you what to do next.
FinPilot is a personal AI financial advisor built as an over-the-top mobile app that uses the Model Context Protocol (MCP) to securely authenticate with and pull data across all of these sources simultaneously. Powered by an LLM at its core, FinPilot synthesizes your checking balance, savings, mortgage principal, credit card spend, stock holdings, and real-time market signals into a single daily briefing — and proactively tells you whether to spend, save, invest, or rebalance.
In this session we walk through the full MCP architecture, the OAuth security model for authenticated financial APIs, and close with a live demo on a real device showing FinPilot answering questions like: Should I take this vacation? Should I make an extra mortgage payment to reduce my total APR? Where should my idle cash go?