Is your feature request related to a problem? Please describe.
Sampling in its current form is a powerful tool, featuring support for:

• Preloaded message histories: The server can preload a conversation history in the messages property of the sampling request, and have the client LLM generate the next message in the conversation. The server can also send new sampling requests with any subset (real or fictional) of a conversation history to induce a given client response (setting context security aside for the moment -- that is important but deserves its own discussion).
• Context sharing: The server can summarize information into the systemPrompt property to bootstrap a collaborative task. The server can also suggest a context the client should use when responding, via the undocumented includeContext property.
• Nested execution: The server can dispatch sampling requests at any time, such as within an active tool call. Combining tool calls with sampling enables collaborative task execution.

Despite being documented as a solution for agentic behaviors, sampling has seen very limited uptake for this purpose, even in toy examples. Issues and discussions related to sampling are also scarce, and only a small number discuss improvements that can be made for agent communication (honorable mentions: #105, #124, #186). The proposed spec for elicitations (#382) also overlaps significantly with what sampling in its flow, but has a distinctly-different use case (requesting data from a human, bypassing model ambiguity).

I think the understated importance of sampling is the result of several interrelated issues:

1. Poorly-documented usage patterns: I imagine this is at least partially because demonstrating how sampling can actually be used is hard to do in an easily-digestible manner. I tried my hand at a simple two-agent deep sequence diagram and it's 63 lines long (I'll include it in a separate comment). Usage with tools is actually not discussed at all in either the specification or the docs, which is a huge gap when it comes to conceptualizing sampling in general. It's very unintuitive to imagine sampling outside of the context of using it in response to a tool call (even if there may be use cases for this). This is really a microcosm of a broader documentation gap around building end-to-end MCP applications.
2. Documentation noise: A significant portion of the sampling specification and documentation is devoted to clarifying the usage of modelPreferences, which is perhaps the least-important aspect of the specification.
3. Lack of cohesion with other protocol elements: Resources and Embedded Resources are not supported as message types.
4. Lack of client support: Almost zero end-user clients support sampling at all, likely because few servers use it (and servers are unlikely to use it if clients don't support it).

Describe the solution you'd like

1. Update the documentation to offer specific working examples of sampling in at least one SDK.
2. Update the documentation and the specification to discuss using messages and systemPrompt for interesting tasks.
3. Update the documentation and the specification to discuss using sampling with tool calls and other specification features.
4. Revise the specification to add support for Resources and Embedded Resources in sampling messages.
5. Revise the specification to define the existing includeContext property.

Describe alternatives you've considered

• A2A and ACP support agent-to-agent communication with their own mechanisms on top of MCP, and interestingly don't mention sampling in their justifications for standing up new agent-oriented protocols at all -- I don't believe that this was (entirely) for business/product reasons, but rather is a consequence of the how the specification and documentation don't do a good job of framing sampling as a potential solution for that problem.