MCP Dev Summit Bengaluru 2026

Modern MCP applications depend on tools to extend model capabilities, yet tool interface design is a primary source of unreliability. Ambiguous descriptions, poorly structured schemas, and inconsistent outputs often lead to incorrect tool selection, invalid inputs, and unpredictable system behavior.

This session introduces a practical framework for designing reliable MCP tools. We begin with a concise mental model of how language models interpret tool interfaces, followed by real-world failure scenarios that expose common design pitfalls. Building on this, we present design principles for clear naming, well-defined schemas, and structured outputs, along with patterns for creating predictable and composable tools.

The session concludes with a practical checklist and actionable guidelines that attendees can immediately apply to improve reliability, reduce debugging complexity, and build robust MCP applications in production environments.

MCP standardizes how tools are described and invoked, but not what they should return. That leaves a critical decision open: whether an MCP tool returns raw data, shared state, or decisions. That choice determines where intelligence lives.

This talk presents three placement patterns in MCP tool design. Centralized Intelligence treats tools as data sources, returning raw inputs agents must interpret. Streaming Intelligence exposes pre-processed state so agents operate on shared context. Edge Intelligence pushes decisions into tools, with MCP delivering opinionated outputs rather than raw inputs.

These patterns produce fundamentally different behavior across tool call volume, context window usage, latency, and failure modes. In multi-agent systems they determine whether agents converge or diverge: raw data per agent leads to inconsistent reconstruction; shared state or decisions make coherence a property of the architecture itself.

This talk introduces a practical decision framework for MCP tool design based on data volatility, agent reuse, and consistency requirements.

MCP is a tool contract. Intelligence placement is the architectural decision it doesn't make for you.

MCP adoption has outpaced security. An audit of 17 popular MCP servers found an average security score of 34 out of 100. Tool poisoning attacks succeed at 84.2% with auto-approval enabled. Over 30 CVEs have been filed against MCP implementations in the past 60 days. The first confirmed malicious MCP server, postmark-mcp, silently BCC'd every outgoing email to an attacker-controlled address for weeks before detection.

OWASP responded with the MCP Top 10, a structured threat taxonomy purpose-built for the protocol. This talk is a practitioner's walkthrough of all ten risks, not a slide-read, but a builder's guide to what each risk looks like in a real MCP deployment, how it gets exploited, and what a concrete fix looks like in code.

We cover token mismanagement and secret exposure, prompt injection via tool responses, tool poisoning through malicious descriptions, excessive permissions, insecure output handling, context over-sharing, missing authentication, rug-pull attacks, shadow MCP servers, and the audit trail gap.

Leave with a pre-deployment security checklist you can run against any MCP server before connecting it to production.

When I started building MCP-powered agents and Claude Skills at Harness, I kept running into weird transport issues, connections dropping behind load balancers, SSE endpoints behaving differently across clients, tutorials that contradicted the actual spec. Turns out, MCP's transport layer had quietly gone through a major overhaul and most of the content out there hadn't caught up.

In this talk, I'll walk through MCP's transport journey, stdio for local tooling, the dual-endpoint SSE model that powered early remote servers, and the Streamable HTTP design that replaced it in the March 2025 spec update. More importantly, I'll explain why each shift happened: the scaling headaches SSE caused, the connection recovery gap, and the auth/CORS simplifications that Streamable HTTP unlocked.

I'll share code from actual migrations I've worked through, what breaks when you switch, what gets simpler, and the backward-compatibility gotchas that the docs don't warn you about. If you're building or maintaining MCP servers today, this should save you a few weekends of debugging.

Every MCP demo assumes text in and text out. This talk explores what actually happens when you replace the text interface with a live voice stream.
Connecting a real-time voice pipeline to an MCP-backed agent introduces problems that the current MCP ecosystem has no established answers for. This talk walks through them one by one: end-of-turn detection and how tool-calling latency affects perceived conversational fluency, interruption handling when a user speaks while a tool is executing, tool result verbalization where structured JSON responses need to be narrated naturally without losing meaning, and error communication when a tool fails mid-conversation.
The talk is grounded in a working system built with a real-time voice layer, Sarvam AI for speech processing, and MCP-connected agents handling live tool calls. Attendees will see a live demo and leave with an architectural blueprint for voice-first MCP agents, including the specific latency budgets, buffering strategies, and verbalization patterns that make the experience feel natural rather than robotic.
This is a frontier that very few builders have shipped in production.

Connect three MCP servers and 55,000 tokens are consumed before the agent reads the user's query. Perplexity's CTO called this out at Ask 2026. Cloudflare measured 244,000 tokens for their API surface. The protocol isn't the problem. The "load everything upfront" pattern is.

