MCP Dev Summit Bengaluru 2026

Modern MCP applications depend on tools to extend model capabilities, yet tool interface design is a primary source of unreliability. Ambiguous descriptions, poorly structured schemas, and inconsistent outputs often lead to incorrect tool selection, invalid inputs, and unpredictable system behavior.

This session introduces a practical framework for designing reliable MCP tools. We begin with a concise mental model of how language models interpret tool interfaces, followed by real-world failure scenarios that expose common design pitfalls. Building on this, we present design principles for clear naming, well-defined schemas, and structured outputs, along with patterns for creating predictable and composable tools.

The session concludes with a practical checklist and actionable guidelines that attendees can immediately apply to improve reliability, reduce debugging complexity, and build robust MCP applications in production environments.

We had 47 runbooks in Confluence. During incidents nobody used them. So I converted them into MCP server tools where an agent picks the right steps based on what it sees in the cluster.
This was working fine until two things went wrong.
One, the MCP server had the same service account as our CI pipeline. Too many permissions. Agent went and listed every secret in the namespace. It wasn't doing anything wrong, just had access it should not have. That's when I understood MCP has no security story for infra tools.
Two, at 3 AM the agent connected two unrelated alerts, restarted the wrong deployment, and a small incident became bigger.
I fixed both. Built OPA policy gates that check every tool call before execution. RBAC is now per tool, not per server. Tokens last five minutes and expire after one action. After the 3 AM incident I added blast-radius checks and human approval for destructive operations.
In the demo I walk through an agent diagnosing a pod failure, clearing policy, running with a scoped token, and logging an audit trail. Then it tries something it should not and gets blocked.
This talk is about what it actually takes to give an agent kubectl access safely.

This session introduces InstaMCP, a common platform designed to instantly "MCP-ify" enterprise APIs and eliminate the need for redundant "glue code" currently required to connect LLMs to internal products. This solution addresses siloed AI integrations and maintenance bottlenecks within large SaaS ecosystems. InstaMCP automatically ingests Swagger/OpenAPI specifications to generate fully deployable, secure Model Context Protocol (MCP) servers in minutes. It moves beyond simple 1:1 API mapping by providing a visual, low-code interface for developers to stitch multiple APIs into complex, multi-step workflow tools for seamless agent execution. Attendees will explore the platform's architecture, automated MCP server generation, and how it addresses the critical "security blindspot" by accommodating token-exchange and other guardrails.

As the Model Context Protocol (MCP) matures, enterprises face a "Connectivity Gap": the $M \times N$ integration problem has shifted from a development crisis to an operational one characterized by context window bloat and fragmented identity management. While the protocol simplifies 1:1 connections, orchestrating a fleet of agents across AWS, GCP, and Azure requires a centralized intermediary to govern tool discovery and secure credential propagation. This session presents cloud-engineer-mcp, an open-source implementation of the MCP Gateway Pattern. We will dive into the technical challenges of aggregating official CSP-specific servers—AWS, Azure, and GCP—behind a single interface while maintaining high performance. The talk focuses on two core architectural innovations: Embedding-based Semantic Similarity (using local models like all-MiniLM-L6-v2) to surface only the most relevant top-K tools for a conversation, and Multi-Transport Support that allows the gateway to bridge local stdio environments (like Cursor or VS Code) with remote Streamable HTTP deployments.

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.