AGNTCon + MCPCon Europe 2026

An end-to-end deep dive into how a new spec goes from idea to a production, stable release. In this session, you will learn more about the MCP governance process, Spec Enhancement Proposals (SEPs) and how all of this work translates into a brand-new MCP spec that then is adopted by the agentic space at large!

MCP is becoming stateless in one of the largest changes to the protocol since its launch.

This change simplifies the deployment of robust servers, making MCP ready for the next wave of scaled usage driven by agents and use cases like MCP Apps.

This session led by members of the Transports Working Group:
- Explores the upcoming changes - and sharing real data from Google and Hugging Face on the motivation behind them.
- Details the latest approaches on handling serverless Elicitation, Sampling and Sessions.
- Introduces the application and infrastructure patterns that can take advantage of the stateless protocol.

We'll also update on the latest roadmap status and expected migration timelines and approach

MCP's new Tasks primitive makes tool calls asynchronous: a request returns a durable handle now, and the result arrives later. That's the right model for work that runs for minutes or hours, like ETL jobs, deep research, or batch reasoning, but the spec leaves the hard parts to implementers.
Where does in-flight work live? How does a task survive a restart? How do you deliver a result exactly once and let multiple clients subscribe to it?

This talk argues that an append-only event log is a natural backend, because a Task is a state machine and a state machine's history is just an ordered log of its transitions. We walk a concrete, vendor-neutral implementation: creation, status, and completion become events, recovery becomes replay, and the server can go stateless, lining up with MCP's roadmap. We dig into the failure modes that bite in production: orphaned tasks, duplicate side effects, and at-least-once versus exactly-once delivery, plus the gaps the 2026 roadmap is still closing around retry and expiry.

You'll leave with a reference architecture you can build on any log or queue, and an honest view of what Tasks gives you today and what it doesn't yet.

MCP Conformance testing is a set of tools for ensuring SDK's implement the spec in a way that's compatible with each other.

The most recent spec revision 2026-07-28 is the first release that requires conformance testing as a part of the Specification Enhancement Proposal (SEP) process. This talk will go over lessons learned from the rollout of that specification, and also introduce hosted conformance testing that clients and servers can use to test their deployed implementations.

People frequently assume MCP requires tools to be dumped straight into the system prompt, and responses to be returned straight to the model. Critics say the protocol has a context problem, that CLIs and agent skills are more efficient and composable. They're right about the symptoms, but wrong about the diagnosis. The problem isn't MCP - it's for a long time few had applied serious context engineering to it.

Through a self-built agent harness (mcpi), I will demonstrate three complementary strategies for progressive tool discovery over MCP - each paying only the context tokens it needs.

This talk focuses on the most transformative of the three: skills over MCP that describe the tool surface, and progressively enable tools upon skill invocation. I will also look at MCP CLIs and Code Mode approaches, and show how they can complement each other with their different strengths.

Attendees will leave with practical patterns they can implement in their own MCP servers and agent harnesses today.

As agents evolve from quick tool calls to work that unfolds over hours or even days, MCP servers need to do more than expose tools. They need to teach agents what work they are suited for, how to sequence it, how to monitor progress, when to involve a human, and recognize when results have actually landed.

This talk presents a practical quality bar for MCP servers that support long-horizon agentic work. We'll discuss patterns for describing capabilities, guiding workflows, coordinating changes across services and validating outcomes, drawing on lessons from building effective MCP apps and plugins inside of ChatGPT and Codex. These patterns let us separate enduring design principles from changing protocol details, and discuss how today’s servers can adapt as tasks, triggers, resources, skills, and related MCP capabilities evolve.

MCP creates a common way for models to use tools, but production use still breaks down when reliability expectations are left implicit. This talk argues that MCP systems need explicit reliability contracts covering permission boundaries, tool-call semantics, retries, observability, and recovery behavior. It will show how multi-step failures emerge in real tool-use chains and how traces, evals, and protocol-aware safeguards can make those failures debuggable instead of mysterious. The session also covers design patterns for graceful degradation when tools, transport layers, or model reasoning do not behave as expected. Attendees will leave with a concrete framework for making MCP-based systems more trustworthy in real deployments.

Prompt injection ends when the session ends. Memory poisoning doesn't.
As enterprise agents mature, three attack surfaces are converging: MCP server trust, agent skill libraries, and long-term memory retrieval. Each is dangerous in isolation. Together, they create a threat model most teams aren't yet reasoning about.

MCP enables agents to acquire tools dynamically, including from servers never explicitly authorised. Agent skills package reusable behaviours that can be poisoned at the source. Memory systems built on vector retrieval treat past experience as trusted context, with limited provenance validation.

The MINJA research (NeurIPS 2025) demonstrated injection success rates approaching 98% across GPT-4o, Gemini, and Llama-based agents. Crucially, better reasoning models don't solve this - they may amplify it. A more capable model becomes more faithful to a poisoned memory once retrieved.

OWASP's 2026 Agentic Top 10 dedicates a standalone category: ASI06 Memory and Context Poisoning.

This session maps the attack chain, shares real enterprise exposure patterns, and offers a framework for memory provenance tracking, skill validation, and MCP server trust evaluation.

MCP borrowed its design from the Language Server Protocol. It skipped LSP’s hardest lesson, the one about packaging and trust, and a decade later that lesson is still unlearned.

LSP never standardized how servers were packaged or verified. Each editor invented its own channel, the VS Code extension format won by default, and signing was bolted on much later, marketplace by marketplace. It still has not closed the gap.

MCP repeats this with a larger blast radius. An MCP server runs arbitrary code that reaches into credentials, data, and local systems. Today’s packaging work falls short: the official registry delegates trust to npm and PyPI, the MCPB format repeats the VS Code extension model, and the provenance that exists is locked inside vendor silos.

What is missing is open, registry-neutral provenance verified before an agent loads a server. That standard does not need inventing. Packaging MCP servers as OCI artifacts inherits the signing, attestation, and policy tooling the container ecosystem already proved. This talk traces that history firsthand, then shows how to reuse it rather than rebuild it registry by registry.

The session opens with the pre-deployment checklist, seven controls, no preamble, then walks through the evidence for why each one exists. This audience deploys MCP in production and needs to leave knowing what to do.

The empirical baseline: 30+ CVEs in 60 days. 24,008 secrets in public MCP configs. 85% attack success rate against major hosts (MCPSecBench, ICLR 2026). Reported as lower bounds with stated provenance.

Three attack classes, demonstrated with lab code. Tool description poisoning: exfiltrates an SSH key simultaneously. Cross-server shadowing: a trusted WhatsApp server weaponised by a malicious daily-facts server, end-to-end encryption intact. The rug pull: postmark-mcp, reconstructed.

The protocol gap analysis is the content specific to this audience. I show the SDK code implementing the flat namespace, the spec text that acknowledges the trust boundary but enforces nothing, then four protocol changes with concrete JSON-RPC schema diffs: today's schema, the addition, the attack class it closes. The finding that changes model selection: more capable models follow poisoned instructions more reliably.

No vendor tools. Source: github.com/aminrj-labs/mcp-attack-labs.