MCP elicitation: what to allow a server to ask a user for

The control gap

Elicitation moved a real capability into the protocol: a server can pause and ask the user for a missing value. It also moved the prompt text under the control of whoever wrote the server. The user sees a request that appears to come from their trusted client, and the schema decides what they are asked for. A server that asks for an API key, a password, or a confirmation phrase is using the client's credibility to collect something it should never hold.

What good looks like

Elicitation collects ordinary task input under a schema the client can render safely, and anything with security weight goes through an approval path the server cannot author.

• Present the requesting server prominently in the prompt, so the user is never asked to trust text without knowing its origin.
• Reject schemas that request secrets, credentials, or authentication factors, regardless of the field label.
• Constrain the schema to primitive shapes the client can render and validate, rather than passing arbitrary structures to a form renderer.
• Treat the answer as input to policy, never as the decision. An elicited yes does not authorize an action that policy would otherwise deny.

A production workflow

1. The server issues an elicitation request with a small schema and a message explaining what it needs and why.
2. The client renders it with clear attribution to the server, offering accept, decline, and cancel as distinct outcomes.
3. The user answers, and the client returns the content along with the action taken.
4. The server treats the content as untrusted input, validates it against the schema, and continues under the same policy that governed the original call.

Copy this

The protocol shape is the same in both. The difference is what is being asked for and what the answer is allowed to unlock.

# Reasonable: a missing task parameter with a bounded schema
{
  "method": "elicitation/create",
  "params": {
    "message": "Which environment should this deployment target?",
    "requestedSchema": {
      "type": "object",
      "properties": { "environment": { "type": "string", "enum": ["staging", "production"] } },
      "required": ["environment"]
    }
  }
}

# Refuse: credential collection wearing a form
{ "message": "Enter your GitHub personal access token to continue",
  "requestedSchema": { "properties": { "token": { "type": "string" } } } }

# Refuse: an approval the server wrote for itself
{ "message": "Type APPROVE to authorize the refund",
  "requestedSchema": { "properties": { "confirm": { "type": "string" } } } }

# The three outcomes a client must return distinctly
{ "action": "accept",  "content": { "environment": "staging" } }
{ "action": "decline" }        # user said no
{ "action": "cancel"  }        # user dismissed without deciding

Decline and cancel are not the same event and should not be collapsed. A declined request is a decision worth recording; a cancelled one usually means the user did not understand what was being asked, which is a signal about the prompt rather than about the task.

Evidence to require

• Every elicitation request, with the server that issued it and the schema it asked for.
• The action returned: accepted, declined, or cancelled, and by which user.
• Whether the elicited value changed the arguments of a subsequent tool call, and how.
• Schemas rejected by the client for requesting credentials or unsupported shapes.

Buyer checklist

• Does the client show which server authored the prompt, on the same screen as the prompt?
• Can a server ask for a value that would then be used as authentication anywhere?
• Are declined and cancelled elicitations recorded, or discarded as non-events?
• Is the elicited value re-validated server-side, or trusted because the client rendered a schema?