MCP Dev Summit North America

The AI hype cycle promised full automation. Reality delivered hallucinations and agents that guess when they should ask. The MCP spec offers a different vision—humans in control through rich, interactive collaboration rather than micromanaging every step.

This talk explores how recent MCP primitives transform the protocol from text-in-text-out tool-calling into interactive human-agent workflows. We'll cover elicitations that let servers ask clarifying questions with structured forms, async tasks that pause for human decisions and resume seamlessly, and MCP Apps that render interactive UIs—charts, dashboards, confirmations—in sandboxed iframes. Each makes feedback loops faster and agent interactions richer.

Using VS Code's implementation as reference, we'll demonstrate patterns for adaptive autonomy, progressive input gathering, and bidirectional workflows where servers drive the conversation. You'll leave with concrete patterns for building MCP integrations that treat collaboration as a feature, not a fallback.

While it is now considered a best practice for agent skills to leverage MCP servers, there is still no widely accepted approach for how those MCP servers should be distributed, versioned, and shared as dependencies.

This talk presents a practical pattern for using OCI artifacts as a distribution mechanism for MCP servers and configurations that agent skills depend on, enabling reproducible, shareable, and composable agent capabilities.

We’ll walk through creating an agent skill that can build and run an MCP project as a containerized service, then publish supporting artifacts such as the MCP server’s configuration.

Rather than bundling dependencies directly, the agent skill references an OCI artifact by OCI ref, pulls it at runtime, and activates the required MCP servers automatically. This ensures that when prompts expect specific MCP servers to be available, they already are.

By treating OCI as a universal distribution layer for agent tooling metadata and configurations, this approach makes agent skills easier to share, reproduce, and evolve across teams and environments.

Agentic systems adopting MCP face a scalability hurdle: managing interactions with numerous servers exposing dozens or hundreds of tools. Injecting all tools into the model context, or "context bloat," increases latency, inflates context window usage, drives up costs, and degrades reasoning quality.

This session introduces the MCP Gateway pattern, an architectural solution to context bloat. This pattern uses an MCP-aware routing layer to dynamically select and inject only the tools semantically relevant to a user request.

We will detail the design and implementation of semantic tool routing utilizing intent classification, embedding-based search, and lightweight prompt analysis. The talk will cover how this routing layer interacts with multiple MCP servers, maintains protocol correctness, and enables just-in-time tool discovery without overwhelming the model.

Attendees will receive a practical blueprint for building scalable, cost-efficient, and modular agentic systems based on MCP. The session emphasizes reusable patterns and reference architectures applicable across the broader MCP ecosystem, independent of any single vendor or runtime.

Before MCP, Arcade was building tools for LLM agents. We've shipped over 1,000 tools—first as native Arcade tools with our own protocol and eventually adopting MCP. The main lesson: the hard part isn't writing the code, it's finding the right abstraction.

Most MCP tools today are thin wrappers around APIs. `GET /users/{id}` becomes `get_user(id)`. But this creates a mismatch—LLMs reason about tasks ("find the customer who complained last week"), not endpoints. The question is: where should tools sit on the abstraction spectrum?

**Too low-level:** The agent needs to chain together many calls. Each step is a chance to fail, and the model has to maintain context across all of them. You're asking the LLM to be a programmer at runtime.

**Too high-level:** You end up enumerating every possible task as its own tool. This defeats the point of having a general-purpose agent and your tool schema balloons, eating context and degrading selection accuracy.


In this talk:

- The common pitfalls we see in MCP tool design
- Our design philosophy for optimized tools
- Multiple real-world use cases and the tools that work for them
- Outlook on future tool development

Here's a scenario that might sound familiar: you've got ten MCP servers, which means ten client connections, ten auth flows, and ten different places where things can break. One reason teams end up in this mess is that each MCP server solves a real problem - so you add another one, and another, and suddenly you've got MCP sprawl.

Enter the MCP Gateway pattern.

