Skip to content

CHAP vs MCP elicitation

Jump to bottom
Arsalan Shahid edited this page Aug 25, 2026 · 1 revision

MCP elicitation asks a user for information during an MCP interaction. CHAP records accountable work among humans, agents and services across a longer-lived collaboration.

Short answer

MCP elicitation and CHAP solve different problems.

MCP elicitation lets an MCP server request extra information from a user through the client. The current MCP specification defines form mode for structured input and URL mode for sensitive interactions that should happen outside the MCP client. The result of a form interaction is an accept, decline or cancel action with optional content.

CHAP defines the shared work around that interaction. It represents participants, authority, tasks, artefacts, review requests, approvals, rejections, overrides, abstentions, escalations and a verifiable evidence chain. An elicitation can be the interface through which a person makes a CHAP decision, but it is not the decision record itself unless an application deliberately turns it into one.

Comparison

Question MCP elicitation CHAP
Primary job Request additional user input during an MCP operation Coordinate and evidence accountable human-agent work
Typical boundary MCP server, client and user Humans, agents, services and groups in a workspace
Core unit An elicitation request and response A signed envelope in a task and artefact lifecycle
Response semantics Accept, decline or cancel Approve, reject, override, abstain, escalate and more
Human modification A user can review and modify a form response An override can carry a structured diff, rationale, tags and intent classification
Authority model Application-defined Explicit participants, workspace membership and policy enforcement
Persistence Determined by the MCP application Append-only, hash-linked evidence is part of the protocol model
Sensitive input URL mode keeps the sensitive interaction outside the MCP client CHAP recommends opaque artefact references and external content storage for sensitive payloads
Relationship Can provide a user interaction for a CHAP method Can be exposed through MCP and can cite MCP tool calls

Why they are easy to confuse

Both appear at the moment an agent needs a person. A server asks a question, a user sees a prompt, and work continues after the response. At the interface level, this can look like human-in-the-loop approval.

The difference appears when someone asks what must still be understood six months later:

  • What exactly did the agent propose?
  • Was the person authorised to approve it?
  • Did the person accept it unchanged or modify it?
  • What changed, and why?
  • Which policy and operational mode applied?
  • Which tool result or external agent output supported the proposal?
  • Can another implementation verify the sequence?

MCP does not claim to standardise that broader accountability model. Elicitation is deliberately focused on requesting input while an MCP interaction is in progress. CHAP focuses on the durable collaboration state around the request and response.

A concrete example

Suppose an agent prepares a customer refund and calls an MCP server that requires human confirmation.

With MCP elicitation alone, the server can ask the client to show the amount and request confirmation. The user can accept, decline or cancel. The application may keep its own record of the exchange.

With MCP and CHAP together:

  1. The agent completes a CHAP task with the proposed refund as an artefact.
  2. The agent sends review.request to an authorised human participant.
  3. The MCP server uses elicitation to gather the person's response through the existing client.
  4. An unchanged confirmation becomes decide.approve.
  5. A changed amount becomes decide.override, including the structured difference and rationale.
  6. A refusal becomes decide.reject, with the reason if the reviewer provides one.
  7. The executed MCP tool call can be cited with input and output hashes in the CHAP evidence chain.

The user experience can remain a familiar MCP confirmation dialog. CHAP supplies portable meaning and evidence behind it.

Two ways CHAP composes with MCP

MCP inside CHAP work

An agent in a CHAP workspace can call an MCP tool and cite the invocation in the resulting CHAP artefact. Input and output hashes establish the boundary without copying the full MCP transcript into CHAP.

CHAP exposed through MCP

A CHAP Coordinator can present CHAP methods as MCP tools. Existing MCP-aware clients can then create workspaces, submit tasks, request reviews and read audit evidence without adding a new transport to the client.

These patterns can be combined. A client can drive a CHAP workspace over MCP while an agent in that workspace calls other MCP servers to perform work.

When MCP elicitation is enough

Use MCP elicitation by itself when the interaction is local, short-lived and the application's own record is sufficient. Examples include asking for a missing format choice, confirming a low-risk preference or redirecting a user to a secure external flow.

Add CHAP when decisions must travel across systems or organisations, when modified outputs need a standard representation, when multiple people or agents share responsibility, or when the evidence must remain verifiable independently of one application's UI and database schema.

What using both does not solve automatically

Neither protocol decides whether a person is competent, whether a policy is fair, or whether a request should exist at all. Authentication, authorisation, privacy controls, retention rules and interface design still require deliberate implementation. Protocol evidence makes those decisions inspectable. It does not make them correct.

Related pages

Primary sources

If this distinction is useful, star CHAP and tell us which MCP client or server you want to connect in Discussions.

Last reviewed: 25 August 2026.

Clone this wiki locally