MCP Dev Summit Mumbai 2026

MCP reached infrastructure currency in 13 weeks. CNCF took 13 months. That compression is the problem. The shared plumbing every production MCP deployment now reinvents, because no neutral open implementation exists yet, has to be built in months instead of years.

This talk maps five missing layers of the MCP ecosystem and what each needs before the protocol scales two more orders of magnitude.

1. Discovery federation. One registry lookup does not survive public, private, and vendor registries coexisting.
2. Workload identity for servers. Not user OAuth. Who is this server, who signed it, what is it allowed to do?
3. Observability backbone. OpenTelemetry semantic conventions for MCP are still draft, so every gateway ships its own trace format.
4. Health and reputation signals. When seventeen servers are named github-mcp, which one should an agent trust?
5. Metering and cost attribution. Boring, load bearing, absent from the spec.

For each layer: what exists today, where it breaks at scale, what a minimum viable open implementation needs. Attendees leave with a concrete map of which gaps are urgent, which are deferrable, and which are already being filled.

The Model Context Protocol (MCP) has fundamentally revolutionized developer velocity, allowing engineers to build and iterate complex AI agents seamlessly on a local machine. However, when moving these autonomous agents from a local sandbox into a production enterprise environment, organizations hit a sudden architectural ceiling. The local agility that fuels early-stage innovation quickly breaks under the compounding pressure of agentic sprawl, fragmented data integrations, and critical compliance requirements.

This keynote addresses the hidden architectural dimensions required to run enterprise AI agents safely and reliably at scale. Moving past individual agent scripts, we will explore why a centralized, fully managed platform is no longer a luxury, but a core system dependency. We will dive into the four essential pillars—Build, Scale, Govern, and Optimize—with a specific focus on how a managed MCP control plane provides the cryptographically-attested identity, granular gateway policies, and runtime isolation required to cross the chasm from an impressive local prototype to a secure, enterprise-grade AI ecosystem.

We ran 75 benchmark runs comparing CLI and MCP for identical agent tasks. CLI won every efficiency metric.

For the simplest task like identifying a repo's language — CLI used 1,365 tokens. MCP used 44,026. That's a 32x difference, almost entirely schema overhead: 43 tool definitions injected into every conversation, most never touched.

CLI was also 100% reliable. MCP failed 28% of the time like TCP-level timeouts on a remote server that never responded.

If we'd stopped there: use CLI, skip MCP, move on.

But that benchmark tested one scenario: a single developer automating their own workflow. Not what production agent products look like.

The moment your agent acts as your customer's employees inside their orgs, across services they control — CLI becomes a liability. It inherits your credentials. Can't scope per user, per org, or per action. There'd be no audit trail and no consent as well.

The data is real. CLI is faster, cheaper, simpler. For personal dev tools, use it.

But if you're building a product with data that belongs to someone else, CLI works in demos. You won't catch the problem until a customer asks why your agent touched their Salesforce without asking.

Most MCP servers don't break because of bugs. They break because the tool descriptions are too vague for agents to reliably pick the right tool.
Two research papers put numbers to this. A SAIL Research study of 856 tools across 103 MCP servers found 97% have at least one quality defect, 56% don't clearly state what the tool does, 89% give no guidance on when not to use it. A second study of 10,831 servers found that well-written descriptions get selected 260% more often, and fixing them raises task success rates by roughly 6 points.
Working with the Glama founder, I helped develop the Tool Definition Quality Score (TDQS) - an open source framework that scores every MCP tool across six dimensions: Purpose Clarity, Usage Guidelines, Behavioral Transparency, Parameter Semantics, Conciseness, and Contextual Completeness. Each tool gets a 1–5 per dimension with specific feedback on what's missing and why it matters.
This talk covers how TDQS was built, what scoring thousands of real servers revealed, and how server authors can use it to ship tools agents actually invoke correctly. The framework is open source and already live across Glama-hosted servers.

MCP servers introduced a new kind of client: one driven by an LLM. Unlike traditional clients, this one is non-deterministic. It can call tools in unexpected sequences, with unpredictable inputs.

We can’t reliably test how an LLM will call our tools. This makes the MCP server the only component under our control and the one that must be tested rigorously. A well-designed server is a well-tested server.

While reviewing several popular MCP servers, I found that “works correctly” often means testing happy paths and checking that tool descriptions exist.

This talk introduces a practical testing model for MCP servers. Attendees will learn how to treat tool descriptions as functional contracts in their tests, how to design tests that cover real-world and deliberate out-of-order tool call sequences, essentially what an LLM would attempt, and how to validate error channels so that, when things go wrong, the server returns errors that are actually useful for an LLM to recover or respond appropriately. These are practical techniques that can be applied immediately.

The goal is to establish a testing mental model that can keep up with the fast-moving MCP ecosystem.

MCP has become the de-facto "standard" for exposing the external environment to agents, but security has always been a trailing concern, making a lot of platform teams sweat under the collar. Policy checks and tool-call authentication were tacked on quickly, but are quickly being seen are necessary but not sufficient. This session zooms out from single-agent enforcement to the operational challenge security and platform teams actually face in 2026: dozens of agents, hundreds of MCP server connections, multiple clouds, rogue tool registrations, and no centralized visibility into what's running.

This session presents a multi-stage maturity model for enterprise MCP governance, to help take practitioners from "we have no idea what's running" to "every tool call is governed, audited, and compliant with internal policies", and shows how to build the program incrementally, without boiling the ocean in the process and slowing down developer velocity.

