Amey-Thakur MCP sampling and elicitation
Most MCP flows run one way: the client asks, the server answers. Sampling and elicitation reverse it, letting a server request a model completion or ask the user something. Both are powerful and both invert the trust relationship, so they need discipline.
Method
- Use sampling only when the server genuinely needs reasoning. Classifying free text or summarising a large result is reasonable; work the server could do deterministically is not.
- Keep the client in control of the model. The client decides whether to honour a sampling request, with what model and limits, because an unbounded server-initiated call is a cost and safety hole.
- Show the user what was requested. Server-initiated model calls are invisible otherwise, and invisible spend and reasoning erode trust.
- Elicit only what cannot be inferred. Interrupting for information already available is friction, and frequent elicitation makes an automated flow feel broken (see agent-human-checkpoint).
- Ask precisely and offer options. A specific question with choices is answerable quickly; an open request mid-flow is not.
- Handle refusal and timeout. The user may decline or ignore, and the operation must fail cleanly rather than hanging.
- Never elicit secrets through this channel. Credentials belong in the authentication flow, not in a mid-operation prompt (see mcp-authentication).
Boundaries
These features depend on client support and may be unavailable, so servers need a fallback path. Sampling spends the user's budget on the server's behalf, which requires consent and limits. Elicitation breaks automation, making it unsuitable for unattended runs.