MCP Dev Summit Seoul 2026

An agent processes a payment, hits a timeout, and retries. Now the payment has been charged twice. The model didn’t hallucinate. The workflow did exactly what it was told. The problem is that nobody designed the agent to be safe under retry.

This is a distributed systems problem.

When agents read data, take actions, and write results back, correctness depends on how state is managed across steps. Under retries or concurrent execution, the same workflow can produce conflicting outcomes.

This talk shows how to build stateful AI agents using the Model Context Protocol with a PostgreSQL-compatible distributed database. Instead of treating memory as embeddings, we treat it as structured, transactional state.

You will learn how to design MCP tools for database operations, manage multi-step workflows, and handle failure modes such as retries and idempotency. We will also explore consistency tradeoffs in distributed systems.

The session ends with concrete patterns for building reliable agents, including idempotent tools and safe retry design.

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.

Model Context Protocol (MCP) is quickly becoming a core interface layer for AI agents, yet many teams still secure MCP servers as if they were ordinary APIs. This session provides a practical guide for building and operating secure MCP servers in production.

I will translate key security principles into concrete engineering decisions: secure local vs. remote MCP architectures, trusted tool onboarding, signed manifests, schema-based input and output validation, prompt injection controls, OAuth 2.1 / OIDC-based authentication, centralized policy enforcement, hardened deployment, audit logging, and continuous validation.

The goal is not theory, but an actionable security baseline that developers, architects, and platform teams can apply immediately. Attendees will leave with a pragmatic minimum bar and review checklist for MCP server development that helps reduce avoidable security failures, improve trust between clients and servers, and strengthen the security posture of the growing MCP ecosystem.

Giving an AI agent access to a Kubernetes cluster sounds powerful — until it runs the wrong command. The real challenge is not connecting an LLM to a cluster, but constraining what it can do, enforcing correctness, and keeping a human meaningfully in the loop.
This session presents a blueprint for safe, auditable MCP-powered operations through a real use case: an AI-assisted failover system for Kubernetes. Instead of letting an agent call cluster APIs directly, we place a Failover MCP Server in front of the cluster and expose only discrete, permission-scoped tools for observation and controlled action.
Beneath that reasoning layer, a Kubernetes Operator serves as the enforcement point. CRDs such as FailoverPolicy and DisasterRecoveryPlan encode failover semantics, validate requested actions, and ensure execution remains deterministic and policy-compliant. Sensitive actions are held behind a requireApproval setting in the Agent manifest until an operator explicitly approves the next step.
The talk closes with lessons on where LLM reasoning helps during incidents and why Operator-controlled execution still matters in high-risk workflows.

When teams start building on MCP, one of the first real questions that comes up is simple: what are agents actually allowed to do?

In smaller setups, it's easy to bake access checks into the agent or the application itself. That works until it doesn't. Once you're dealing with multiple tools, services, and data sources, things get messy fast. Permission logic gets copied across services, drifts out of sync, and when something breaks, nobody can agree on where the problem actually lives.

This talk covers how I approach authorization in MCP-based systems. Where access decisions should live, how to keep them consistent as complexity grows, and what changes when agents are acting on behalf of users rather than just on their own.

The focus is on patterns that have worked in real systems: centralizing your policy layer, passing the right context through each request, and keeping decisions auditable so you can trace what happened and why.

You'll leave with a clearer way to think about authorization in MCP environments, and a better sense of where things tend to break down as systems scale.

When a human calls an API, identity is well understood, OAuth tokens, JWTs, API keys. When an AI agent calls that same API via MCP, the identity model breaks down. Who is the caller? What should it be allowed to do? How do you revoke access when something goes wrong? As MCP adoption moves from dev laptops into production systems, the absence of a consistent identity and authorization layer for agent-initiated traffic is becoming a critical gap. This session walks through the auth problem from first principles covering OAuth flows for non-human callers, per-agent rate limiting, JWT validation at the MCP proxy layer, and policy enforcement patterns that don't require rewriting your backend services. Attendees will leave with a concrete mental model and implementation patterns for securing MCP tool calls in production.

Most MCP examples are written in Python or TypeScript. Great for prototypes, but enterprises don't ship prototypes. They ship type-safe, robust, observable, secure services. Exactly what Java excels at.

And, perhaps contrary to popular belief, building MCP servers or clients with Java is not hard at all. It is as natural as creating REST servers and clients. Swap a few dependencies, annotate your methods, and your services speak MCP.

But MCP in Java isn't just about exposing data to LLMs. It can also vastly augment your AI development experience. We'll show how we built an MCP-based agent into the Quarkus framework that exposes live runtime intelligence to your code assistant: structured exceptions, dynamically discovered tools, extension-specific coding patterns, and version-aware documentation search. With this, your agent doesn't just write code; it can also get real-time feedback from the running application, recover from crashes, and learn patterns specific to the frameworks in your project.

Through real-world examples including IoT integrations and Kubernetes analysis agents, we'll show why Java is the natural home for enterprise MCP adoption.

As teams adopt MCP, a common anti-pattern appears: expose an entire API surface as tools and hope the agent figures it out. In practice this leads to confusion, brittle behavior, and security headaches.

In this talk, I’ll walk through a practical architecture for taming that complexity using MCP flavors and a Public MCP gateway. We’ll start from the real constraints: large APIs, multiple products, and agents that need a bit of more focus & from there:

- design flavors as curated tool bundles on top of existing OpenAPI contracts;
- expose them via a gateway (/mcp vs /{flavorId}/mcp) while handling auth and routing cleanly;
- and plug these flavors into agents in editors or chat environments.

I’ll also cover how to evaluate and debug flavors using datasets and traces so they’re treated like product surfaces with their own quality bar, not opaque black boxes. Finally, I’ll share lessons learned ramping from a mostly frontend/“traditional” engineering background into MCP and agentic infrastructure work: what worked, what didn’t, and what I’d do differently.

Imagine telling your system, “Simulate a pod failure on the payments service,” or asking, “What chaos experiments have we run on service X in the last 30 days?” This talk covers a practical approach to using the Model Context Protocol (MCP) with LitmusChaos. The goal is to move away from manual YAML configuration and CRD lookups by using a natural language interface. I'll demonstrate how this MCP setup works and how it changes the workflow for designing and running resilience tests.

This session introduces Chaos Engineering and explores how MCP makes it more accessible. By replacing YAML and dashboards with human language, we’re lowering the barrier to entry for chaos engineering. Resilience testing becomes accessible to QA, product, and on-call teams, not just platform experts. Whether or not you’re currently using Litmus, this talk will provide a roadmap for building your own chaos copilot and a glimpse into a future where resilience is everyone’s responsibility.