MCP Dev Summit Mumbai 2026

18 months ago, Block open-sourced an agent framework called Goose. Community grew quickly,  faster than I ever expected. Then the community came back with a question I didn't have a good answer to: who keeps this open?
This is the story of chasing that answer - how it led to a foundation co-founded by fierce rivals, why nearly two hundred companies have since joined, and what we've learned about open along the way. Because open, on its own, doesn't stay open; we've seen that movie before, and the agentic layer raises the stakes higher than anything that came before it.
It's also a look forward - to the future we're building toward, where agents from any vendor can find each other, trust each other, and transact on rails no single company, or government, can ever pull out from under us. The agentic layer is still being shaped. This talk is about how we keep it open, and how you can help, while it's still ours to shape.

Goose is an open-source AI agent that can be extended through integrations, tools, and community-driven projects. In this talk, I'll share my journey working with Goose, explore how its capabilities can be extended through community-driven projects, highlight examples from the Goose ecosystem, and discuss the development of GooseBot as one approach to bringing AI agents closer to developer communities. Along the way, I'll cover lessons learned from building in the open and why extensibility is key to the future of open-source AI agents.

AI Agents are getting smarter with each passing day. But, their interfaces? Not so much.

But, what if there is a way to turn the AI chat from a place where you converse into a place where you can actually work?

MCP Apps offer a solution to go beyond the text and standardize how MCP servers can deliver rich, bidirectional UI components like dashboards, forms, interactive visualizations & more. These components are rendered securely and natively within AI hosts, enabling agents to interact with users via rich interactive interfaces.

In this session, attendees will learn:
- Core architectural patterns from real MCP Apps development
- How to handle sandboxed host–server communication, manage state synchronization, stream real-time updates, handle async tasks, & add multiplayer collaboration
- How to leverage context and persist memory across conversations
- How to avoid some common pitfalls and utilize debugging workflows and tools
- How to add authentication & deploy a remote MCP Server providing MCP Apps

We will walk through a complete, production-style Sales Analytics MCP Apps and perform a code deep-dive to showcase the effective foundational patterns while building MCP Apps.

56,000+ MCP servers are listed across mcp.so, Smithery, Glama, and PulseMCP. But how do you know which ones actually work?

I independently mapped 4 major MCP directories and tested 65+ servers across Research, Code, and Finance categories. The results expose a critical trust gap.

Each directory measures something different — none measure what matters most:
- mcp.so (19.5K servers): Zero quality signals
- Smithery (4.4K): Tracks uptime, not output quality
- Glama (21K): Grades code quality, not correctness
- PulseMCP (11K): Tracks popularity only

Key findings I'll share:

1. Quality collapse at scale — Developer Tools has 8,800 servers but only ~12 are consistently good (0.1% quality rate)

2. The Finance/Payments desert — 74 Finance servers out of 19,557 (0.4%). Fewer than 8 support agent-to-agent payments across 14 protocols I analyzed

3. A practical framework for MCP server trust — beyond code grades to actual output quality assessment

This is independent research, not a product pitch. Full dataset and methodology shared openly.

Attendees leave with the first cross-directory quality analysis of the MCP ecosystem and a framework for evaluating servers.

MCP makes tool use interoperable. It does not, by itself, give you a portable record of what happened after a tool call crosses a system boundary.

That gap shows up quickly in real deployments. Server logs help the operator debug. Traces help inside one stack. But if a customer, partner, auditor, or downstream system needs to verify a tool result later, those artifacts usually do not travel well.

This talk shows a practical pattern for adding portable signed records to MCP tool calls without changing MCP itself. I will walk through where the record fits, what should be signed, how to carry it with a tool result, how offline verification works, and how this complements existing auth, tracing, and policy systems instead of trying to replace them.

Attendees will leave with a clear implementation pattern they can use in their own MCP servers and gateways: issue, carry, verify, and reason about signed records for tool calls.

There is a fundamental contradiction at the heart of production deployments for the Model Context Protocol (MCP). Conceptually, MCP sessions are stateful: they establish connections, negotiate capabilities, and persist context. However, modern deployment environments—like Kubernetes horizontal scaling, serverless functions, and AWS Bedrock AgentCore—are inherently stateless.

The current ecosystem advice is simply to "externalize your state," but there is no standardized infrastructure for doing this natively within MCP. Developers are forced to build ad hoc memory management using custom Redis wrappers or brittle in-memory dictionaries.

This session introduces the State Sidecar pattern: a dedicated MCP server whose sole responsibility is to store, manage, and retrieve agent workflow state. Instead of building custom database connectors, any agent can call the sidecar via standard MCP tool calls to persist intermediate results, track task progress, and maintain context summaries.

Most developers encounter MCP as a way to give chat assistants better tools. This talk blows that ceiling off.
Using two open-source projects, Appium MCP and AppClaw, we'll show how MCP becomes the backbone of a fully autonomous agent that controls real Android and iOS devices without a human in the loop. The agent perceives a live UI tree, reasons about what to do next, calls MCP tools to act, observes the result, and loops handling stuck states, recovering from failures, and decomposing multi-app goals on its own.
We'll go deep on the architecture decisions that make this work in production: how dynamic tool discovery lets the agent adapt to new capabilities at runtime without code changes; how parsing raw UiAutomator2/XCUITest XML into compact representations makes mobile UI fit inside an LLM context window; why dual vision (DOM-first with screenshot fallback) beats either strategy alone; and how stuck detection transforms a fragile demo into a reliable engineering tool.
Attendees will leave with a concrete mental model for building agentic systems on MCP and an understanding of why the protocol matters far beyond tool-calling alone.
https://github.com/appium/appium-mcp

The default AI stack today ships user data to a cloud endpoint and hopes for the best. But regulations like GDPR, India's DPDP Act, and sector-specific mandates (healthcare, finance, defense) increasingly demand that sensitive data never leave the device or jurisdiction. This talk presents a working architecture that squares the circle: run frontier-class SLMs (Phi-3 Mini, Gemma 2B) locally via Meta's ExecuTorch runtime on Android, while using Anthropic's Model Context Protocol (MCP) as the orchestration layer that decides what runs where, which tools the model can access, and what data governance policies are enforced — all without a single byte of PII hitting an external server.