MCP Dev Summit Mumbai 2026

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.

The LFX ecosystem faced fragmentation, hundreds of siloed APIs and scattered data made simple questions complex and prevented AI agents from connecting. This talk chronicles the journey to build the LFX MCP Server, a 100% open-source solution that established a single, standard AI interface, enabling every LFX system to speak the same language. You will hear why MCP was chosen over custom integrations and learn about unexpected challenges, including securing authentication, managing permissions, and tackling immediate data quality issues. Finally, we share critical lessons learned, emphasizing the power of fewer, sharper tools and the necessity of governance from day one.

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.

When we tried to scale our multi-agent MCP system beyond a single node, the orchestrator broke immediately.

Each model running on a different machine means the orchestrator had to track which models it called, which responses arrived, and which were pending. The moment the orchestrator restarted, everything was gone. Models got called twice. Responses were lost. Consensus became inconsistent.

Turns out this is the sticky session problem. And the ecosystem is still figuring it out.

As SEP-1442 is moving MCP toward a stateless-by-default transport model. But most deployments still depend on session affinity. When you are orchestrating models across distributed nodes, that dependency breaks everything.

This talk covers what we learned designing around it:

- Why multi-agent MCP orchestration creates hidden session dependencies
- How to decouple consensus state from the orchestrator process using structured event logs
- Migration patterns that preserve workflow correctness without session affinity
- Stateless MCP is not just an infrastructure concern. It is what makes multi-agent consensus reliable at scale.

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.

Multi-agent systems on MCP are where most of the interesting architectural questions live: routing, state, retries, coordination, and what happens when any one of N tool calls misbehaves. Most talks on the topic are theoretical. This one is not.

Since early 2026 I've published one new AI agent every day at dailybuild.xyz. Many of them are multi-agent: price-war simulations, research pipelines, a local agent orchestration studio, a recursive research loop, human-in-the-loop travel planners, and a "swarm CFO" with policy-gated spend. Dozens of them plug into MCP servers.

In this session I'll pull out the ten orchestration patterns I now use by default when MCP is in the mix, and the ten I've thrown out. Topics include: why single-agent-with-many-tools usually beats a team of agents until it suddenly doesn't; how to design a router that survives tool-name collisions across multiple MCP servers; state strategies that don't rot; retry and compensation patterns for idempotent vs non-idempotent tools;

Every pattern in the talk is tied to a specific public build with working code, so attendees can go verify, fork, or challenge anything I claim.

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.

Most of us think of agent tools as vending machines - you put in the right input, you get the right output. Put in the wrong input, and you either get the wrong output or nothing at all.

This breaks for complex workflows where context is incomplete or intent is ambiguous. The tool either guesses wrong or fails outright. No back-and-forth, no clarification. Good AI tools built for conversation should explain what they need, what they'll do, and provide clear options.

In this session, we’ll look at how MCP elicitation works in practice across different workflows: covering ambiguous input, missing context, risky operations, and auth flows. Attendees will leave with concrete patterns for designing tools that go beyond transactional APIs to collaborative multi-turn interactions.

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.

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.