MCP Dev Summit Seoul 2026

As MCP systems move from single tool use to multi server and multi agent workflows, a key security question appears: when one server calls another on behalf of a user, whose authority is actually used. In this talk I show how chained MCP calls can create a confused deputy scenario where a server unintentionally uses its own higher privileges instead of the user’s limited permissions, leading to privilege escalation and capability leakage. I demonstrate this with a working multi server setup that exposes three concrete failure modes: token scope amplification across calls, server to server impersonation caused by implicit trust, and over delegation of capabilities during orchestration. I then present a practical mitigation based on capability driven design, where each request carries explicit scoped permissions, preserves the caller chain, and is verified at every hop. A prototype implementation shows how these controls block real attack paths while keeping developer experience simple. Finally, I highlight gaps in the current MCP specification and suggest extensions for safer multi agent systems.

As MCP adoption grows, tools are becoming the primary interface between agents and external systems. This introduces a new class of risks: tool poisoning, where tool definitions, inputs, or outputs are manipulated to influence agent behavior in unintended ways.
This talk focuses on practical experience identifying and mitigating tool poisoning in MCP-based systems. Early implementations often assumed tools were trustworthy, but in practice we encountered issues such as ambiguous tool descriptions, unsafe parameter handling, and outputs that could steer agents off course.
We will walk through concrete examples of how these failures surfaced, and the patterns that proved more reliable. This includes validating tool contracts, detecting anomalous inputs and outputs, constraining tool usage, and introducing safeguards around execution flow.
Rather than proposing a single framework, the session presents a set of techniques that can be applied incrementally to existing MCP setups. The goal is to help teams better understand how tool poisoning occurs in real systems, and how to design MCP tools that remain predictable and safe under agent-driven use.

MCP is becoming the standard way for agents to connect with tools, apps, services, and data systems. But as MCP moves from local developer workflows into production agent platforms, the next bottleneck is discovery infrastructure: how agents find the right MCP server, verify its capabilities, evaluate trust, respect permissions, and route safely across teams, clouds, vendors, and organizations.

This session presents a practical architecture for MCP discovery infrastructure: capability metadata, registries, signed server facts, gateway patterns, trust signals, policy-aware routing, observability, audit trails, and failure handling. The focus is on reusable design patterns that can help MCP scale without fragmenting into brittle static configurations or vendor-specific registries.

Drawing on Project NANDA work around AgentFacts, registry interoperability, adaptive resolution, and NEST-style testbeds, the talk gives MCP builders a concrete framework for moving from “agent calls a configured tool” to “agent discovers and safely uses trusted capabilities.” Attendees will leave with implementation patterns, failure modes, and standardization questions for production MCP systems.

Traditional AI implementation relies on "tool sprawl": manually wrapping every API action into custom functions. This creates a maintenance burden where prompts swell, tokens vanish, and agents hallucinate under the weight of excessive choice. At Postman, we’ve shifted the paradigm: instead of teaching agents how an app works, we provide them with structured context they already understand through the MCP.

This session moves beyond theory to demonstrate a live "AI Readiness" workflow using Postman’s native Git integration. We will pit a well-defined OpenAPI schema against a poorly designed one to visualize the "Context Tax" - showing how architectural debt leads to 2x higher token usage and fumbled execution. By leveraging Postman’s MCP Server generator and CLI SDKs, I’ll demonstrate how to transform static documentation into active "code skills" that agents like Claude can navigate autonomously. Attendees will learn to build APIs that don't just return data, but serve as high-fidelity maps for the next generation of autonomous agents.

When an MCP server exposes documentation.search and documentation.fetch, its docs site quietly acquires a second reader: the agent. And the agent is not a small human. Humans want narrative tutorials; agents want flat, deduplicated, single-source-of-truth pages. Humans skim; agents tokenize. Humans tolerate ambiguity; agents hallucinate from it.

