MCP Dev Summit Seoul 2026 ranged from tool design and security to mobile, robotics, video, and ML systems, but several engineering questions kept resurfacing across the tracks. These five themes connected some of the strongest examples from the conference.
Some sessions were presented in Korean and are marked below.
Choose the interface for the outcome
Several speakers started one step earlier, with whether the workflow needed MCP at all.
Challenging the assumption that MCP should be the default whenever an agent needs a tool, Daniel Oh argued that one agent calling one tool may already have a shorter path through function calling, while MCP can add network, token, security, and maintenance costs.
From the workflow side, Junho Kong (Korean and English) mapped different kinds of work to code, reusable templates, APIs, workflow engines, and MCP. APIs can suit known callers, workflow engines can provide state and control, and MCP becomes useful when AI applications need standardized discovery and invocation across systems.
For Dale Seo, how often information changes provided another useful dividing line. Live capabilities and frequently changing information are a natural fit for MCP, while stable procedures and guidance can often live in skills.
The choice comes down to what the workflow needs to do, how often its information changes, who needs to discover it, and how much control or state it requires.
Keep the tool surface deliberate
Choosing MCP still leaves another design decision: how much capability should the agent see?
One concrete example came from Nimit Savant and Gokul K S, whose MCP surface had grown to 40 overlapping object-specific tools. Grouping those into intent-level contracts reduced the number to 14 and gave the agent fewer similar choices to distinguish between.
In a second session, Nimit Savant and Gokul K S took the same principle into the context window. Tool search, progressive schema disclosure, and server-side response filtering can keep unused schemas and large raw responses away from the model until they are needed.
A different route came from Bhumika Satpathy, who used Code Mode to expose a smaller tool surface and let the model compose executable steps, while bulk processing, loops, retries, and transformations run inside a sandbox.
The same issue appears when the number of servers grows. At Naver Cloud Platform, Jihye Kim (Korean) described a move from individually generated MCP servers toward a gateway that can search a larger catalog and expose relevant tools.
Across those approaches, the agent gets the capability and context needed for the current task rather than carrying the full catalog through every interaction.
Security has to survive change
A tool can pass an initial review and still become unsafe later, as the Postmark MCP case used by Arshardh Ifthikar showed. A later server version added code that copied emails to an attacker's address, so approval at installation time did not protect against later changes to code, descriptions, or outputs.
That puts more emphasis on controls around each action.
With Aram Andreasyan, externalized policy affected both tool discovery and invocation. Decisions could include the user's identity, the tool being called, its arguments, limits, and the work assigned to an agent.
Jorge Ruiz Arto followed that identity chain from the user through an MCP proxy to the backing API, applying policy around the actor, action, and resource at tool level.
Server approval, tool discovery, authorization, arguments, and downstream API access therefore have their own decision points. Keeping those controls separate allows permissions to be checked as the system changes around the agent.
Production needs evidence at every layer
Once an MCP tool can change something outside the model, a successful response is only part of the operational picture.
Testing in Navin Pai's session looked much like testing elsewhere in software: unit tests, Inspector checks, conformance tests, property-based fuzzing, linting, and LLM evals combined into a suite that can run as tools change and on every server commit.
For ML-backed tools, Sho Tanaka focused on whether operators can explain what produced a result. His four checks cover the request, execution, result, and identity, including which server, model, and model version were involved.
Another failure mode appeared in Sunyoung Park's incident-triage example. An early flow could recommend moving traffic without collecting enough evidence first. The revised design put that judgment behind a structured execution boundary, where the system gathered the required signals before returning an action.
In each case, the MCP call is only one part of what needs to be checked. Operators also need evidence about inputs, execution, outputs, models, policies, and external state if they are going to diagnose failures and review actions later.
New environments bring new constraints
Some of the Seoul sessions pushed MCP into environments that look quite different from a conventional backend integration.
On robotics, Anshuman Singh connected an agent to an SO101 arm and added camera input so its actions could respond to the surrounding environment instead of relying only on fixed commands.
Mobile brought a different set of constraints. Sasha Denisov showed that phones can work comfortably as MCP clients, while hosting a server on-device has to account for sandboxing, foreground and background execution, networking, and secure reachability.
Video added long-running jobs and visual output to the mix. Kyle Cabigon covered ingestion, queries across a video corpus, and rendering results so an MCP interaction can return playable evidence rather than reducing everything to text.
Infrastructure operations gave another angle. HyounKyoung Moon (Korean) used MCP Apps to bring resource inspection into the agent conversation, allowing an operator to identify idle and old resources, inspect activity, and decide what should be removed without moving through several dashboards.
The common protocol stays the same, but a phone, robotic arm, video system, and infrastructure console each bring different requirements around execution, context, security, and interfaces.
Full recap list
A recap of all 43 sessions from MCP Dev Summit Seoul 2026, is available here.
More to come in North America
Some interesting ideas came out of Seoul, with more to come at AGNTCon + MCPCon North America in San Jose, October 22–23. Keynotes include MCP co-creator David Soria Parra, UC Berkeley’s Dawn Song, Tim O’Reilly, and more.
Share
Author
