MCP Dev Summit Mumbai 2026

The emergence of the Model Context Protocol is transforming how AI agents interact with tools, data, and real-world systems. However, most early MCP implementations rely on high-level runtimes that are not well-suited for embedded and resource-constrained edge environments. This session explores how RUST enables a new class of high-performance, memory-safe MCP servers designed specifically for Embedded Linux–powered edge devices.

In this tutorial, I'll walk through building a lightweight MCP server, bridging physical data sources into LLM-readable formats, enabling intelligent agents to reason over live edge data using Rust.

- Why MCP for Edge AI Systems?
- Why RUST?
- Building simple server using rmcp and testing with a client
- Bridging physical word e.g. Sensors, Telemetry, File Systems and structuring LLM-readable context, data pipelines
- High-performance Edge MCP Runtime - Async & Concurrency Models for scalable communication (MQTT, HTTP, gRPC etc.)
- Observability, tracing & Debugging
- Bring MCP in Agent loop, Using Rig for orchestration
- Deploying to target board, cross compilation steps
- Case Study: Building an Edge MCP Agent, e.g. Telemetry and Diagnostics

**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.

The MCP authorization spec gives us a clean OAuth 2.1 story between clients and servers. What it leaves out of scope is the host itself, the AI agent orchestrating the conversation. That's where enterprise deployments quietly break.

An MCP host is not a passive pipe. It accepts requests from users, services, and peer agents, reasons with LLMs, and invokes tools across many servers. Every edge is an identity boundary. Without a first-class host identity, no stable credentials, no verifiable delegation, no independent audit trail, every downstream decision inherits that ambiguity. Who made this tool call? The user? The agent on their behalf? The agent autonomously? Most deployments cannot answer, so they cannot enforce least privilege or satisfy audit.

This talk treats the MCP host as a first-class identity through four disciplines: Administer (lifecycle, credentials), Authenticate (how a host proves itself), Authorize (delegation vs. impersonation, token exchange, actor claims), and Audit (trails that separate agent action from user intent). For each, we'll show what the spec covers, where the gap sits, and which extensions and emerging patterns are converging to close it.

As enterprises scale AI operations to support hundreds of agents and thousands of users, they inevitably hit an architectural wall. The friction points fall into three categories: visibility, control, and reuse. Teams struggle to discover existing agents and MCP servers across a large organization, platform teams need to govern publication and enforce security, and siloed groups waste time rebuilding capabilities that already exist. Without a centralized registry, agent sprawl grows, compliance risk increases, and critical knowledge stays trapped in local teams. In this session, we will share how the Motorola Solutions Platform Engineering team addressed this bottleneck by building a shared discovery and governance layer for internal AI resources. We will unpack the patterns behind our internal MCP catalog, including agent and prompt versioning, team-based visibility controls, approval workflows, and automated security scanning before resources are broadly shared. We focus on what broke early, and what won trust first. Attendees will leave with a practical, vendor-agnostic blueprint for making MCP resources easier to discover, safer to publish, and more reusable at enterprise scale

As the Model Context Protocol (MCP) emerges as a standard interface for connecting models, agents, and tools, organizations are exploring MCP servers while also evaluating the operational and security implications of adopting them at scale. This session proposes the solutions and guardrails to address the common security issues such as lethal trifecta, tool poisoning and access misuse.

The talk will outline how MCP registry, control planes, secure gateways and trust boundaries a work together to enable risk governance, security, and operational reliability across agent and MCP ecosystems.

While examples may reference specific approaches, the session remains implementation-neutral and focuses on how these controls collectively establish a safe and scalable MCP environment. Attendees will gain a holistic understanding of how layered controls can address the security concerns and operational risks associated with MCP servers, helping organizations move toward trusted, scalable MCP ecosystems.

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.

Single agents calling MCP tools is a solved problem. Multi-agent swarms, where several agents coordinate on the same task, isn't.

The moment you go from one agent to three, you hit a set of problems that MCP itself doesn't solve and that most orchestration frameworks only paper over: how do agents share state without drowning each other in JSON, how do you isolate their execution when they're all touching the same files, and how does one agent pick up where another left off?

This talk walks through those three problems using a concrete example: a code review swarm. Three specialized reviewer agents (style, security, test coverage) work on the same PR in parallel. A fourth, a developer agent, reads their findings and applies the fixes. Each agent runs in its own isolated sandbox. They collaborate through a shared filesystem rather than by passing context in prompts.

This is a technical deep dive covering:
- why traditional file storage mechanisms are not optimized for agentic workloads
- why shared workspaces are better than passing state through prompts or RAG lookups
- why isolation boundaries are important when agents execute code

Includes live demo of swarm.

The Model Context Protocol (MCP) standardizes context retrieval and tool execution, but granting LLMs access to dynamic execution environments introduces critical runtime vulnerabilities. Traditional containerization (e.g., Docker/containerd) introduces unacceptable latency overhead for sub-second agentic loops, while static IAM/RBAC models fundamentally fail to constrain non-deterministic generated code.

This technical session details the architectural implementation of embedding a WebAssembly (WASM) runtime within an MCP server to enforce a strict, capability-based execution boundary. We will deconstruct how to compile MCP tools to WASM modules and utilize the WebAssembly System Interface (WASI) to ensure that any logic invoked by an LLM is isolated from the host operating system.