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.

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.