MCP Dev Summit Seoul 2026

Working with hardware has always been tough. But over the last 2 years, the emergence of the SO-101 arm and the rise of AI agent architectures have opened up a new way to experiment -one that dramatically shortens the loop between idea and physical action.

In this session, I will briefly cover assembling and setting up the SO-101, then spend most of the time on: how AI agents can talk to and control the hardware. Starting with Claude Code and Codex, I will show how builders can create their own agents and then use MCP to connect them directly to the arm and issue movement instructions.

All scripts, implementations, and the MCP server used in this session are available at github.com/anshuman-dev/so101-project. The repo is actively being improved to make it more structured and easier for others to pick up and build on.

The bigger idea here is accessibility. Traditionally, operating robot arms required learning specialized, poorly-maintained software with long feedback loops. With AI agents and MCP as the interface layer, that barrier drops significantly. Builders, enthusiasts, and curious generalists can now go from zero to moving a robot arm without needing a robotics background.

In early 2025, as MCP adoption grew, we built our first MCP server for Cloud-Barista, an Apache 2.0 multi-cloud project I maintain. We started with a simple approach: feed REST API docs to an LLM, ask it to generate a server, and connect it to Cloud-Barista.

It worked. Users could provision cloud infrastructure across 10 providers, including AWS, Azure, GCP, Alibaba, and NCP, through LLM clients. It felt like an early glimpse of the Vibe Computing I had imagined.

But the first success was incomplete. The server misused APIs, burned tokens, stopped midway, and sometimes provisioned unintended resources. Imagine an agent creating 1,000 VMs with expensive GPUs by mistake. The real work began when we had to feed it better context and tame it with clearer tool boundaries, workflows, and controls.

This made Multi-Cloud Vibe Computing more concrete. It showed that a useful MCP server needs more than API coverage: context design, tool boundaries, workflow guidance, and safety controls.

This session shares lessons from building and taming an MCP server for a real-world system. It is a hands-on story of learning through mistakes and turning an API wrapper into a useful MCP interface.

10,000+ MCP servers exist. Developers can't find them. Agents can't query them at runtime. There is no canonical, vendor-neutral, machine-readable registry, and that single gap is slowing MCP adoption more than any protocol limitation.

This talk dissects the MCP discoverability crisis: why a fragmented landscape of marketplace-style lists, hand-curated JSON files, and closed vendor directories fails both human developers and autonomous agents. Drawing on the DNS, npm, and Docker Hub precedents, I propose an open MCP Registry Specification covering four layers: server schema contracts, semantic capability metadata for runtime agent discovery, cryptographic provenance attestation, and a federated hosting model any organization can self-host.

We'll walk through a working prototype of a registry server that conforms to the proposed spec, federate it with a second node live, and demonstrate a Claude agent autonomously discovering and connecting to previously unknown MCP servers via semantic query. No proprietary platform required.

This talk shares lessons from rebuilding a production LLMOps feedback system after its original pipeline architecture became too difficult to extend and operate in practice. The system was initially designed as a modular, cloud-native pipeline that handled community exercise data end to end—from collection and analysis to feedback generation and publishing. As new capabilities were added, coordinating cross-step dependencies, managing state, and evolving the workflow without breaking existing logic became a growing challenge.
To address this, we restructured the system around MCP tools. Each core function—data ingestion, exercise analysis, recommendation generation, and feedback delivery—was refactored into an independently callable tool that agents can dynamically orchestrate. We will discuss how we handled multi-step coordination without losing state, partial failures and retries across tool boundaries, observability in agent-driven execution, and secure tool interaction in a production environment. Rather than presenting an idealized architecture, this session focuses on what changed in practice: what worked, what didn’t, and what we would do differently.

Building an MCP server is easy to demo and hard to operate. Once a server sits between an agent and real systems, questions about transport choice, cancellation, timeouts, concurrency, schema evolution, and tool safety show up fast.

This talk walks through building a production-minded MCP server in Go. It covers how to model tools and resources with Go types, choose between stdio and HTTP-based transports, handle concurrent tool calls without shared-state bugs, and add logging, metrics, and failure boundaries that make incidents debuggable. It also compares the current Go MCP landscape: the official Go SDK, community libraries like mcp-go, and what the emerging ecosystem still lacks compared to the Python and TypeScript stacks.

The examples come from MCP server patterns for CI/CD and platform workflows, where reliability matters because the server sits in the critical path between an AI agent and deployment infrastructure. Attendees will leave with a concrete set of patterns for shipping Go-based MCP services that are reliable enough for production, not just demos.

MCP servers today are blind to the client's context budget. In production, we watched a single list call return 161k tokens. Tool schemas alone consumed 37% of a 200k context window. One customer's sprint data retrieval filled 80k+ tokens and collapsed the agent's reasoning entirely. Organizations with heavy custom fields caused tool schemas to balloon unpredictably.
These aren't edge cases - they're the default experience at enterprise scale. The MCP protocol currently has no mechanism for servers to understand or respect context constraints. Every response is a best-effort data dump.
This talk presents real production telemetry from building and operating an enterprise MCP server, then proposes three protocol-level mechanisms the community should consider: context budget hints from client to server, progressive tool disclosure so agents discover tools as needed rather than loading everything upfront, and server-side response compression conventions. We'll share an open reference implementation of progressive discovery that reduced effective schema size by 70%.
The goal: move this conversation from "each server figures it out alone" to "the ecosystem has shared conventions."

Most standard RAG pipelines treat data retrieval as a blunt instrument: run a basic search and stuff the context window. At Elastic, we used the Model Context Protocol to build a much smarter, agent-driven retrieval system. In this talk, I’ll show you how we built our MCP server to focus on dynamic context engineering rather than hardcoded pipelines.

I’ll break down our strategy of giving agents atomic tools to inspect the data environment first. By exposing capabilities like list_indices and get_mappings, the agent gathers the exact schema context it needs before writing and executing complex ES|QL or Query DSL.

If you are building an MCP server for your own databases or APIs, I’ll share how this "discover first, search second" approach practically eliminates query hallucinations and creates a highly reliable retrieval loop. You'll walk away with a proven strategy for engineering better context and building smarter data retrieval into your own MCP systems.

AI agents interact with enterprise systems through three different traffic patterns, each demanding its own governance. Inbound API traffic (REST, GraphQL, gRPC, event streams) needs auth and rate limiting. Outbound LLM traffic needs multi-model routing, token-based cost controls, and guardrails. Agent-to-tool traffic via MCP needs session-aware governance, delegated identity, and discovery.
Most organizations handle each ad hoc with different proxies, custom middleware, ungoverned direct connections. The result: policy fragmentation, identity silos, and cost blind spots.
This talk presents a three-gateway architectural framework. We define the API gateway (ingress), LLM gateway (egress), and MCP gateway (agent-to-tool) as composable patterns with distinct governance primitives, then show how they unify into a bi-directional architecture with shared identity (OAuth2), consolidated observability, and consistent policy.
Technology-neutral and standards-based: OpenAPI, AsyncAPI, MCP, and OAuth2. You'll leave with a decision framework for which pattern governs which traffic flow — and how to avoid building three separate governance silos.