MCP Dev Summit Bengaluru 2026

Most MCP servers are one-shot: the client asks, the server answers. But some features need the server to reason mid-execution like summarise a diff before returning it, classify input to pick the next step, recover from ambiguity instead of failing, generating new data. That's what sampling unlocks: the server calls back into the host's LLM, without ever holding its own model keys.

This deep dive walks through sampling/createMessage feature provided by the mcp protocol and its internals messages, modelPreferences, includeContext, systemPrompt — and what the client is actually allowed to modify. We'll cover capability negotiation and the human-in-the-loop approval flow, then step through how sampling patterns are actually built in the smartbear-mcp server, using its implementations over there to understand how one could build their own sampling features.

Then the hard parts: agent loops, token-budget blowups, portability across clients using different model providers.

You'll leave knowing when sampling beats tools or elicitation, and with patterns you can lift today.

As the Model Context Protocol (MCP) matures, we face a critical security hurdle: how do ambient agents that are running in the background or on headless devices securely access sensitive resources without constant manual intervention?

Standard OAuth flows often break the "ambient" experience by requiring immediate browser redirects on the same device. This session proposes a decentralized identity architecture using Client-Initiated Backchannel Authentication (CIBA). By decoupling the consumption of resources from the authorization flow, an MCP client can trigger a "just-in-time" permission request directly to a user's trusted mobile device.

Key Takeaways:
- Decoupled Auth: Implementing CIBA to bridge the gap between headless MCP clients and human controllers.
- Just-in-Time delegations: Moving from "all-or-nothing" API keys to granular, session-based permissions.
- Security Patterns: Handling asynchronous "Out-of-Band" callbacks within the MCP lifecycle.

Join us to explore how we can make background agents both powerful and respectful of the "human-in-the-loop" principle.

At NetoAI we build AI agents for telecom network operations. Our Rapid Root Cause Analysis Agent, built on our open-source TSLAM models (22k+ HF downloads), runs against live operator networks.

When we moved to MCP as the tool-interface layer, agents that passed eval started breaking weeks after production launch. The model, prompts, retrieval, none were root cause. The tool environment itself was.

So we built a digital-twin simulation of our production telecom domain and stress-tested MCP agents across four axes:
1). tool-set scale
2). task complexity
3). persona variability
4). deterministic repetition.

Tool-selection accuracy is near-perfect up to ~20 exposed tools, then collapses. One bad early dependency step cascades the whole workflow.

I'll walk through the seven failure patterns we kept hitting, including Tool Selection Collapse and Cascading Fragility, the three architectural root causes behind them, and the task-scoping and dependency-aware fixes that worked. You leave with a pre-launch methodology for your own MCP servers vendor-neutral, applicable to any dependency-dense domain.

In 2013, shipping a Python service meant picking a base OS, writing an initscript, and fighting pip against the system package manager. Docker made it one command. Twelve years later, shipping an MCP server still feels pre-Docker — pick a language, spin up a process, hope the dependencies cooperate.

The WebAssembly Component Model quietly shipped the pieces it was missing in 2023. wasmcp, Microsoft Wassette, and Fermyon Spin now compose a single MCP server from Python tools that use pandas, TypeScript tools that use Zod, and Rust middleware that uses Regorus. One process. Hard isolation between components. One signed artifact, distributed through OCI registries, cold-starting in the low milliseconds.

This is a live-demo talk. I'll build a polyglot MCP server on stage, push it to a registry, and run the same bytes in four environments — a Kubernetes pod, a Spin function, a browser tab, and a Raspberry Pi. And I'll be honest about what WASM still can't do.

As the ecosystem for the Model Context Protocol (MCP) expands, developers are hitting a familiar wall: token bloat. While MCP provides a powerful standardized interface for LLMs to interact with external data, the "context tax" of verbose tool definitions and massive data payloads can quickly degrade performance and spike costs. To build production-ready agents, we must move beyond basic implementations and embrace advanced orchestration.

This session dives into the architecture of efficient MCP server design, focusing on the "Code Mode" technique. We will explore how to shift the heavy lifting from the LLM’s reasoning space to the server’s execution environment. Instead of forcing the model to process raw, unrefined data, "Code Mode" empowers the LLM to generate and ship logic—miniature, execution-ready scripts—directly to the MCP server. This approach minimizes round-trip latency and drastically reduces the input tokens required for complex data manipulation.