MCP Dev Summit Seoul 2026

Two years ago, getting an AI agent to reach anything outside itself meant writing a whole bunch of glue code. A custom integration for every tool, every data source, every model you wanted to support. Nobody enjoyed this, and yet everybody did it anyway.

MCP was the emerging alternative - one protocol, implemented once on each side. It empowered all imaginable agents to be able to talk to anything through a standard set of conventions.

Two years later, the ecosystem around MCP is bigger than the spec itself. There are servers for nearly everything anyone would want to wire an agent into, clients across every major platform, and entire categories of capabilities that make the protocol suitable for more than just ferrying text-based data back and forth.

MCP is now the undeniable substrate most agentic workflows run on. Getting there took a couple of years, a large number of engineering debates, and the work of a community of maintainers, developers, and advocates that spans the globe. This is the story of us getting here.

To attach an MCP server to each of hundreds of Naver Cloud Platform services, every service team had to implement MCP from scratch.
We built an MCP Generator to solve this — automatically generating MCP server code from OpenAPI specs.

Then Claude's MCP Builder Skills arrived. Suddenly, anyone could build an MCP server through a few conversations with Claude. The value of the generator we had built disappeared overnight.

We had to change direction.
And the question changed with it — from "how do we make building MCP servers easier?" to "how do we operate hundreds of them?"

That's how MCP Gateway was born. It aggregates multiple MCP servers behind a single HTTP endpoint, so users can connect every cloud service tool to their AI agent with just one URL and one API key.

This talk is structured in two parts:

Part 1 — The Journey: The process of figuring out how to provide good MCP servers for hundreds of cloud services — what problems we found, what we tried, and how the arrival of MCP Builder Skills became the turning point.

Part 2 — MCP Gateway: An introduction and demo of what problems it solves today, and a look at what we're building next.

Most MCP deployments implicitly trust the LLM. If the model says call this tool with these parameters, the server calls it. That trust model is wrong — and at enterprise scale, it is catastrophic. This talk reframes MCP server design through a zero-trust lens: every tool invocation is treated as an untrusted external request that must be authenticated, authorized, validated, rate-limited, and audited independently of who initiated it. I'll demonstrate a zero-trust MCP middleware layer that enforces four controls: (1) per-call JWT audience binding so a tool call valid in one agent context is rejected in another, (2) schema-level input validation with content-addressable allow-lists to prevent prompt injection via tool parameters, (3) capability scoping — tools declare what filesystem paths, network ranges, and data stores they may access, enforced by a policy engine at runtime, and (4) immutable audit logs using append-only signed ledger entries. Live demos include intercepting and blocking a prompt injection attack mid-flight. Code ships as open-source middleware compatible with any MCP SDK.

We started running MCP servers in production about a year ago. Within weeks we got our first 3 AM page, a tool was silently failing, agents were retrying into the void, and we had zero visibility into what was going wrong. No dashboard caught it. No runbook existed. That incident kicked off a twelve-month journey of figuring out how to actually operate these things. We ended up cutting agent-related incidents by about 70% and got tool invocation P99 under 500ms.

This talk is the playbook we wish we had on day one. We'll cover the stuff that bit us: health checks that go beyond HTTP 200 and actually validate MCP protocol readiness, how to handle deployments when connections are stateful, what to put on your observability dashboards (and what turned out to be noise), and circuit breaker patterns for when an upstream tool starts misbehaving. We'll also do a quick demo of a monitoring setup we've been running.

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.

For most developers, one of the trickiest parts of building MCP Servers is Auth. With an ever-evolving specification that takes advantage of niche OAuth standards, many feel left behind and simply don't bother to secure their MCP Servers, leading to severe risks for organizations and users adopting MCP.

This session will cover the MCP Auth spec from first principles, explaining concepts in a way that even auth newbies can understand. The goal of this session is to help developers 'catch up' on the latest with MCP auth and secure their MCP servers.

Participants can walk away from this session with a cursory understanding of the state of the MCP auth spec and how to roll out auth in their MCP servers.

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.