Schedule

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.

As AI agents proliferate across organizations, from coding assistants to autonomous workflows, teams face a critical infrastructure gap: there is no standard way to version, scope, and distribute agent skills and MCP configurations across teams. Today, one developer builds a powerful set of skills; the rest of the team copies from a Notion doc. Skills evolve bidirectionally (at source and point of use), creating drift that no existing tool resolves. This session introduces an open-source architecture for a unified skill registry that operates as both an npm-like CLI for developer workspaces AND an MCP server for runtime agent resolution. We'll cover the declarative requirements.yaml format that lets teams describe intent rather than write full skill packages, namespace-based scoping (@org → @team → @personal) with version inheritance, and how the resolution algorithm works in multi-agent (ACP) systems. Live demo included.

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.

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 understand Washington D.C.'s Municipal 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 accountaibility, 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

The Playwright MCP and CLI expose the same tools with different interfaces, making for an useful side-by-side comparison. I’ll walk through an investigation that began as a runtime performance benchmark and led to a stranger result: “context-inefficient” interfaces like the Playwright MCP can make agents faster, more accurate, and less expensive.

I compared the Playwright MCP, CLI, and agent-browser across QA scenarios. To my surprise, agents with the MCP were consistently 2-3x faster than the alternatives. The alternatives focus on token efficiency as their raison d'être, and do consume dramatically fewer tokens. They achieve this by returning less information, which requires agents to make more tool calls before acting. Each tool call adds significantly to the runtime and the cost.

The results don't tell us to choose MCP or CLI, but should inform interface choices for both. Concise responses save tokens, but if an agent needs that context, it pays for the conciseness with extra steps.

This talk expands on https://outpost.ranger.net/post/the-hidden-cost-of-fewer-tokens/, with more detail on the methods, results, and what they suggest for designing better interfaces for agents.

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.

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.

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!!!) 🙂

Most MCP demos show a simple tool call: ask, execute, return. But real enterprise agents rarely work that way. They trigger cloud checks, deployment validations, incident workflows, report generation, approval steps, and remediation tasks that can take minutes, fail halfway, or need cancellation.

This session explores how to design reliable MCP-based agent workflows using the emerging Tasks model: call-now/fetch-later execution, task handles, progress checks, retries, expiry, cancellation, and state handoff across tools and servers.

We will use a real-world architecture problem familiar from cloud and Kubernetes operations: an agent starts a production readiness check across multiple systems, waits for results, retries transient failures, asks for human input when needed, and cancels safely if risk increases. The session will show how MCP clients, servers, and orchestration layers can coordinate without depending on fragile synchronous calls or hidden session state.

Attendees will leave with a practical blueprint for building MCP agents that survive latency, partial failure, retries, and long-running enterprise workflows.

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.

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.

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.

Many organizations are hearing about the Model Context Protocol (MCP) and exploring how it can help connect AI assistants and agents to business data and systems. But what does MCP actually do, and how do you move from experimentation to real business value?

We'll demystify MCP and explore how organizations can use it as a foundation for building connected AI experiences across Microsoft 365, Dynamics 365, and other enterprise applications. Using real-world examples, we'll walk through the journey from early pilot projects to broader organizational adoption.

Attendees will learn:
– What MCP is and why it is becoming important in enterprise AI strategies
– How MCP helps AI assistants securely access business data and systems
– Common scenarios for Microsoft 365, Dynamics 365, and custom applications
– Key considerations for governance, security, and user adoption
– Practical steps for getting started and scaling beyond initial pilots

By the end of the session, attendees will have a clear understanding of MCP fundamentals, its role in the enterprise AI ecosystem, and a roadmap for beginning their own MCP journey.

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.

Every team that connects an enterprise platform to MCP runs into the same problem. Your product has hundreds of API methods. Make all of them available as tools and you overwhelm the context window, confuse the model, and give the agent too much power. Make too few available and the agent cannot do its job. This talk is about my experience designing an MCP integration for an enterprise analytics platform, and the decisions that mattered along the way.
We will go through the design questions in the order we faced them. How do you turn a large API into a small set of tools instead of copying every endpoint? Tool granularity has a bigger impact on quality than anything else. How did we handle context bloat before clients could progressively discover tools, and what changed once they could? Typed parameters caught mistakes that would have gone unnoticed. We separated read tools from write tools, added approvals so the agent cannot make big changes without permission, and logged everything, because someone will eventually ask why the agent did something.

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.

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.

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.

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.