In this talk, we'll walk through an architecture that aggregates multiple MCP backends behind a single unified interface. We'll cover the fun problems this creates - what happens when two backends expose tools with the same name? and show how declarative workflow composition lets you orchestrate multi-step operations across backends without writing custom wrapper code.

We'll demo a gateway unifying several backends and executing a workflow defined entirely in YAML. No magic, just patterns you can apply to your own infrastructure.

With this in mind, you'll leave with practical approaches to taming MCP sprawl while keeping your security policies consistent across the board.

While frontier models achieve impressive scores on benchmarks like MCP Atlas (62.3%) and SWE-bench (62.1%), these metrics don't answer the critical question: "Will this agent work for OUR specific use-case?"This talk presents a practical framework for building custom agent evaluation systems tailored to your organization's needs. We'll cover the complete lifecycle: data collection and categorization, open-source instrumentation patterns, and production monitoring for long-term performance tracking. You'll learn to construct evaluation datasets reflecting actual workloads, implement testing harnesses mirroring production constraints, and establish monitoring pipelines that catch degradations early.We'll demonstrate techniques for measuring agent reliability across accuracy, latency, cost, and safety dimensions while accounting for real-world variables: prompt engineering, data quality, MCP tool availability, and model selection. Attendees will leave with actionable strategies to build confidence in production deployments and create feedback loops for continuous improvement.

As MCPs are adopted at scale, certain patterns start to emerge:
1. Increase in wrong tool calls
2. increase in token usage, semantic loss
3. agents skipping the required tool call sequence.

For high stakes domains such as finance and infrastructure, this leads to reliability and compliance risk.

This talk presents a new MCP server design pattern for addressing this class of problems called: "progressive tool exposure".
Rather than assuming static tools, the MCP server actively controls which tools are visible to the agent at each point in execution. This framework ensures, tools are refreshed, scoped, and changed as the agent progresses through an MCP workflow. This allows the server to direct the agent’s action space, guide execution order, and enforce "runbooks" without changing server/ agent capability. This design pattern also tracks state ensuring backtracking of tool calls reverts the server side state, making agent behaviour as transactional on the MCP server.

We show how such practices reduce invalid tool calls, lower inference costs, and improve determinism for tool heavy systems.

Here's what's going to happen: MCP takes off. Hundreds of MCP servers get built. Most of them end up unmaintained within two years and then issues pile up, PRs go stale, the original author moves on.

I have spent time digging through MCPZoo, a dataset of 56,000+ MCP servers, and the warning signs are already there. Repos with READMEs that just say "install and run." Projects with one contributor and no activity in months. Issues sitting unanswered. The ecosystem is growing fast, but a lot of what's being built has "abandoned in 6 months" written all over it.

I'm sure some of you have tried contributing to these projects. Couldn't run the tests. Couldn't understand the structure. Couldn't tell if anyone was still around. That friction isn't just annoying, it's why maintainers burn out and contributors disappear.

In this talk, I'll break down what makes an MCP server thrive or die. Projects die when newcomers can't onboard, can't run tests, can't understand the structure. The ones that survive do specific things: working CI from day one, a README that gets someone running in under 5 minutes, clear contributor guidelines. I'll show you how to set up your own projects to last.

Effective context engineering via MCP servers requires understanding how host agents weave the server's responses into their context as conversations unfold.

Context flows through more channels than tool definitions alone: initial instructions, the tool set itself (explicit tools vs. generic execution tools), tool names and parameters, descriptions, response content, structure and length, error feedback, "skill-loading" tools, resources, and sub-agent delegation.

Each mechanism involves trade-offs. Eager loading of context risks bloat; lazy loading adds tool calls. Rich tool responses help agents self-correct but consume tokens. Sub-agents compartmentalize complexity, but limited client support for elicitation creates friction.

Getting this balance right means staying conscious of how much context you're injecting, when, and at what cost (e.g. in # of tool calls to achieve a goal)—a balancing act that's hard without a clear picture of what's happening inside the host agent's context window.

This talk aims at providing a framework for thinking about these decisions—grounded in concrete examples from building the MotherDuck MCP Server.