MCP Dev Summit Bengaluru 2026

Most MCP servers are one-shot: the client asks, the server answers. But some features need the server to reason mid-execution like summarise a diff before returning it, classify input to pick the next step, recover from ambiguity instead of failing, generating new data. That's what sampling unlocks: the server calls back into the host's LLM, without ever holding its own model keys.

This deep dive walks through sampling/createMessage feature provided by the mcp protocol and its internals messages, modelPreferences, includeContext, systemPrompt — and what the client is actually allowed to modify. We'll cover capability negotiation and the human-in-the-loop approval flow, then step through how sampling patterns are actually built in the smartbear-mcp server, using its implementations over there to understand how one could build their own sampling features.

Then the hard parts: agent loops, token-budget blowups, portability across clients using different model providers.

You'll leave knowing when sampling beats tools or elicitation, and with patterns you can lift today.

Most of us think of agent tools as vending machines - you put in the right input, you get the right output. Put in the wrong input, and you either get the wrong output or nothing at all.

This breaks for complex workflows where context is incomplete or intent is ambiguous. The tool either guesses wrong or fails outright. No back-and-forth, no clarification. Good AI tools built for conversation should explain what they need, what they'll do, and provide clear options.

In this session, we’ll look at how MCP elicitation works in practice across different workflows: covering ambiguous input, missing context, risky operations, and auth flows. Attendees will leave with concrete patterns for designing tools that go beyond transactional APIs to collaborative multi-turn interactions.

As the Model Context Protocol (MCP) matures, we face a critical security hurdle: how do ambient agents that are running in the background or on headless devices securely access sensitive resources without constant manual intervention?

Standard OAuth flows often break the "ambient" experience by requiring immediate browser redirects on the same device. This session proposes a decentralized identity architecture using Client-Initiated Backchannel Authentication (CIBA). By decoupling the consumption of resources from the authorization flow, an MCP client can trigger a "just-in-time" permission request directly to a user's trusted mobile device.

Key Takeaways:
- Decoupled Auth: Implementing CIBA to bridge the gap between headless MCP clients and human controllers.
- Just-in-Time delegations: Moving from "all-or-nothing" API keys to granular, session-based permissions.
- Security Patterns: Handling asynchronous "Out-of-Band" callbacks within the MCP lifecycle.

Join us to explore how we can make background agents both powerful and respectful of the "human-in-the-loop" principle.

Most database MCP implementations are stdio transport, hardcoded URIs, and live connections handed directly to AI agents. This works on a laptop. It fails in production.
Direct agent-to-database connectivity is dangerous. Connection exhaustion, raw credentials in agent context, DDL one hallucination away, PII returning unfiltered into LLM context windows, runaway queries taking down production clusters. Not theoretical. Production failures waiting to happen.
For our internal DBaaS service we built a two-layer remote MCP architecture to close every one of them. An MCP Proxy handles agent-facing concerns — JWT auth, SSO-backed approvals, rate limiting, and an execution_id registry so no agent ever sees a raw URI. It never touches the database. Queries route through a Query Service — the only layer that does. Read-only enforced structurally, DDL blocked even for root, injection filtered, timeouts enforced, Presidio scrubbing PII before responses reach any agent context window. We contrast this with direct-connect tools, contribute execution_id as a reusable enterprise primitive, and make the case for why an enforcement layer between MCP and your DB is the architecture — not an option

As MCP servers exponentially proliferate, a critical question emerges: who audits what an LLM actually did when it invoked a tool?

Application-layer logs can be tampered with or missed. This talk argues that eBPF is the only tamper-resistant audit layer for MCP tool execution and shows you how to build it.

We walk through instrumenting an MCP server's syscall surface with bpftrace and cilium/ebpf: capturing every network egress triggered by a tool call, every file descriptor opened, every exec spawned, correlated back to the originating MCP request ID via process lineage tracking in BPF maps.

The result is an immutable, kernel-enforced audit trail that no application-layer bug or prompt injection can suppress.

We'll also cover using eBPF LSM hooks to enforce policy at call time, blocking tool invocations that attempt unexpected network destinations or file paths effectively making eBPF a runtime policy engine for MCP's threat model.

Attendees leave with a working threat model, reference eBPF programs, and a clear mental model for where kernel enforcement fits in MCP's trust architecture.

MCP prototyping on a laptop is deceptively simple — a few decorators, a stdio transport, and your agent has tools. But the moment you try to serve your team, reality hits: who authenticates callers, how do sessions stay isolated, what happens when three agents invoke your server concurrently, and who traces the call that went wrong at 2 AM?

