MCP Dev Summit Bengaluru 2026

MCP demos are easy. Production MCP is not.

Once a remote MCP server touches real data or privileged actions, a successful tool call is not enough. Teams need OAuth 2.1 done correctly, least-privilege scopes, protected resource metadata, audience-bound tokens, secure session handling, gateway-aware controls, and audit trails that explain who requested what and what the server actually did.

This session turns MCP’s security guidance into a practical production blueprint. I’ll walk through how to secure remote MCP servers end to end: when authorization is required, how to avoid token passthrough and over-broad scopes, where session isolation fails, what proxies and gateways must enforce, and what to log for debugging, compliance, and incident response.

Attendees will leave with a clear mental model, a reference architecture, and a concrete checklist for operating MCP clients, servers, and intermediaries safely in production.

What happens when your on-call agent can read Datadog metrics, tail logs in groundcover, pull pod state from Kubernetes, and grep GitLab for the commit that broke prod, all in one conversation? At Learneo we built one MCP endpoint that does that across 11 upstream servers, 518 indexed tools, and can manage multiple AWS accounts credentials. It changed how we triage incidents.
I'll walk a synthetic incident end to end, with redacted screenshots from real ones, showing the agent go from alert to MR to revert.

Key Takeaways:

- Context: meta-tools and BM25 search keep the agent at about 1.5k tokens, not 500 schemas, and it pulls what it needs on demand
- Routing: a company overview shipped as MCP instructions on connect points the agent at the right cluster and Jira project before it picks a tool
- Memory: an agent-maintained company wiki for org structure, data models, and playbooks. The agent reads it and writes back what it learns
- Security: centralized credentials and a write denylist so the agent can read everything without breaking anything

Attendees will leave understanding both the value and the architecture for turning MCP into production-grade agent infrastructure.

Small Language Models are great for edge and cost-sensitive deployments, but struggle with limited context windows. This talk shows how MCP servers can act as an external memory and context orchestration layer for SLMs. Based on a survey of 25+ long-context reasoning techniques, we demo concrete implementations: episodic memory with surprise-based retrieval (EM-LLM-inspired), and a dynamic context orchestrator that picks between RAG, summarization, and sliding-window strategies based on query type and model capacity. This is a builder's guide to making small models punch above their weight via smart MCP-based context engineering.

As MCP-based systems grow in complexity, standardizing tool interaction alone is not enough to ensure reliable execution.

This talk introduces a control-plane perspective for MCP-based systems, grounded in distributed systems principles such as scheduling, retries, idempotency, and fault isolation. Coordinating multi-step workflows across MCP servers introduces challenges such as partial failures, inconsistent state, and retry behavior that can escalate under load.

The focus is on how a control plane actively manages execution, including deciding when and how tool calls are made, handling failures dynamically, and coordinating workflows across multiple services. It also examines how centralized control improves reliability and consistency in complex MCP-based systems.

Attendees will gain concrete mental models for building scalable and reliable MCP-based systems.

We had 47 runbooks in Confluence. During incidents nobody used them. So I converted them into MCP server tools where an agent picks the right steps based on what it sees in the cluster.
This was working fine until two things went wrong.
One, the MCP server had the same service account as our CI pipeline. Too many permissions. Agent went and listed every secret in the namespace. It wasn't doing anything wrong, just had access it should not have. That's when I understood MCP has no security story for infra tools.
Two, at 3 AM the agent connected two unrelated alerts, restarted the wrong deployment, and a small incident became bigger.
I fixed both. Built OPA policy gates that check every tool call before execution. RBAC is now per tool, not per server. Tokens last five minutes and expire after one action. After the 3 AM incident I added blast-radius checks and human approval for destructive operations.
In the demo I walk through an agent diagnosing a pod failure, clearing policy, running with a scoped token, and logging an audit trail. Then it tries something it should not and gets blocked.
This talk is about what it actually takes to give an agent kubectl access safely.

