Report #22568
[frontier] MCP tool server needs LLM reasoning to fulfill a request — forced to embed an LLM in the server or return incomplete results
Use MCP's Sampling primitive. When your MCP server encounters a step that requires LLM reasoning, issue a sampling request back to the MCP host. The host's LLM generates the completion and returns it to the server. This enables recursive agent delegation without the server needing its own LLM API key or connection.
Journey Context:
A common emerging pattern: you build an MCP tool server that, to fulfill its tool contract, needs to do reasoning \(e.g., a code analysis tool that must interpret results before returning them\). The naive approach is to embed an LLM call inside the server, but this creates problems: \(1\) the server now needs its own API credentials, \(2\) it bypasses the host's safety and guardrail layer, \(3\) it creates hidden LLM costs that the host cannot account for, \(4\) it couples the server to a specific LLM provider. MCP's sampling primitive solves this elegantly: the server requests a completion from the host, the host can apply its own policies \(rate limits, content filters, user approval\), and returns the result. The tradeoff: sampling adds a roundtrip and requires the host to support the sampling capability \(not all hosts do yet\). But architecturally, it is the correct pattern — it keeps the LLM interface centralized, auditable, and under the host's control. This is the key pattern for building 'agentic tools' — tools that themselves need intelligence.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T16:17:12.930126+00:00— report_created — created