An authenticated and authorized MCP tool call is not evidence of the user's intent. Ambiguous instructions, faulty parameter inference, or prompt injection can produce a fully authorized tool call that performs actions the user never intended. From the tool call it receives, the MCP server cannot verify whether the user was prompted for approval, what they approved, or whether the approved operation matches the executed tool call. At the point of execution, a correctly reviewed operation and a misinterpreted one are indistinguishable.

This talk introduces the User Intent Verification Pattern (UIVP), which closes this gap without changing the MCP protocol, in the same way authentication and authorization do: by replacing an unverified claim with verifiable evidence. Instead of trusting confirmation prompts rendered and reported from within the agent's own trust domain, UIVP captures approval out of band, cryptographically binds it to the exact tool and arguments, and enforces it at the MCP server before executing consequential operations.

We close with a live demo: an authorized tool call diverges from the user's intent, and the MCP server refuses to execute it.

MCP is reshaping how agents connect to tools. Enterprise adoption is stalling at two blockers: regulated buyers need to know exactly what data the agent accessed and under what policy, with proof that cannot be altered post-execution.

This talk covers cMCP — an open-source gateway that wraps any MCP server without requiring changes to existing servers or agent code:

Cedar policy enforcement: tool calls evaluated against declarative policies before execution. Denials are structured — the agent can reason from them, not silently fail.

Tamper-evident audit chains: every call chained into a Merkle structure. Any modification breaks the chain.

TEE attestation: the audit chain root is sealed into a hardware measurement (AMD SEV-SNP, Intel TDX, NVIDIA H100 CC). The resulting TRACE claim is verifiable by any third party — no trust in the operator required.

The same property that makes a log entry inadequate for compliance — an operator can alter it — is exactly what hardware-sealed receipts solve.

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.

Writing an MCP server is easy. Reproducing everything around it — the database, the credentials, the network policy — is where most projects lose contributors and workshop attendees.

This talk works through that reproducibility problem using three sandbox kits of increasing complexity. The first surfaces why PATH configuration that works in a login shell silently breaks when an AI agent runs bash non-interactively — a failure mode affecting every Python-based MCP server. The second exposes a networking lesson that hits any sandboxed environment: bind address configuration that works on localhost silently fails once the client is one network hop away. The third wraps a hosted MCP service for cross-agent memory handoff, where the real challenge is credential proxying, auth header injection, and composing narrow single-purpose mixins.

From these cases the talk distills patterns that generalize: why credentials must flow through a proxy layer, why network allowlists require transitive auditing, and why composability beats monolithic environments.

Attendees leave with a checklist they can apply to their own MCP server the next day.

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.

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.

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.

We built an MCP server to wrap an internal storage API. It took two weeks. A direct SDK call would have taken an afternoon. The server added latency, auth complexity, and a new failure surface, all for a single-model integration that never needed protocol-level abstraction. We've done this more than once.

MCP is powerful. It standardizes how LLMs connect with tools, prompts, and resources. But not every integration deserves an MCP server. Sometimes it's overhead that slows you down, even when a plain SDK or a direct API call would work better. The problem is that the MCP ecosystem currently has no guidance on when to stop.

This talk covers the decision points we got wrong and the ones we got right across multiple MCP builds on the JVM. When does tool granularity matter versus when is it wasted design effort? When does the protocol's resource model earn its weight, versus when is it a layer you'll regret? What's the actual threshold where "just call the API" stops working and MCP starts paying off? I'll walk through each with real examples, including a case where ripping out an MCP server improved agent reliability.

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.

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.

MCP authorization is converging for the client–server edge: OAuth 2.1, PKCE, scoped tokens, DCR. But the host — the AI application orchestrating clients, sub-agents, and downstream systems — is still out of the picture. The host needs an identity to administer, authenticate, authorize, and audit. What's unanswered: what that means when the host runs on-device, offline, in regulated verticals where no Authorization Server is reachable.
This talk presents an edge-native instantiation of the Four A's, drawn from EdgeMind — an Android on-device AI governance platform for pharma, fintech, logistics, and emergency response. A Keystore-rooted, SPIFFE-style host identity; ES256 capability tokens minted in-process with sub-5-min lifetimes; an in-process MCP control plane gating every tool call with JIT scopes; and an HMAC-signed, hash-chained append-only audit journal realise the Four A's without an IdP on the wire — federating upward via OAuth Token Exchange when connectivity returns.
We close with an airplane-mode demo on a Snapdragon device: an MCP host that authenticates itself, mints scoped capabilities, gates a tool call, and emits a verifiable audit record — offline, under 400 ms

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