MCP Dev Summit Mumbai 2026

**Space Limited - First Come, First Served.  Please bring a fully charged laptop to the workshop**

Most MCP tutorials stop at "hello world." This session goes further. We will walk through how we built a production-grade, open source MCP server template at Red Hat, covering FastMCP + FastAPI integration, multiple transport protocols (HTTP, SSE, streamable-HTTP), OAuth with PostgreSQL token storage, structured logging, and OpenShift deployment manifests. Attendees will leave with a clear mental model of what it actually takes to go from a local MCP prototype to something you can run in production on Kubernetes. We will also share the design decisions we made, the mistakes we avoided, and how developers can use this template as a starting point for their own MCP servers.

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.

We design MCPs assuming idempotency, apply the same action twice nothing changes, reconcile repeatedly, and state is declarative.

But in reality, most MCP actions are only partially idempotent, because beneath the abstraction external systems mutate independently, side effects escape the control plane, ordering of operations matters, and “same input” doesn’t always mean “same result”. At scale, MCPs rely on many things like reconciliation loops, declarative APIs, retry-based execution.

We’ll unpack how MCPs unintentionally, violate idempotency through hidden side effects, depend on ordering guarantees that don’t exist, produce divergent states under retries, mask unsafe operations behind “safe” abstractions. This isn’t a talk about retries or Kubernetes patterns. There are no controller frameworks, just a deeper examination of why MCPs aren’t as safe as we assume, and how to design them with fewer hidden risks.

Because the most dangerous systems aren’t the ones that fail.
They’re the ones you believe are safe to retry.

MCP tools give AI agents direct access to external services - production databases, internal APIs, third-party platforms. But most teams deploying MCP today have no answer to a simple question: who authorized that tool call?

MCP has made remarkable strides in standardizing agent-to-tool connectivity - but AuthN and AuthZ at the tool invocation layer remain an open problem. Tool calls are dynamic and runtime-driven; static Kubernetes RBAC has no vocabulary for per-tool, per-agent, or per-parameter enforcement. There is no native spec primitive to say "only this agent can call this tool."

In multi-tenant environments this gets worse - one misconfigured agent can invoke tools across tenant boundaries and nobody finds out until the damage is done. Teams filling this gap today are relying on custom middleware, app-level checks, or nothing at all.

This talk explores where MCP's authorization model falls short and how policy-as-code closes the gap - with Kyverno as one strong implementation path. The session walks through real ClusterPolicy configurations, multi-tenant isolation patterns, and hard-won lessons from tuning enforcement without breaking production agents.