MCP Dev Summit Seoul 2026

I plugged 17 MCP servers into my agent, and the agent got worse: slower decisions, dumber questions, somehow forgetting how to use the same tool it had used five minutes earlier.

That's not an MCP problem, the protocol works. The problem is that MCP defines how a tool is invoked and exactly nothing else. Every invocation is a fresh ceremony of re-discover, re-parse, re-decide, re-handle, with no persistent artifact wrapping any of it. The agent has no memory of what worked, no feedback signal for what didn't, no surrounding context to anchor which tool, when, and why.

Stateless function calls in an inherently stateful problem.

This talk is about the layer above MCP, the one that turns a directory of well-formed tool calls into coherent agent behavior, call it a Skill, a context artifact, or whatever your stack calls it. I'll show what changes when you bolt one on top of MCP: tool-call frequency drops, accuracy climbs, dumb questions to the user disappear.

If your MCP integration demos beautifully but production doesn't, this is the talk for you.

(And if you haven't shipped an MCP server yet, congrats. You'll skip a few mistakes. The protocol is the easy part.)

Every team building production agents is solving the same execution problems independently: what happens when a tool call runs for an hour, when the process crashes mid-sequence, when a downstream failure requires earlier steps to be undone. MCP doesn't specify this — deliberately. But the absence of shared patterns is costing the ecosystem duplicated effort and incompatible implementations.

This talk contributes a named, reusable pattern — MCP tool sequences as durable sagas with compensation semantics — and puts three concrete candidates on the table for spec extension: async tool results, execution receipts, and cancellation propagation semantics. A worked implementation serves as existence proof that all three are tractable today, not theoretical.

It also reframes how MCP fits into agent architecture: as the intent layer within a larger execution model, not the execution model itself. That distinction makes MCP more composable and keeps the spec lean as the ecosystem scales.

Video intelligence is an unusual MCP workload. Operations are asynchronous and long-running (indexing a 30-minute video takes minutes, not milliseconds), inputs span local files and remote URLs, and the tool surface is wide; search, analysis, embeddings, and entity recognition each carry distinct parameter shapes and response patterns.

When we set out to build a production MCP server for TwelveLabs' video understanding platform, these constraints became a useful stress test for the protocol itself. This talk traces the builder's journey from first commit to published npm package (twelvelabs-mcp), covering the decisions that shaped a 19-tool MCP server and the patterns that emerged along the way.

Attendees will leave with concrete patterns for building MCP servers around API-first platforms (particularly those with async workflows, multimodal inputs, and wide tool surfaces), along with a clear picture of how MCP servers can evolve into full agent plugins.

Developers are moving from ad-hoc AI coding assistance to more reliable agentic engineering workflows. But adoption often stalls when agents lack project-specific instructions, safe tool boundaries, and reviewable outputs.

In this session, I’ll share practical patterns from working with the Codex developer community on how teams can move from one-off AI usage toward repeatable engineering workflows. We’ll walk through an adoption ladder: starting with clear task contracts, encoding team conventions in AGENTS.md, exposing external context through MCP-style tools, and closing the loop with tests, human review, approvals, and reusable workflows.

This talk is not a general introduction to MCP. Instead, it focuses on how developers and teams can combine AGENTS.md, scoped tools, review loops, and MCP to make agentic systems more trustworthy and practical in real-world engineering environments.

MCP has solved a critical problem: giving AI agents access to external tools and data. But access alone isn't enough. An agent with a database tool can still write terrible queries. An agent with a deployment tool can still push unsafe changes. The gap isn't access. It's expertise. Agent Skills are a lightweight format for encoding the domain knowledge agents need to use tools well. A common misconception is that Skills replace MCP. They don't. MCP provides capabilities: live connections to real systems. Skills provide knowledge: patterns to follow, mistakes to avoid, conventions a team considers non-negotiable. Skills ensure an agent does things right. MCP ensures it does real things. You need both. In this talk, I'll show how they work together through real examples. You'll see agents that call tools with the right arguments, handle edge cases, and recover from errors like an experienced developer would. As the creator of Apollo MCP Server and Apollo Skills, I've built on both sides of this equation and will share the challenges of shipping both: distributing them together, keeping them in sync, and evaluating if they still add value as models get smarter.

Six months ago, building a voice AI agent on our platform meant clicking through a UI. This meant editing prompts, dragging conversation flows, hooking up tools with no audit, no rollback, no review. To make the platform work better with MCP, we moved everything to a Git-backed harness. Each agent is now its own repo with skill folders and an agent.md capturing the agent's custom instructions and unique nuances, so when a customer points Cursor or Claude at it via MCP, the AI picks up that context before making any changes.

This talk covers:
(1) the org-change journey from clickops to version control
(2) the sandboxing model, how MCP safely exposes Git's branch model (dual read/write endpoints, tool-layer branch protection, SSO-derived org scoping)
(3) the two-stage CI on every PR, MCP-driven changes ride the same rails as human-authored ones, with simulations followed by automated evaluations
(4) the closed-loop flow that ties it all together, a user files an issue with a test scenario on an agent's page, the sandboxed AI makes the change, validates it, and submits a PR for review using MCP.