This session introduces InstaMCP, a common platform designed to instantly "MCP-ify" enterprise APIs and eliminate the need for redundant "glue code" currently required to connect LLMs to internal products. This solution addresses siloed AI integrations and maintenance bottlenecks within large SaaS ecosystems. InstaMCP automatically ingests Swagger/OpenAPI specifications to generate fully deployable, secure Model Context Protocol (MCP) servers in minutes. It moves beyond simple 1:1 API mapping by providing a visual, low-code interface for developers to stitch multiple APIs into complex, multi-step workflow tools for seamless agent execution. Attendees will explore the platform's architecture, automated MCP server generation, and how it addresses the critical "security blindspot" by accommodating token-exchange and other guardrails.

As the Model Context Protocol (MCP) matures, enterprises face a "Connectivity Gap": the $M \times N$ integration problem has shifted from a development crisis to an operational one characterized by context window bloat and fragmented identity management. While the protocol simplifies 1:1 connections, orchestrating a fleet of agents across AWS, GCP, and Azure requires a centralized intermediary to govern tool discovery and secure credential propagation. This session presents cloud-engineer-mcp, an open-source implementation of the MCP Gateway Pattern. We will dive into the technical challenges of aggregating official CSP-specific servers—AWS, Azure, and GCP—behind a single interface while maintaining high performance. The talk focuses on two core architectural innovations: Embedding-based Semantic Similarity (using local models like all-MiniLM-L6-v2) to surface only the most relevant top-K tools for a conversation, and Multi-Transport Support that allows the gateway to bridge local stdio environments (like Cursor or VS Code) with remote Streamable HTTP deployments.

Most "MCP security scanners" are wrappers around npm audit and regex keyword rules. A November 2025 research survey showed 0% detection on TypeScript servers because the underlying tools never parse the AST and two-thirds of public MCP servers ship in TypeScript.

This talk walks through building an AST pipeline using ts-morph that catches what keyword rules miss: path traversal through fs wrapper functions, command injection even when the command is assembled across intermediate variables, SSRF through aliased URL parameters, and tool handlers registered without any schema validation. The key technical contribution is multi-pass taint tracking following a user parameter through variable aliases before reaching a dangerous sink, which eliminates the false-negative class that makes regex rules useless. Audited against more than 50 MCP servers.

Attendees leave with:
(1) the open-source MCPeek ruleset to drop into CI,
(2) a decision framework for choosing SAST depth per vulnerability class,
(3) the taint-tracking pattern for building MCP-aware rules in any language.

Link to MCPeek: https://github.com/iamakash-06/MCPeek
NPM Package: https://www.npmjs.com/package/mcpeek

Most MCP talks focus on the protocol or the AI side. This one is about the infrastructure underneath.
I run MCP servers on Kubernetes, and I've hit enough weird failure modes to have opinions about it. This talk covers how to deploy MCP servers as containerized workloads: health checks that actually make sense for long-lived agent connections, resource limits that don't starve your servers mid-conversation, and what happens when an agent decides to call 200 tools in a loop.
I'll walk through deployment patterns I've tested. Sidecars vs standalone pods, service mesh routing for multi-tenant setups, and HPA configurations that don't flap every time an agent goes quiet. I'll also cover the stuff that broke: connection drops during rolling updates, memory leaks from unbounded context, and the time a misconfigured liveness probe took down every MCP server in the cluster.
Expect a live demo on a real cluster, real YAML, and zero slides about what MCP stands for.

Most teams treat MCP as a pipeline, and that is the problem. Pipelines fail silently. They have no concept of desired state, no reconciliation loop, and no recovery path when a model times out or a tool call returns garbage. You are essentially writing bash scripts with an LLM in the middle.

Kubernetes already solved this. The operator pattern gives you level-triggered reconciliation, retry logic with backoff, and declarative desired state baked into the control plane. Combine that with MCP's tool abstraction and you stop writing pipelines and start building platforms where AI workflows are first-class resources that the cluster actively keeps healthy. GitOps via ArgoCD means your model routing, fallback configurations, and tool permissions are version-controlled, auditable, and promotable across environments like any other workload.

We will cover: modeling MCP workflows as Kubernetes custom resources, building operators that reconcile AI workflow state including fallback model selection and tool availability, wiring ArgoCD to manage MCP server deployments and configuration drift, and the observability hooks you need to actually trust that self-healing fired correctly.