MCP Dev Summit Bengaluru 2026

MCP demos are easy. Production MCP is not.

Once a remote MCP server touches real data or privileged actions, a successful tool call is not enough. Teams need OAuth 2.1 done correctly, least-privilege scopes, protected resource metadata, audience-bound tokens, secure session handling, gateway-aware controls, and audit trails that explain who requested what and what the server actually did.

This session turns MCP’s security guidance into a practical production blueprint. I’ll walk through how to secure remote MCP servers end to end: when authorization is required, how to avoid token passthrough and over-broad scopes, where session isolation fails, what proxies and gateways must enforce, and what to log for debugging, compliance, and incident response.

Attendees will leave with a clear mental model, a reference architecture, and a concrete checklist for operating MCP clients, servers, and intermediaries safely in production.

This is not just about Admiral Group PLC but for every organisation, tool schemas in MCP evolve as platforms change parameters get renamed, new required fields are added, response shapes shift. Agents built against an older schema break silently, produce incorrect results, or enter undefined behavior, and there is no established SemVer discipline for MCP tools today. This session proposes a practical versioning specification for MCP tool definitions covering additive-only change policies, explicit deprecation signals embedded in tool metadata, capability negotiation via request headers, and client-side schema compatibility layers. The session demonstrates these patterns with a real Kubernetes tool server that ships v1 and v2 tool definitions side by side, with running agents targeting each version independently, and a live migration showing how a breaking change is introduced and absorbed without downtime.

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.

Over the last few months I've built and shipped 100+ agents in public, many wired into MCP servers running against local models through Ollama, LM Studio, and decentralized open-source inference. A draw.io MCP server driven by Llama 3.2, an Excalidraw MCP integration, a Bright Data MCP briefing agent, all running end-to-end without a single token leaving the host.

This talk is a working engineer's tour of that stack. We'll walk through a minimal local MCP setup (server + client + Ollama) and then dig into the real-world failure modes: tool-selection collapse on 7B models, JSON-schema compliance gaps, capability-negotiation mismatches, and the surprisingly large quality delta between structured-output fine-tunes and general chat models. I'll share the prompt shapes, tool-description patterns, and schema-validation tricks that reliably push small open models from "demo-grade" to "I'd ship this internally."

Attendees will leave with a reference architecture for private MCP, a shortlist of open models that actually handle tool calls well today, and a set of design patterns for MCP servers that degrade gracefully when the client LLM has 8B parameters instead of a trillion.

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.

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.

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.

Building an AI sales assistant means pulling data from everywhere , Salesforce for accounts, Snowflake for product catalogs, and internal KBs for pricing. We started by hardcoding each integration into the agent. It worked until every new data source meant rewriting agent code, duplicating auth logic, and redeploying everything. Tool definitions were tightly coupled, making it impossible to evolve the data layer independently.MCP changed everything. In this talk, I'll walk through how we built a production AI sales assistant using LangGraph connected to multiple MCP servers ,each wrapping a different backend, owned by a different team. I'll cover: why direct integrations become unmaintainable at 3+ sources; our reusable FastMCP server template that spins up domain-specific servers in days; how a user's SSO token flows end-to-end from agent through MCP to Snowflake OAuth with zero credential storage; why tool descriptions and agent prompts matter more than the protocol itself , and the patterns we developed (normalize-before-search, dynamic prompt injection) to make the LLM reliably pick the right tool; and what broke in production with real failures and real fixes.

Your MCP server works. Every tool call executes. But do you know who made that call, whether they were allowed to, and whether it should have required a human to approve it first?

Most MCP servers today operate on implicit trust. If an agent can connect, it can run anything - usually without any identity checks, boundaries, or logs. That works in dev. In production, a misconfigured agent or a prompt injection can trigger your most sensitive tools with nothing to stop it.

This session makes the path from 'working' to 'governed' concrete: authenticating agents via OAuth, enforcing per-tool authorisation, and adding human-in-the-loop approvals for high-stakes actions. Live demo: we’ll take an unauthenticated agent, lock down the server, and hold a sensitive call for approval with a full trace on exit.

MCP connects agents to your most important systems; it’s time we started checking their IDs at the door.