This talk follows the lifecycle of a real MCP server — from a single-file prototype to a production deployment running on a managed cloud runtime. Along the way, we unpack the four walls every MCP server hits on its way out of localhost: transport (stdio to streamable HTTP), identity (from trust-everyone to verify-everything), concurrency (single-user to multi-session isolation), and observability (from print() to distributed traces).

The highlight is a live demo where we take a three-tool MCP server, deploy it to a managed runtime with zero infrastructure code, connect an AI agent that discovers those tools automatically via the MCP protocol, and then show what production actually looks like — traced multi-tool invocations, session memory across turns, and guardrails blocking a destructive call in real time.

You will leave with a clear mental model of the production gap, a concrete deployment path you can replicate the same evening, and a checklist of what "production-ready" actually means for MCP servers — so the next tool you build doesn't stay trapped on your laptop.

Agent security discussions focus on prompt injection and sandboxing. But when agents operate on real infrastructure - pushing to Git, executing code via SSH, starting cloud instances - every machine in the fleet carries its own keys, tokens, and credentials, multiplying the risk.

This talk presents the security architecture of apra-fleet, an open-source (Apache 2.0) MCP server that orchestrates AI agents across distributed machines:
- Credential lifecycle: provisioning LLM auth (OAuth, API keys), SSH keys, and Git tokens with automated key-pair migration
- Out-of-band credential entry: passwords collected via separate terminal, never exposed to the LLM. "LLM secure variables" for sensitive text
- Short-lived tokens: GitHub App mints scoped tokens with minute-level TTLs - a compromised session cannot reuse yesterday's token
- Role-scoped permissions: MCP tool constraints make violations structurally impossible - a doer agent cannot call the merge tool
- Encryption at rest

Grounded in production sprints across C++, Node.js, Python, and ML. Attendees leave with reusable patterns for securing multi-agent systems on real infrastructure.

Everyone's heard the AAIF framing: MCP handles agent-to-tool, A2A handles agent-to-agent. Clean in theory. In practice, every multi-agent system lives at the boundary of both, and that boundary has no standard.
Context gets dropped. Errors go silent. A state that survived an entire A2A task lifecycle vanishes the moment it crosses into an MCP tool call. Nobody is talking about this publicly.
This session replaces the "vertical vs horizontal" mental model with something more honest: a precise seam diagram showing what each protocol guarantees, what it doesn't, and what falls into the gap. We'll go deep on MCP's Tasks primitive (SEP-1686)- including its two admitted gaps: no retry semantics, no expiry policies. We'll map the real failure modes developers are hitting today, drawn from open GitHub issues across both protocol repos.
Then a live demo using Google's open-source A2A sample repo: no custom code. We'll run a real multi-agent task, cross the protocol boundary, sever the trace header, and watch the silent failure happen in real time.
You'll leave with a clear mental model, a three-point failure checklist, and a concrete picture of what the spec needs next.

As the ecosystem for the Model Context Protocol (MCP) expands, developers are hitting a familiar wall: token bloat. While MCP provides a powerful standardized interface for LLMs to interact with external data, the "context tax" of verbose tool definitions and massive data payloads can quickly degrade performance and spike costs. To build production-ready agents, we must move beyond basic implementations and embrace advanced orchestration.

This session dives into the architecture of efficient MCP server design, focusing on the "Code Mode" technique. We will explore how to shift the heavy lifting from the LLM’s reasoning space to the server’s execution environment. Instead of forcing the model to process raw, unrefined data, "Code Mode" empowers the LLM to generate and ship logic—miniature, execution-ready scripts—directly to the MCP server. This approach minimizes round-trip latency and drastically reduces the input tokens required for complex data manipulation.

Building an AI sales assistant means pulling data from everywhere , Salesforce for accounts, Snowflake for product catalogs, and internal KBs for pricing. We started by hardcoding each integration into the agent. It worked until every new data source meant rewriting agent code, duplicating auth logic, and redeploying everything. Tool definitions were tightly coupled, making it impossible to evolve the data layer independently.MCP changed everything. In this talk, I'll walk through how we built a production AI sales assistant using LangGraph connected to multiple MCP servers ,each wrapping a different backend, owned by a different team. I'll cover: why direct integrations become unmaintainable at 3+ sources; our reusable FastMCP server template that spins up domain-specific servers in days; how a user's SSO token flows end-to-end from agent through MCP to Snowflake OAuth with zero credential storage; why tool descriptions and agent prompts matter more than the protocol itself , and the patterns we developed (normalize-before-search, dynamic prompt injection) to make the LLM reliably pick the right tool; and what broke in production with real failures and real fixes.