MCP Sampling & Elicitation: When Servers Talk Back
written by Stefan Christoph
From Request-Response to Collaboration
When I wrote about the CLI vs MCP debate [1], I focused on the infrastructure patterns underneath. But MCP itself has been evolving, and the latest additions change what’s architecturally possible.
The Model Context Protocol is best known as a clean way for AI agents to call tools: agent sends request, server returns response. Simple, effective. Tool calling was only ever one of MCP’s capabilities, the spec included prompts, resources, capability negotiation, and even server-initiated sampling early on, but request-response tool calls are how most of us have used it. Real-world agent workflows need more than request-response. They need the server to ask questions back.
As of the 2025-11-25 spec revision, MCP supports three server-initiated collaboration patterns [3][4]. These are part of the open MCP specification, not vendor-specific: clients advertise support for them through capability negotiation, and servers can use whichever patterns the connected client supports. Amazon Bedrock AgentCore Runtime is one production runtime that supports all three [2].
The Three Patterns
| Pattern | Direction | What It Does |
|---|---|---|
| Sampling | Server → Client → LLM | Server requests an LLM completion for reasoning, validation, or personalization |
| Form Elicitation | Server → Client → User | Server requests structured user input via JSON Schema forms |
| URL Elicitation | Server → Client → External URL | Server directs user to external URL for sensitive interactions (OAuth, payments) |
Sampling: The Server Asks the LLM to Think
This is the most architecturally interesting pattern. A tool server can request that the client’s LLM perform a completion, effectively asking the agent to “think about this” mid-workflow.
Use case: A code review tool that retrieves a diff, then asks the LLM to analyze it for security issues before returning results. The server doesn’t need its own LLM. It requests a completion through the client, which picks the model and mediates the call.
The security model is human-in-the-loop: clients are expected to let the user review or edit the request before it runs, and review the result before it goes back, a client responsibility the spec recommends, not a wire-level guarantee, so servers shouldn’t assume either check happens. The server never gets direct LLM access; it goes through the client. If the user rejects a request, the client is expected to return an error, and the server must handle that gracefully, along with the client that never advertised sampling support, cancellations, and timeouts. These collaboration patterns add failure modes that simple request-response doesn’t have, so well-designed servers need fallback paths.
Form Elicitation: The Server Asks the User
Sometimes a tool needs information that only the user has: a project name, a priority level, a confirmation. Form Elicitation lets the server request structured input via JSON Schema.
This is structurally different from asking a question in chat. Chat returns free text. Form Elicitation returns typed data shaped to the schema the server requested: specific fields, enums, numbers. The server gets structured input instead of a natural language string it has to parse, but schema conformance is enforced client-side, so it remains untrusted input the server still validates.
Constraint: it must not request sensitive data (passwords, tokens). The schema is flat objects only, no nested structures. This keeps the interaction simple and auditable. For complex or sensitive input, that’s what URL Elicitation is for.
URL Elicitation: The Server Sends the User Elsewhere
For sensitive interactions (OAuth flows, credential entry, payment processing) the server directs the user to an external URL. In a correctly designed external flow, the sensitive data never passes through the MCP client, the client sees only the URL and a completion signal. Identity verification isn’t something URL Elicitation does for you: the external flow you build has to provide it. The pattern gives you the redirection, not the verification [3].
This is how you’d implement “Sign in with Google” or “Connect your Stripe account” in an MCP workflow without the agent ever seeing the credentials.
Why This Matters
These patterns transform MCP from a tool-calling protocol into a collaboration protocol. The server isn’t just a passive responder; it’s an active participant that can request reasoning, gather input, and orchestrate multi-step workflows.
A single tool call orchestrating user input, LLM reasoning, and out-of-band approval.
This is a single tool call that involves three collaboration patterns: user input, LLM reasoning, and out-of-band approval. Without these patterns, you’d coordinate the same steps outside the protocol, multiple tool calls stitched together in the application, a state machine, or external callbacks. When the connected client supports them, these patterns move that coordination into the protocol. This is an emerging capability, not an established production pattern yet, but the architecture makes it possible today.
AgentCore Runtime: Stateful MCP in Production
Amazon Bedrock AgentCore Runtime supports all three patterns as stateful MCP server features [2]. The key architectural detail: servers run in dedicated microVMs with session isolation. The session’s in-memory state persists across the collaboration, so the server can keep conversation context between sampling requests and elicitation responses for as long as the session lives, anything that must outlive the session still needs durable storage.
This is different from stateless MCP server deployments (which keep no session state between requests, whatever their process lifetime) and from local MCP servers (which run on the developer’s machine). What AgentCore provides is managed, session-isolated MCP servers in the cloud, dedicated microVMs whose in-memory state lasts the session [2]; availability, recovery, and everything beyond the session lifetime are still yours to design.
The Bigger Picture
MCP is following a loose analogy to the HTTP-era web: starting simple (request-response), then gaining richer interaction through separate mechanisms, WebSockets, Server-Sent Events, HTTP/2 push, each with its own semantics. MCP is much earlier in its lifecycle, and the protocols differ enormously in scope and maturity. But the direction is the same: from “agents call tools” to “agents and tools collaborate.”
For architects building agentic systems, the implication is clear: design your tool servers as collaborative participants, not passive endpoints. The patterns are there. The runtime support is there. The question is whether your architecture takes advantage of it.
💬 Are you building with MCP’s collaboration patterns? What use cases are you seeing?
Sources
[1] My earlier post on infrastructure patterns, “CLI vs MCP: The Wrong Debate”: https://schristoph.online/blog/cli-vs-mcp-the-wrong-debate/
[2] AWS, “Amazon Bedrock AgentCore Runtime supports stateful MCP server features” (March 2026): https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-bedrock-agentcore-runtime-stateful-mcp/
[3] MCP Specification (2025-11-25), Elicitation: https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation
[4] MCP Specification (2025-11-25), Sampling: https://modelcontextprotocol.io/specification/2025-11-25/client/sampling
[5] WorkOS, “Beyond Request-Response: How MCP Servers Are Learning to Collaborate”: https://workos.com/blog/beyond-request-response-mcp
[6] My earlier post on making websites agent-friendly: https://schristoph.online/blog/making-website-ai-agent-friendly/
Related writing:
- The Protocol We Should Have Built for Humans, MCP’s broader evolution: MCP Apps, Linux Foundation donation, 110M SDK downloads
- From Cloud-Native to AI-Native: What Actually Changes, MCP as the connectivity layer for agent orchestration
About the Author
Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.
This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.