MCP Dev Summit Mumbai 2026

MCP is the protocol layer for the new consumer of software. But protocols are necessary, not sufficient. The next generation of agents won't be soley defined by the protocol they speak — but also the infrastructure that powers it.

In this keynote, Sam Partee (CTO and Co-Founder of Arcade.dev) walks through the agent runtime components needed to drive more adoption of MCP: delegated identity that scopes what an agent can do; tool routing that survives ten thousand registered tools; memory and provenance that turns one-shot demos into auditable systems. Each layer is grounded in production data — what breaks, mistakes we made, what to build, why, and what the next two years of infrastructure work look like.

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.

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.

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.

An agent processes a payment, hits a timeout, and retries. Now the payment has been charged twice. The model didn’t hallucinate. The workflow did exactly what it was told. The problem is that nobody designed the agent to be safe under retry.

This is a distributed systems problem.

When agents read data, take actions, and write results back, correctness depends on how state is managed across steps. Under retries or concurrent execution, the same workflow can produce conflicting outcomes.

This talk shows how to build stateful AI agents using the Model Context Protocol with a PostgreSQL-compatible distributed database. Instead of treating memory as embeddings, we treat it as structured, transactional state.

You will learn how to design MCP tools for database operations, manage multi-step workflows, and handle failure modes such as retries and idempotency. We will also explore consistency tradeoffs in distributed systems.

The session ends with concrete patterns for building reliable agents, including idempotent tools and safe retry design.

Most MCP demos stop at "hello world over stdio." Shipping a production MCP server means answering harder questions: How do you authenticate callers? How do you meter usage? How do you safely hand an LLM a live Kubernetes cluster without giving it the keys to prod?

This talk walks through Starling, a production MCP server that exposes 17 Kubernetes tools — from list_pods to scan_cluster — to Claude, Cursor, and VS Code. It runs live on GKE at ops-mcp.warblecloud.com, charges credits per tool call, and handles ephemeral kubeconfigs without ever persisting them.

We'll cover concrete design decisions: dual-transport architecture (stdio for desktop agents, HTTP for remote), a Firestore-backed credit ledger with atomic per-tool debits, mode-gated write tools (scale_deployment only when --mode=readwrite), and the security model for handing an LLM temporary cluster access.

Attendees leave with a working mental model for turning an MCP prototype into a billable, multi-tenant service — plus the exact auth, transport, and RBAC patterns they can lift into their own servers.

Most MCP servers in production were built by AI teams. Meko's was built by a distributed SQL database team, and the view from this side of the stack is different.

Coming from storage, some decisions were obvious from day one. Memory, knowledge, conversation history, and structured data belong on one cluster, not four. Tenant isolation is a schema problem. The datapack, our per-agent namespace, fell out of the same instinct that builds any multi-tenant database.

Other decisions we only got right the second time. We started with a deployment model that gave every user their own MCP server, and pivoted to a shared fleet once we saw how real usage patterns played out. We shipped tools for capabilities that turned out to belong in skills. We learned where the language model needed a tight, opinionated surface and where it needed more room.

This talk is the story of what we brought to MCP from the database side, what we discovered once real agents started using it, and the pivots we made, including the ones still in flight.

MCP Apps are reshaping what a Model Context Protocol server can do — turning text-only tool exchanges into rich, interactive experiences embedded directly in the host. This session takes a builder's tour of the MCP Apps extension: core concepts, target use cases (dashboards, multi-step workflows, human-in-the-loop confirmations), the security model, and current limitations worth knowing before adoption.
A central theme is the visibility paradigm — letting UI carry state the model doesn't need to see, unlocking meaningful token savings on data-heavy flows. We'll cover iframe sandbox constraints, postMessage patterns, session-bound identity, and prompt-injection defenses for sensitive actions. We will also cover existing protocol limitations and work going on to address the same in exp-apps working group.
We close with a live Go-based demo executing a fund transfer flow end-to-end.

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.