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.

We built an MCP server exposing 40+ operations. Agents misused most of them. Hybrid search returned only IDs with no context. get_issue prefixed every field with redundant key-value labels, burning tokens without helping the LLM. We had write tools with no corresponding read tools. Custom field schemas varied wildly across organizations, causing unpredictable bloat.
We cut to 14 tools. Agent precision improved dramatically. But deciding which 14 - and how to design them - required building a framework we wish had existed when we started.
This talk shares that framework as an open, reusable methodology any MCP server author can apply: how to audit which tools agents actually select vs. misuse, how to score agent success rate per tool, how to identify tools that confuse rather than help, how to structure response shapes for minimal token cost and maximum agent comprehension, and how to design progressive disclosure so capability scales without overwhelming context.
Every team building an MCP server faces this decision. We'll give them a starting point so they don't have to learn it the hard way.

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.

As MCP and open source agentic stacks transition into production infrastructure, developers are navigating a completely new paradigm of challenges. In this fast-paced, interactive Ambassador Office Hours, newly appointed Agentic AI Foundation (AAIF) Ambassadors from across the globe take the stage to share raw, unvarnished insights from the front lines of agentic AI adoption.

The Ambassador Office Hours will dive straight into the practical realities of building with AAIF projects (e.g., MCP, AGENTS.md, goose, and agentgateway), uncovering what it takes to move past basic LLM orchestration into production-ready agent environments. The ambassadors will break down their biggest learning curves, systemic integration challenges, and the architectural shifts required by the latest protocol standards.

The final half of this rapid-fire session opens the floor entirely to you for a highly interactive, crowd-sourced Q&A with the AAIF Ambassadors. Leave with actionable tactics to accelerate your own agentic roadmap.

Most teams start with MCP by exposing existing APIs as thin tool wrappers. We did too. However, we quickly realized that for complex operations-like managing GPU clusters and infrastructure health-simply exposing more tools doesn't lead to better automation; it leads to LLM confusion. The real challenge is defining the right reasoning and execution boundary.

In this talk, we share our journey of moving beyond simple API exposure to building MCP servers that act as a sophisticated operational layer. We'll dive into how we transformed fragmented signals into 'Structured Guidance' by embedding domain heuristics and workflow context directly into the MCP layer.

Attendees will learn:
- how to recognize when MCP is acting as a thin wrapper versus a real workflow boundary
- how to design MCP on top of existing operational or management systems
- how to turn fragmented tools, signals, and internal APIs into structured guidance for real-world workflows

This session is a practical story about where MCP becomes more than an integration layer: when it starts acting as the execution boundary for real-world operational decisions.

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 3 strategies to solve the context constraints at enterprise scale which community should consider: progressive schema disclosure, server-side response projections, SQL based tools for multi-object queries. 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."

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.