MCP Dev Summit Seoul 2026

The Model Context Protocol (MCP) is emerging as a standard for connecting AI agents with external tools. While LLM-based tools are flexible, their non-deterministic behavior makes it difficult to meet requirements for stability, repeatability, and auditability in production systems. In such cases, traditional machine learning models provide more predictable inference and are often preferred for system-critical decisions.

However, ML-powered tools are not free from challenges. Latency, failures, and integration issues can propagate through MCP systems and impact agent behavior, leading to inconsistent decisions, repeated retries, or silent failures.

This session explores what happens when MCP tools fail and how to design systems that remain reliable under such conditions. We present a reproducible demo of failure scenarios, including latency spikes and unstable predictions, and show their impact on agent behavior. We then introduce practical design patterns—such as timeout and retry strategies and observability—to build reliable MCP-based systems.

Attendees will gain concrete techniques to design trustworthy AI systems that remain stable in real-world environments.

MCP's current transport model is largely request/response — but production agents need to react to live events without polling. GraphQL subscriptions, delivered over graphql-ws or graphql-sse, offer a battle-tested, widely deployed event streaming primitive that maps cleanly onto MCP's resource notification model. This talk covers the full protocol translation layer needed to wire GraphQL subscriptions into an MCP server as push-based resource updates: how subscription events become MCP notifications, how to map GraphQL variables to MCP resource URIs, and how to handle subscription lifecycle — setup, teardown, and mid-session schema changes. We'll dig into the tradeoffs between WebSocket and SSE transports for different agent deployment environments, covering reconnection strategies, message ordering guarantees, and backpressure handling when an agent falls behind the event stream. Load tested using Grafana k6 against 2,000 concurrent subscriptions running on Apollo Server, this architecture achieves P99 event-to-agent latency under 80ms and sustains throughput that is 4.2× faster than a comparable polling baseline.

Korea's industrial conglomerates—chaebols like Samsung, SK Hynix, Hyundai, LG, and POSCO—operate the most sophisticated manufacturing ecosystems on the planet. Behind the scenes, each utilizes thousands of highly proprietary, heavily siloed Operational Technology (OT) and Information Technology (IT) systems resulting from decades of organic growth and acquisitions. Currently, engineers waste weeks manually extracting, normalizing, and correlating data from these isolated environments before any advanced AI analysis can even begin. This session explores the transformative role of the Model Context Protocol acting as a universal, cloud-native translation layer. We will reveal how manufacturing giants are utilizing Kubernetes-hosted MCP platforms to seamlessly bridge legacy industrial control systems with modern AI agents, radically accelerating industrial intelligence.

Same MCP server. Same prompt. Three different IDEs. Three different outcomes — and one of them is silently wrong.

After documenting a production MCP server across Cursor, Claude Desktop, and Windsurf, the speaker has the war stories. Tool descriptions one client truncates and another expands. Resource limits that vary by 10x. Notification semantics that work in one host and silently no-op in another. OAuth flows that route through different dances depending on the client. Session-lifetime assumptions that turn into "why did my context vanish?" support tickets.

This talk is a field guide, organized by client, with the actual diffs server authors should care about. Live side-by-side traces of the same tool call across three clients, showing where each one quietly diverges from the spec — and the small defensive changes (in tool naming, description length, error semantics) that make a single server work the same way in all three.

Closes with a proposal: a "client compatibility matrix" the MCP ecosystem should publish and maintain, modeled on Can I Use for the web.

For MCP server authors who have only ever tested in one client.

AI agents are increasingly expected to work with visual information: documents, screenshots, cameras, inspection images, and other domain-specific signals. MCP gives developers a powerful way to expose these capabilities as discoverable tools and resources, but real-world computer vision brings challenges that do not disappear behind a simple tool call, including image quality, sensor differences, domain shift, uncertainty, validation, and human review.

In this session, I will explore practical patterns for integrating computer vision into the MCP ecosystem, including OCR, object detection, visual monitoring, and domain-specific inspection tools. The talk will focus on what MCP can standardize for agent-facing vision systems, what should remain domain-specific, and how developers can design safer, more reliable interfaces between AI agents and visual perception.

GPU infrastructure has traditionally been operated through CLIs, dashboards, and a patchwork of admin tools. Each task — checking cluster state, allocating resources, launching sessions — forces the operator to switch context and stitch results together manually.

MCP changes the surface of this work. By exposing infrastructure operations as MCP tools, an agent can carry out cluster tasks on the operator's behalf. And with MCP Apps (SEP-1865), the agent doesn't just respond in text — it renders interactive UIs inline, so the operator can see the cluster, review the agent's plan, and approve actions visually within the same conversation.

This talk shows how an agent embedded in an MCP host can manage GPU infrastructure efficiently by combining:

- **Visual control via MCP Apps** — the agent renders cluster status views, resource allocation charts, and confirmation cards inline. The operator sees the infrastructure, reviews the plan, and clicks to approve.
- **Session-level control via MCP** — the agent creates, inspects, and modifies compute sessions through MCP tool calls.
- **Human-in-the-loop by design** — visual checkpoints make every consequential action explicit

Talks on agent security often focus on prompts and tools; this one zooms in on the MCP supply chain itself. When every MCP server can reach production systems, a single compromised SDK, container image, or plugin becomes an enterprise incident.

This session walks through an end-to-end hardening playbook for MCP ecosystems: SBOMs for MCP servers and clients, signing and verifying artifacts, policy-as-code gates in CI/CD, runtime admission policies, and emergency kill switches at the MCP layer.

I’ll map real-world supply-chain failures from the broader OSS world to concrete MCP risks, then show how to layer defenses without killing developer velocity. Attendees will leave with threat models, example policies, and a response runbook they can adapt to their own deployments, something they can hand directly to their security team on Monday.

MCP gained popularity because it was as easy as building a REST API. Infact, many might say, building an MCP Server is a bit too easy. Shipping a broken MCP server into a pool of a hundred others is easy but shipping one that actually behaves correctly under adversarial clients, malformed inputs, and edge-case tool schemas is hard.

Devs have already built tens of thousands of MCP servers, and recent spec revisions have focused on richer tool annotations, structured tool outputs, and clearer security best practices, all of which introduce new failure modes to test for.

This session covers a complete testing pyramid for MCP servers: using the official MCP Inspector for interactive tracing, writing conformance tests against the JSON Schema tool definitions, and applying property-based testing (with tools likeHypothesis in Python or fast-check in TypeScript) to fuzz tool inputs and surface schema violations before clients do. We'll also walk through how to set up a CI pipeline that runs your MCP server against a spec conformance suite on every pull request, and how to lint tool descriptions for ambiguity that could confuse real LLM clients.

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.

I spent four years building identity systems. When I read the MCP authorization spec, I recognized the building blocks: OAuth 2.1, PKCE, Dynamic Client Registration. I also recognized where it goes quiet on the hard parts.

Three gaps stand out.

Scopes are defined at the transport level, not the tool level. A token grants access to an MCP server, but says nothing about which tools the client can call.

Agent chain identity has no standard answer. The spec is silent on server-to-server authentication, and the client credentials grant for agent-to-agent scenarios is only now returning as a draft extension.

Dynamic Client Registration brings lifecycle problems. RFC 7592 for client management is not widely supported, and multiple clients sharing an OAuth client ID is a risk teams hit without realizing it.

I'm not an MCP insider. This talk maps four years of API and identity work onto problems MCP teams are running into right now.