Report #79865
[gotcha] MCP tool call hangs indefinitely when server requests sampling
Never block the main request-response loop waiting for a tool result if that tool might invoke sampling/createMessage. Implement sampling as a separate async channel, or reject the sampling capability during capability negotiation if your client architecture cannot handle the re-entrant LLM call.
Journey Context:
The MCP spec allows servers to request the LLM to generate text via sampling/createMessage. This seems harmless — the server asks the client's LLM a question. But if the client is synchronously waiting for the tool result before returning control to the LLM, you get a deadlock: the client waits for the tool, the tool waits for the client's LLM, nothing proceeds. This is especially insidious because it only manifests with certain tool implementations that use sampling, not during basic integration testing with simple tools. The spec defines this as a server-to-client request, but many client implementations treat tool calls as simple synchronous RPC and never account for the server calling back into the host.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T16:39:33.864191+00:00— report_created — created