Jupyter Notebooks are critical medium for code, data, and ML, demanding a paradigm shift for AI assistance. With Jupyter's real-time collaboration and cloud-native evolution, it's becoming a powerful portal to a full data platform, beyond mere notebooks.

This session explores MCP as the essential framework for human-AI synergy within this expanded Jupyter ecosystem. Leveraging Jupyter's extensibility, MCP expands its API, opening gateways to services across the entire data, ML, and AI landscape. By extending Jupyter’s real-time collaborative models, MCP enables AI agents to seamlessly co-create alongside human developers. This integration moves beyond traditional AI coding assistance, fostering true parallel work without conflicting edits, eliminating friction and accelerating development.

The speakers will give the live demo showing how MCP provides the blueprint for connecting AI assistance directly with the Jupyter environment, both locally and in the cloud. This empowers builders to redefine human-AI interaction and unlock unprecedented productivity across the entire AI development lifecycle – from data preparation and feature engineering to LLMs fine-tuning and evaluations.

Many organizations exploring MCP already operate large microservice ecosystems. A common first instinct is to mirror that architecture directly—one microservice becomes one MCP server, and each API becomes a tool. While simple in theory, this often creates too many servers, overlapping tools, poor discoverability, and unnecessary operational complexity.

This session explores how to design MCP boundaries for real enterprise environments instead of copying existing service boundaries. I’ll walk through practical patterns for grouping capabilities, aggregating multiple services behind task-oriented tools, and exposing interfaces optimized for agents rather than internal architecture diagrams.

We’ll also cover how different agents can safely consume shared MCP services, along with key considerations such as ownership, versioning, permissions, observability, and scaling MCP across many teams.

A short demo will show how a well-designed MCP layer can simplify complex multi-service workflows.

If your organization already has dozens or hundreds of services, this session will help you adopt MCP intentionally - without repeating old patterns in a new protocol.

MCP servers are quickly becoming the default interface between AI agents and production systems.

This speed has a cost. Most teams shipping MCP servers today are repeating the same security mistakes like overprivileged tool definitions, missing input validation, no transport-layer auth, and blind trust in what the LLM sends downstream.

This talk presents a practical security assessment playbook for MCP servers, built from hands-on penetration testing and security assessments of real MCP deployments.

We'll walk through the three-five most common vulnerability patterns seen in the wild.

- tool poisoning
- permission escalation
- transport misconfiguration
- server-side request forgery through tool arguments

For each vulnerability class, you'll see how the attack works, why it slips past code review, and what the fix looks like in practice.

Attendees will walk away with a repeatable methodology for assessing the security posture of any MCP server before it hits prod. Whether they built it or adopted it.

For a geographically distributed Dev and QA team, accessing physical Set-Top Boxes for debugging is a constant bottleneck. By deploying Remote MCP, we transformed our physical STB testing lab into a shared, AI-accessible platform. This talk covers the infrastructure needed to host Remote MCP servers that interface with a fleet of physical devices. We will explore how developers can now use their local AI assistants (like Claude) to securely connect to, setup, and debug remote STBs as if they were sitting on their desks.

Modern AI agents struggle not because of reasoning limits, but because of interaction with tools on interfaces designed for humans. In agentic systems, this mismatch leads to incorrect tool selection, redundant calls, increased latency, & weak workflows that fail under real-world conditions. As MCP emerges as a standard for how models connect with tools & applications (LF Events), it provides a path to move from heuristic interactions to structured, contract-driven systems.

Taking a travel customer use case, this talk explores how the MCP redefines agent-tool interaction through schema-based contracts, enabling deterministic execution & reducing ambiguity. We’ll dive into MCP architecture—servers, clients, transports—& demonstrate how standardized tool definitions improve reliability & efficiency in agent workflows. We’ll compare a traditional API-driven approach with an MCP-based design, highlighting measurable improvements in latency, cost, & system behavior.

We’ll also cover production architectures: building MCP-compliant services, scaling them using containerized infrastructure, & implementing observability, security, & governance & failure handling real-world deployments.

This talk shares practical lessons from building a marketplace for MCP servers covering how to design a discovery layer that goes beyond a simple registry, handle versioning without breaking agent workflows, and establish trust signals (author verification, schema validation, sandboxed execution scores) that developers can actually rely on.
Attendees will walk away with concrete patterns for publishing and consuming MCP servers at scale, and an honest look at what breaks when you try to standardize a fast-moving ecosystem.

At Motorola Solutions, downtime isn’t just an inconvenience—it’s a public safety risk where lives are at stake. This session explores how we revolutionized incident response for mission-critical applications by moving beyond fragmented tools and alert fatigue. Historically, siloed data across Kubernetes and Grafana led to 45-minute MTTRs and manual context-switching.

We will detail our adoption of the Model Context Protocol (MCP), specifically utilizing Red Hat Kubernetes and Grafana MCP servers to build an AI-assisted operations layer. Learn how this unified context allows an AI agent to correlate metrics with cluster states in seconds, reducing MTTR to under 4 minutes while sustaining 99.99% uptime.

We'll share our production architecture for natural language incident resolution and our "human-in-the-loop" approach that ensures SREs remain in control of all write operations. Attendees will leave with practical guidance on scaling reliability in regulated environments and empowering junior engineers with senior-level operational context. Discover how to turn fragmented data into a mission-critical intelligence amplifier.