MCP Dev Summit Seoul 2026

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.

Using AI efficiently begins with the outcome—but model choice is only one part of the design decision. As coding agents become more capable, teams must also decide when an agent should explore and generate code, when a validated method should become a reusable template, when a fixed application only needs an API, and when multiple agent experiences justify a shared MCP interface.

Drawing on recurring questions from the Codex developer community, this session connects two examples. An early-stage Science Agent Leaderboard project from the PseudoLab community illustrates how agents can build executable solutions, and why generated work must be evaluated for correctness, cost, and reproducibility rather than judged by the answer alone. A public, synthetic rare-defect analytics example then shows how a data-science method can move from Codex-assisted exploration to evaluation, human review, versioned code, and reusable templates.

The session concludes with an illustrative air-gapped architecture in which fixed analytics applications use APIs, while on-prem coding agents and analytics chatbots can access selected, validated capabilities through a small MCP surface.

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.