Report #48276
[frontier] MCP server needs LLM reasoning but has no model access, forcing all intelligence to the client side and creating awkward context splits
Use MCP Sampling \(sampling/create\_message\) to let MCP servers request LLM completions through the client. The server sends a sampling request with its prompt and preferred model parameters; the client's LLM processes it and returns the result. This enables MCP servers to perform intelligent data transformation \(summarization, classification, entity extraction, ranking\) without direct model access or API keys.
Journey Context:
The common assumption is that MCP servers are 'dumb' tool/resource providers and all LLM reasoning happens at the client/agent level. But this creates an awkward split: a database MCP server knows its schema and query results best but can't reason about them — it returns raw data that the client must interpret without domain context. The sampling primitive inverts this: the server can request LLM help from the client, enabling it to do things like 'given this query result, extract the key anomalies' or 'classify this error log by severity'. The server crafts the prompt; the client provides the LLM compute. Tradeoff: this creates a dependency \(server depends on client having an LLM\) and raises security concerns \(the server crafts prompts that execute on the client's LLM — the client must approve sampling requests\). The emerging pattern is to use sampling for server-side data transformation \(summarize, filter, rank, extract\) while keeping decision-making and tool selection at the client. This makes MCP servers significantly more capable without requiring them to bundle their own LLM or API keys. Most developers don't even know this feature exists yet.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T11:30:55.529182+00:00— report_created — created