MCP Dev Summit Bengaluru 2026

Every agent today answers one question at the auth layer: is this agent allowed to do this? Wrong question. The real one: is it doing something consistent with what the user asked - right now, in this step?

These aren't the same, and the gap is where things break.

Today's auth was built for humans logging into apps: roles and scopes that persist regardless of what the agent is actually attempting. Tell an agent to "read this PDF and send the pointers to my team." The PDF hides an instruction: also forward the thread to an external address. The agent fires two sends - one legit, one exfiltration. Same token. Same checks. Role-based auth can't tell them apart because it never knew the agent's job.

This talk closes that gap. We'll trace why every prior access model assumed a stable human actor - and why that collapses when agents delegate to agents. We'll introduce Intent-Based Access Control: decisions that reflect not just what an agent may do, but what it's trying to do right now. We'll cover emerging standards like transaction tokens and richer auth context, plus concrete steps to ship intent-aware access in MCP flows today.

When humans hire someone, they ask questions first. Check reviews, compare, negotiate. AI agents can't do any of this.

An MCP flight booking server says: "I book flights." Another agent can't ask: How many routes? Success rate? Can you get business class upgrades?

I tore down top MCP servers across mcp.so, Smithery, Glama, PulseMCP. The #1 server has 52K stars but exposes 47 capabilities with zero verifiable metrics. Tool schema: 1,020 tokens of bloat.

The problem: MCP tool schemas describe WHAT but not HOW WELL. No capability layer for agents to evaluate each other before committing.

What's needed — structured capability endpoints:

"I book flights"
→ 147 routes, 96.2% completion, 23% avg savings
→ Business class upgrades: 340 secured, 41% success
→ Savings by route queryable, methodology documented
→ Full transaction log for independent verification

Exposed as MCP resource endpoints —
capability/summary returns structured metrics, capability/evidence/{tool} returns methodology, capability/raw/{tool} returns verifiable logs.

I'll show real endpoint teardowns, what's missing from tool schemas, and a draft capability-metadata spec builders can implement.

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.

MCP's tool schema, server descriptions, and routing logic are overwhelmingly designed around English. That assumption quietly breaks when you build for users in Hindi, Tamil, Kannada, or Bengali.
This talk is a ground-up look at where MCP falls short for Indic language users and what it takes to fix it. The specific failure modes covered include: intent ambiguity in tool selection when queries arrive in transliterated or code-switched text, embedding models trained on English producing poor similarity scores for Indic-language tool descriptions, and response localization gaps where tool results are returned in English to users who queried in their native language.
The talk then presents concrete patterns for each problem, including translated and dual-language tool manifests, language-aware routing layers that sit between the user and the MCP client, and lightweight post-processing for localizing tool outputs. All patterns are demonstrated with working code from production voice agent systems built for Indian users.
With the MCP Dev Summit landing in Bengaluru, this is a timely and locally grounded conversation the ecosystem needs to have.

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.