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.

I have nine MCP servers in production wrapping kubectl, Prometheus, Grafana, OpenSearch, and CI/CD. Three months in, one started silently dropping tool calls. Connection pool exhausted but health checks passing. Logs clean.
Agent did not raise any error. It stopped using that tool and started making up answers. For two weeks nobody caught it. Then one incident response went wrong because the agent was working with data it generated itself.
After that I realised we are building this whole MCP layer with zero visibility into whether it is healthy. Normal monitoring does not catch these failures.
So I built an observability platform for MCP servers. OpenTelemetry hooks that plug into any FastMCP server in two lines of code. Prometheus metrics built for MCP: tool call latency, error rates, connection pool usage. The important one is tool call frequency deviation. It tells you when an agent gradually stops using a tool. That is how you catch the worst failure: agent walking away from a broken server and hallucinating.
In the demo I degrade a server on stage. Normal monitoring will not catch it. Frequency alert fires in under two minutes.
Open-source, packaged as a Helm chart.

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.

The promise of autonomous AI agents has sent engineering teams on a wild goose chase—juggling vendor lock-in, unpredictable costs, & security nightmares all for an agent to execute a simple workflow.

Stop chasing and start building!

Enter goose: the open-source, general-purpose framework, designed to run natively on your machine. It connects to any LLM. goose shifts the paradigm from fragile and remote to robust and local.

In this talk, we shall explore how to successfully architect and deploy goose within an enterprise environment. Chop through hype to demonstrate how goose leverages MCP to integrate with your choice of tools. More importantly, we will tackle the critical enterprise realities of deploying autonomous agents: establishing strict token budgets, implementing robust security guardrails to prevent destructive terminal commands, and building "Custom Distros" to standardize AI workflows across your entire engineering organization.

Automate mundane research, streamline CI/CD, or safely vibecode ― you will leave this session with a practical blueprint for making open-source agents work for your enterprise, thanks to goose.

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.