FastMCP Code Mode solves this server-side, but requires the server author to opt in. Most MCP servers in the wild will never add it.

I'm currently building mcp-guardian, an open-source Python proxy that addresses this for any server, unmodified. It will do two things:

1. Tool scoping: filter tools/list against a YAML config so agents only see allowed tools. delete_repo won't exist in the agent's world.

2. Progressive disclosure: expose three meta-tools (search_tools, get_schema, execute_tool) instead of full schemas. Agents will start at ~300 tokens instead of ~8,000 and load schemas on demand.

I'll live-demo: direct connection (14 tools, ~8,000 tokens) vs through the proxy (3 meta-tools, ~300 tokens). I'll walk through the JSON-RPC interception, share token benchmarks, and compare with Code Mode. They're complementary, not competing.

The project will be open source.

This is not just about Admiral Group PLC but for every organisation, tool schemas in MCP evolve as platforms change parameters get renamed, new required fields are added, response shapes shift. Agents built against an older schema break silently, produce incorrect results, or enter undefined behavior, and there is no established SemVer discipline for MCP tools today. This session proposes a practical versioning specification for MCP tool definitions covering additive-only change policies, explicit deprecation signals embedded in tool metadata, capability negotiation via request headers, and client-side schema compatibility layers. The session demonstrates these patterns with a real Kubernetes tool server that ships v1 and v2 tool definitions side by side, with running agents targeting each version independently, and a live migration showing how a breaking change is introduced and absorbed without downtime.

Most retrieval systems ignore the structure MCP Resources already provide unique URIs, typed links, version metadata, timestamps and flatten everything into vector chunks. GraphRAG proved retrieval needs relational structure; MCP already has it natively.
This talk demonstrates with a live adversarial demo: a vanilla RAG agent and a Resource-graph agent answer the same questions against the same corpus. RAG works on single-hop queries. It confidently returns stale data when a superseded document exists. The graph agent catches the version conflict using last-modified metadata that was already there. When the graph has a broken link, it reports the dead end instead of hallucinating.
A hop-count benchmark across seven questions (1–5 hops) makes the gap measurable: at three hops, RAG hit rate dropped to 50% while graph traversal held at 100%.
The primary deliverable is a draft cross-reference metadata convention four optional fields (superseded_by, depends_on, implements, compliance_scope) that any MCP Resource provider can add without breaking existing consumers. The goal: make knowledge as navigable for AI agents as hypertext made the web for people.

MCP enables powerful AI-driven workflows — but production enterprise systems have SLAs, throughput contracts, and years of performance tuning. Wiring a reasoning loop into that environment reveals costs that don't show up in demos: latency amplification from sequential tool invocations, data movement overhead across system boundaries, schema drift, and observability gaps that span model reasoning and distributed backends.

This talk takes a systems-engineering lens to MCP in enterprise-scale data platforms. We formalize the MCP execution pipeline, identify where overhead accumulates, and present architectural patterns that contain the cost — including isolating orchestration from hot paths, fronting high-performance backends with thin MCP adapters over gRPC, and tracing multi-step workflows end to end.

The central argument: MCP belongs on the control plane, not the data plane. Enforce that boundary, and you gain adaptive orchestration without sacrificing reliability. Cross it, and predictability erodes fast. Attendees leave with a latency model, a failure-mode taxonomy, and a practical framework for deploying MCP in production — deliberately, not by accident.

Dashboards lie. Not maliciously, structurally. Aggregation hides the tenant on fire. Sampling drops slow requests. The p99 looks fine because 47 users who timed out are a rounding error. Every SRE has lived this: green screen, Slack on fire, hunting across five tools to find what the dashboard refused to show.

This is a field report from building MCP tools that do the hunting. The agent does not replace the SRE. It does the grunt work nobody has time for at 3 AM: pulling exemplar logs for the slowest 0.1 percent, correlating a deploy against error rates, checking if the metric was even reporting.

1. Why dashboards lie. Sampling, aggregation, the "aggregate green, individual red" pattern.
2. MCP tool design for truth-seeking. Read-only vs side-effecting split, partial-data schemas, outputs that make the model admit uncertainty instead of hallucinating "all good."
3. Correlation loops that work. Deploy to error rate to exemplar logs to suspected change, not seventeen tabs.
4. Guardrails from production. Prompt injection in logs, cost blow-ups, tools we took back after one bad incident.

Attendees leave with patterns for MCP tools that chase down what dashboards will not show.