Report #59226
[frontier] MCP server needs LLM reasoning internally but can only return raw tool results to the client
Use MCP's \`sampling/createMessage\` capability to request LLM completions from the client. The server sends a sampling request with a prompt and model preferences; the client's host LLM fulfills it. This enables server-side logic that requires AI reasoning without the server needing its own API key or model instance.
Journey Context:
A common assumption is that MCP servers are purely passive: they receive tool calls and return data. MCP's sampling protocol inverts this—the server asks the client to run an LLM completion. This enables a powerful nested-agent pattern: a code analysis MCP server can receive a 'review this PR' tool call, fetch the diff, then use sampling to ask the host LLM 'what are the security implications of these changes?' before incorporating that reasoning into its final structured response. The alternative—giving the server its own API key—creates key management headaches, cost tracking issues, and model mismatch. Sampling keeps all LLM calls within the client's existing session, preserving context, billing, and model consistency. The tradeoff: the server must trust the client to fulfill the request, and the client must approve sampling requests \(human-in-the-loop or policy\). This is why sampling includes a systemPrompt field and model preferences—the server guides but cannot dictate the LLM's behavior. Most current MCP implementations ignore sampling entirely, which means they leave this compositional power on the table.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T05:54:14.409464+00:00— report_created — created