This talk is a field report from rewriting an MCP server's documentation to serve both audiences from one markdown source. Concrete before/after pages, real agent traces from the SuprSend MCP server (used as a case study not a pitch), the five rewrite rules that actually moved the needle on hallucination rates, and the surprising downstream effect: the human-facing docs got better too. Every rule generalizes to any MCP server with public docs.

Closes with two open questions the audience is invited to argue back at: should agent-facing docs be a separate channel? Should MCP add a "documentation" primitive at the protocol level?

For DevRels, technical writers, and MCP server maintainers who already exposed their docs as a tool or are about to.

We built an MCP server exposing 40+ operations. Agents misused most of them. Hybrid search returned only IDs with no context. get_issue prefixed every field with redundant key-value labels, burning tokens without helping the LLM. We had write tools with no corresponding read tools. Custom field schemas varied wildly across organizations, causing unpredictable bloat.
We cut to 14 tools. Agent precision improved dramatically. But deciding which 14 - and how to design them - required building a framework we wish had existed when we started.
This talk shares that framework as an open, reusable methodology any MCP server author can apply: how to audit which tools agents actually select vs. misuse, how to score agent success rate per tool, how to identify tools that confuse rather than help, how to structure response shapes for minimal token cost and maximum agent comprehension, and how to design progressive disclosure so capability scales without overwhelming context.
Every team building an MCP server faces this decision. We'll give them a starting point so they don't have to learn it the hard way.

As MCP adoption grows, most implementations focus on defining tools and integrating APIs, but far less attention is given to how these tools are actually executed. In production environments often introduces real challenges in both security and performance.

In this session, we explore how WebAssembly fundamentally changes this model by providing a secure and high-performance execution layer. We'll also work through how MCP tools can run inside a sandboxed WebAssembly runtime, where access to the file system, network, and environment is explicitly controlled. This significantly reduces the attack surface compared to traditional server-side execution models, especially in multi-tenant and agent-driven environments.

From a performance perspective, WebAssembly enables near-native execution speed with extremely fast startup times. WebAssembly modules can start in milliseconds, making them ideal for MCP workloads where tools are invoked frequently and latency directly impacts agent responsiveness.
We will also cover authentication patterns such as OAuth and JWT, and explain how a “secret-less” architecture can be achieved by isolating credentials outside of the execution runtime.

Most teams start with MCP by exposing existing APIs as thin tool wrappers. We did too. However, we quickly realized that for complex operations-like managing GPU clusters and infrastructure health-simply exposing more tools doesn't lead to better automation; it leads to LLM confusion. The real challenge is defining the right reasoning and execution boundary.

In this talk, we share our journey of moving beyond simple API exposure to building MCP servers that act as a sophisticated operational layer. We'll dive into how we transformed fragmented signals into 'Structured Guidance' by embedding domain heuristics and workflow context directly into the MCP layer.

Attendees will learn:
- how to recognize when MCP is acting as a thin wrapper versus a real workflow boundary
- how to design MCP on top of existing operational or management systems
- how to turn fragmented tools, signals, and internal APIs into structured guidance for real-world workflows

This session is a practical story about where MCP becomes more than an integration layer: when it starts acting as the execution boundary for real-world operational decisions.

"MCP makes it easy to expose tools.
It does not make it easy to design systems."

At scale, that gap shows up as tool explosion, context limits, and unreliable execution.

As MCP servers grow, they accumulate large numbers of tools, fragmented abstractions, and stateful workflows, until agents struggle to discover, select, and reliably execute the right actions.

Attendees will leave with specific design patterns to make MCP servers more reliable, scalable, and easier for agents to use.

In building Appium MCP (github.com/appium/appium-mcp), we encountered this firsthand. Supporting real mobile automation required handling 100+ device actions, concurrent sessions across devices, and flaky UI interactions, quickly pushing naive MCP designs to their limits

In this talk, we demonstrate what breaks when MCP servers scale and how we changed our system

We evolved from loosely defined tools to an intent-driven interface, added elicitation for clearer execution, and integrated Appium Skills to extend capabilities.

These patterns enabled us to move beyond simple command execution toward composable, agent-driven automation, powering new projects like AppClaw - an extension to Appium MCP.