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.

MCP brings structure and standardization to how LLMs interact with tools and resources—but that power comes with cost. We’ve built multiple MCP servers across different use cases, and not all of them should have existed.
This session distills hard-earned lessons from real-world implementations: where MCP created long-term leverage, where it introduced unnecessary complexity, and where a direct API call would have shipped faster and cleaner. We’ll share a clear evaluation checklist you can use before starting your next build—so you choose MCP intentionally, not reflexively.

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.

As MCP adoption grows, tools are becoming the primary interface between agents and external systems. This introduces a new class of risks: tool poisoning, where tool definitions, inputs, or outputs are manipulated to influence agent behavior in unintended ways.
This talk focuses on practical experience identifying and mitigating tool poisoning in MCP-based systems. Early implementations often assumed tools were trustworthy, but in practice we encountered issues such as ambiguous tool descriptions, unsafe parameter handling, and outputs that could steer agents off course.
We will walk through concrete examples of how these failures surfaced, and the patterns that proved more reliable. This includes validating tool contracts, detecting anomalous inputs and outputs, constraining tool usage, and introducing safeguards around execution flow.
Rather than proposing a single framework, the session presents a set of techniques that can be applied incrementally to existing MCP setups. The goal is to help teams better understand how tool poisoning occurs in real systems, and how to design MCP tools that remain predictable and safe under agent-driven use.

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.

Traditional AI implementation relies on "tool sprawl": manually wrapping every API action into custom functions. This creates a maintenance burden where prompts swell, tokens vanish, and agents hallucinate under the weight of excessive choice. At Postman, we’ve shifted the paradigm: instead of teaching agents how an app works, we provide them with structured context they already understand through the MCP.

This session moves beyond theory to demonstrate a live "AI Readiness" workflow using Postman’s native Git integration. We will pit a well-defined OpenAPI schema against a poorly designed one to visualize the "Context Tax" - showing how architectural debt leads to 2x higher token usage and fumbled execution. By leveraging Postman’s MCP Server generator and CLI SDKs, I’ll demonstrate how to transform static documentation into active "code skills" that agents like Claude can navigate autonomously. Attendees will learn to build APIs that don't just return data, but serve as high-fidelity maps for the next generation of autonomous agents.

When an MCP server exposes documentation.search and documentation.fetch, its docs site quietly acquires a second reader: the agent. And the agent is not a small human. Humans want narrative tutorials; agents want flat, deduplicated, single-source-of-truth pages. Humans skim; agents tokenize. Humans tolerate ambiguity; agents hallucinate from it.

This talk is a field report from rewriting an MCP server's documentation to serve both audiences from one markdown source. Concrete before/after pages, real agent traces from the SuprSend MCP server (used as a case study not a pitch), the five rewrite rules that actually moved the needle on hallucination rates, and the surprising downstream effect: the human-facing docs got better too. Every rule generalizes to any MCP server with public docs.

Closes with two open questions the audience is invited to argue back at: should agent-facing docs be a separate channel? Should MCP add a "documentation" primitive at the protocol level?

For DevRels, technical writers, and MCP server maintainers who already exposed their docs as a tool or are about to.