MCP Dev Summit Mumbai 2026

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.

MCP simplifies AI-tool integration — but in high-throughput, latency-sensitive pipelines, its performance characteristics can quietly become the bottleneck. Iterative reasoning loops, sequential tool invocations, and context amplification compound in ways that are easy to miss in development and impossible to ignore in production.

This talk presents a structured decomposition of end-to-end MCP latency — reasoning, communication, execution, and coordination — giving engineers a precise framework for identifying where overhead actually lives. We then present targeted optimizations: parallel tool invocation, streaming responses, schema minimization, and intelligent caching.

The core architectural argument: MCP belongs on the control plane. Separating adaptive orchestration from data-plane execution preserves deterministic performance where it matters, while keeping model-driven flexibility where it adds value. A fast path versus intelligent path pattern follows naturally from this separation. A case study comparing naive and optimized pipeline implementations makes the gains concrete.

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.

MCP brings structure and standardization to how LLMs interact with tools and resources—but that power comes with cost. We’ve built multiple MCP servers across different use cases, and not all of them should have existed.
This session distills hard-earned lessons from real-world implementations: where MCP created long-term leverage, where it introduced unnecessary complexity, and where a direct API call would have shipped faster and cleaner. We’ll share a clear evaluation checklist you can use before starting your next build—so you choose MCP intentionally, not reflexively.