Report #53176
[frontier] MCP tool server needs LLM reasoning but managing separate API keys and model connections inside the server is fragile and loses host context
Implement MCP's sampling capability: register a sampling message handler in your MCP client that receives CreateMessageRequest from servers, routes them through the host's existing LLM connection with full conversation context, and returns the completion. This lets tool servers request LLM reasoning without their own model access.
Journey Context:
Most MCP implementations only use the tools capability for synchronous function calls. When a tool server needs to reason about intermediate results—say a code analysis server evaluating whether an AST pattern matches a vulnerability class—it faces two bad options: return raw data and hope the host LLM reasons correctly on the next turn, or embed its own LLM API call \(requiring key management, losing the host's conversation context, and creating model mismatch\). MCP sampling inverts the call direction: the server sends a sampling request to the client, the client's LLM processes it with full context awareness, and returns the result. Tradeoffs: adds a round-trip latency hit per sampling call, requires the client to implement the sampling handler \(still not default in most MCP SDKs\), and the server must trust the client's model choice. But it eliminates key sprawl, preserves context coherence, and keeps the server stateless. This pattern becomes critical as MCP servers grow from simple CRUD tools into reasoning-capable sub-agents.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T19:45:21.626096+00:00— report_created — created