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.

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.