Most MCP systems today are static at runtime. We define tools, expose schemas and rely on prompts to guide behavior, then hope the system remains reliable after deployment.

In practice, MCP-based systems drift. Agents repeatedly misuse tools, call inefficient sequences or fail in predictable ways. Tool descriptions become outdated. Context grows noisy. Human operators step in to correct outcomes, but those corrections are rarely captured or reused. MCP standardizes how agents connect to tools, but it does not define how systems improve over time.

I would like to explore how to build MCP systems that go beyond execution by introducing feedback loops on top of the protocol. By combining tool call history and observability, we can build systems that identify their own weaknesses and suggest improvements safely.

The session will cover practical patterns:
- Detecting repeated tool misuse and failure patterns
- Learning from retries, fallbacks, and human corrections
- Identifying redundant or low-value tool chains
- Designing safe feedback loops with audit logs, versioning, rollback and human approval

As the ecosystem for the Model Context Protocol (MCP) expands, developers are hitting a familiar wall: token bloat. While MCP provides a powerful standardized interface for LLMs to interact with external data, the "context tax" of verbose tool definitions and massive data payloads can quickly degrade performance and spike costs. To build production-ready agents, we must move beyond basic implementations and embrace advanced orchestration.

This session dives into the architecture of efficient MCP server design, focusing on the "Code Mode" technique. We will explore how to shift the heavy lifting from the LLM’s reasoning space to the server’s execution environment. Instead of forcing the model to process raw, unrefined data, "Code Mode" empowers the LLM to generate and ship logic—miniature, execution-ready scripts—directly to the MCP server. This approach minimizes round-trip latency and drastically reduces the input tokens required for complex data manipulation.

What does it take to bring a company's legacy systems into the AI era?

Hand-coding tool functions for every backend is not sustainable; maintenance costs grow exponentially as the number of services increases. We solved this with a combination of open source projects.

Given a single OpenAPI spec, the system automatically converts endpoints into MCP Tools, a Kubernetes Operator provisions and manages the MCP server, and a LangGraph + deepagents-based Agent talks to internal systems on top, with Agent Skills (SKILL) shaping how that agent behaves.

This session shares how we selected and composed five open source projects, along with the real-world challenges we hit along the way: multi-provider OAuth, custom Keycloak token verification, per-backend header injection, transport-naming inconsistencies across MCP clients, and rewriting auto-generated tool descriptions to fit the LLM.

Not a finished solution, but a practitioner's account showing that turning legacy systems into AI-ready interfaces is entirely achievable with open source.

Agentic Commerce is one of the most intriguing use cases for agents, with $3-5 Trillion in volume predicted by 2030 according to the latest research. However, with so many protocols, projects, and mechanisms, it's very easy to confused while learning about this use case, and where, if at all, MCP fits into it.

Fortunately for us, MCP fits perfectly into the modern Agentic Commerce Protocols! In this session, we'll cover exactly how and where MCP fits into the agentic commerce equation. On top of that, we'll introduce the concept of Agentic Commerce, break down the popular protocols, and construct a system design of what Agentic Commerce looks like with MCP.

By the end of the session, attendees will have a cursory understanding of Agentic Commerce principles and how to enable this use case with MCP. Additionally, a GitHub repository detailing Agentic Commerce via MCP will be provided.

In maritime navigation, dead reckoning means computing your current position using a known starting point, heading, and speed without GPS. Agentic MCP systems face the exact same problem: once a multi-tool workflow begins, mid-flight failures, partial writes, and out-of-order responses leave your agent adrift with no canonical ground truth. This talk introduces a practical framework for designing fault-tolerant MCP state machines inspired by dead reckoning principles. You will learn how to model agentic workflows as explicit state graphs, how to attach idempotency keys to MCP tool calls to safely replay without side effects, how to design checkpointing patterns that survive process crashes, and how compensating transactions replace naive rollback for real-world tools. Live-coded demos run through a concrete multi-server order pipeline that survives server timeouts, stale tool responses, and partial network partitions. Leave with implementation patterns, failure taxonomy, and open-source primitives you can wire into any MCP client today.

Dashboards lie. Not maliciously, structurally. Aggregation hides the tenant on fire. Sampling drops slow requests. The p99 looks fine because 47 users who timed out are a rounding error. Every SRE has lived this: green screen, Slack on fire, hunting across five tools to find what the dashboard refused to show.

This is a field report from building MCP tools that do the hunting. The agent does not replace the SRE. It does the grunt work nobody has time for at 3 AM: pulling exemplar logs for the slowest 0.1 percent, correlating a deploy against error rates, checking if the metric was even reporting.

1. Why dashboards lie. Sampling, aggregation, the "aggregate green, individual red" pattern.
2. MCP tool design for truth-seeking. Read-only vs side-effecting split, partial-data schemas, outputs that make the model admit uncertainty instead of hallucinating "all good."
3. Correlation loops that work. Deploy to error rate to exemplar logs to suspected change, not seventeen tabs.
4. Guardrails from production. Prompt injection in logs, cost blow-ups, tools we took back after one bad incident.

Attendees leave with patterns for MCP tools that chase down what dashboards will not show.