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.

Modern observability stacks make it easy to collect telemetry, but not to derive value from it. Teams accumulate unused metrics, high-cardinality signals, and noisy dashboards, leading to rising costs and poor signal quality.

This talk introduces a practical mental model inspired by the Rumsfeld Quadrant to reason about observability in terms of signals we measure vs signals we actually use. In our analysis of a our Observability stack, nearly 70% of collected signals showed little to no usage, reflecting a Pareto-like distribution of signal value.

We present a closed-loop approach that we used to analyze observability metadata and continuously optimize the system. MCP was used as the coordination layer to expose metadata and connect analysis, reasoning, and action workflows.

We will walk through how low-value signals were identified, how recommendations were generated and applied in a real-world large scale observability platform.

We started building an MCP gateway in early 2025, when the spec was still maturing, and there were no established patterns for multi-tenant enterprise implementation.

This talk will delve into the key patterns we used for taking MCP from POC to Production. We'll also cover layering MCP as a gateway over an existing platform:

- Propagating tenant context through the MCP handshake, so a single gateway can safely serve thousands of accounts.
- Decoupling session state from pod affinity with a distributed session store — needed for horizontal auto-scaling and safe rolling deploys.
- A three-tier error model (protocol/gateway/application) so agents classify failures and retry intelligently.
- A sub-registry that extends the registry with vetting and curates trusted Remote MCP servers with per-tenant install state.
- Multi-tenant session and secret management with One-click install and OAuth 2.1 + Dynamic Client Registration handled by the marketplace, not by every AI client.
- MCP gateway that proxies to remote servers under shared FUP, rate limits, retries/circuit-breaking, and analytics - handling a black-box third-party server with guardrails.

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.

When we moved our multi-agent MCP system from REST to stdio transport, the protocol schema was not the problem. OS pipes have no safety nets.

When a model silently segfaults mid-inference, it does not send a JSON-RPC error. It just dies. The orchestrator sits blocked on a stdout.readline(), which never comes.

Then we hit the pipe buffer deadlock.

Inference engines are noisy. They dump token speeds and debug logs to stderr. If the orchestrator is waiting on stdout and ignoring stderr, the OS pipe buffer fills up to 64KB. The OS physically halts the model. The orchestrator waits for the model to finish. The model waits for the orchestrator to clear the pipe. Nobody moves.

To fix it we had to build async wrapper classes that continuously drain stderr into background loggers.

This talk covers what we learned:

- Draining stderr continuously or your process dies silently
- Managing SIGKILL and EOF lifecycles to flush sensitive data from RAM
- Replacing HTTP timeout assumptions with OS process management

If you are running MCP over stdio, this talk is the process management guide the MCP ecosystem has not written yet.

Platform engineering has a chicken-and-egg problem: the platform needs adoption to justify investment, but adoption requires onboarding that teams resist when deadlines are tight. Our internal developer platform hit this hard. It serves 4,000+ developers across clouds and managed Kubernetes, yet many teams found the portal too unfamiliar.
We solved it with a second entry point built on MCP. Instead of learning a new UI, developers get 30+ platform capabilities directly in IDE chat, from namespace provisioning and Helm deployments to cost analysis and access management. An MCP App renders forms in chat, developers approve and execute, and a first deployment can happen with almost no onboarding.
This session covers the production architecture: sandboxed iframe-based MCP Apps, Elicitation for structured write approvals, an Adaptive Tool Router that keeps 30+ tool schemas from flooding the context window, a split between deterministic Agent Skills and ReAct reasoning, and a safety layer with a sub-500ms kill switch plus delegated RBAC tied to existing permissions. Attendees leave with a practical blueprint for meeting developers where they already work.

Scenario: Deploy an agent to production. Works 90% of time in testing. Month later: Claude model updates. Success rate drops to 70%. Why? Model change altered how tools are ranked.
You can't see this. You have no control. Your agent silently degraded.
This talk identifies sources of divergence:

Temperature/sampling: Agent with temp 0.7 calls Salesforce 60% of time. Temp 0 calls it 95%.
Model version: Claude 3.5 favors Salesforce (in training data). Opus 4.5 favors email (newer training). Same task, different choices.
Context truncation: Tool listed first in window = primacy bias (70% called). Tool listed last = recency bias (30%).
Tool schema order: Tools listed alphabetically vs. semantic order (query before create) changes success rate 25%.
Schema verbosity: Detailed descriptions make tools more likely to be selected than sparse ones.

Then proposes solution: Agent fingerprinting. Create deterministic test suite capturing baseline behavior. Before deploying new model/agent version: run fingerprint suite. If success rate drops 10%+, alert. Don't deploy.

Everyone's heard the AAIF framing: MCP handles agent-to-tool, A2A handles agent-to-agent. Clean in theory. In practice, every multi-agent system lives at the boundary of both, and that boundary has no standard.
Context gets dropped. Errors go silent. A state that survived an entire A2A task lifecycle vanishes the moment it crosses into an MCP tool call. Nobody is talking about this publicly.
This session replaces the "vertical vs horizontal" mental model with something more honest: a precise seam diagram showing what each protocol guarantees, what it doesn't, and what falls into the gap. We'll go deep on MCP's Tasks primitive (SEP-1686)- including its two admitted gaps: no retry semantics, no expiry policies. We'll map the real failure modes developers are hitting today, drawn from open GitHub issues across both protocol repos.
Then a live demo using Google's open-source A2A sample repo: no custom code. We'll run a real multi-agent task, cross the protocol boundary, sever the trace header, and watch the silent failure happen in real time.
You'll leave with a clear mental model, a three-point failure checklist, and a concrete picture of what the spec needs next.

MCP's real power lies not just in what it defines, but in what it leaves room for. As teams push MCP into production, the need to add custom capabilities streaming responses, domain-specific metadata, proprietary auth flows runs headfirst into the risk of breaking existing clients and servers.
This talk walks through the practical discipline of extending MCP without fracturing compatibility: how to use capability negotiation correctly, where to extend vs. where to fork, how to version custom extensions gracefully, and how to contribute extensions upstream without waiting for a spec cycle.
Real examples from building extensions in the wild what worked, what silently broke things, and what the spec doesn't yet have a good answer for.
Attendees leave with a working mental model for extension design and a checklist for evaluating whether a custom extension is safe to ship

Jupyter notebooks are essential for AI agents, yet the .ipynb JSON format is token-heavy and fragile for LLM manipulation. While an MCP server seemed like the obvious solution, we instead built nb—an open-source Rust CLI designed for agentic workflows.

This talk explores the design decisions behind nb and our move away from standard tool schemas:
- The Sentinel Format: Why line-oriented @@cell and @@output sentinels outperform deeply nested JSON for agent comprehension.
- Token Efficiency: How a single 800-token skills file replaced a complex MCP implementation, drastically reducing overhead.
- Content Hashing: Using SHA256 to solve output externalization and state management.
- Real-time Sync: Demonstrating collaborative editing via Y.js when bridged to a Jupyter server.

We’ll share benchmarks on task completion rates and token costs, and provide a clear framework for choosing between MCP servers and CLI-based skills. Attendees will learn when to leverage the simplicity of a CLI and when MCP’s multi-tenant auth and discovery are truly necessary.