evaluate input_required (elicitation) for actions only a person should authorize #755

New issue

Open

opened 2026-10-13 19:11:11 +00:00 by hexajon · 0 comments

hexajon commented

2026-10-13 19:11:11 +00:00

Owner

New in the protocol

Revision 2026-07-28 adds a multi-round-trip request model (SEP-2322) and a per-request protocol marker (SEP-2575). It introduces one result field: resultType.

How resultType works

resultType has exactly two values (go-sdk v1.8.0, mcp/protocol.go):

complete: the call is finished, the result is final. This covers success AND error. Error-ness is carried separately, by isError.
input_required: the call is paused. The server returns InputRequests; the client must supply them and retry the call.

The axis is "finished vs paused for the client", not "success vs error". The server stamps the field once, in setCompleteResultType (go-sdk mcp/server.go). A conforming 2026-07-28 client rejects a result that omits it. madtea sends only complete today, and the terminal path that drops the field is the bug tracked in #740. input_required is unused: madtea has no paused flow.

Why input_required is worth using

Use it where the needed input is a person's decision that the caller may not make alone. Do not use it for substance the caller owes. A close reason stays a required field (#167: elicitation is for consent, never for substance the caller owes). The test is "whose call is this", not "is it dangerous".

The caveat that decides if it is real

Elicitation asks the client. The client is not always a person. An unattended run can answer the prompt on its own. So input_required gates a person's decision only when a person is guaranteed to answer. Without that guarantee it is a convenience prompt, not an authorization boundary. For an unsafe action with no person present, a refusal is the stronger guarantee.

Candidates to classify

Sort each refuse-and-require or confirm-flag surface on two axes. First: is the action the caller's call, or a person's. Second: is a person guaranteed to answer.

Issue hard-delete (today refused on every surface).
madt_prune content-verified branch deletion.
The removed overrides (force_merge, --admin); no_revert stays.
Plaintext-credential consent (--insecure-storage).

Scope

Product behavior: it must work for any user's config, not encode one policy.
Depends on #740 first. Do not build the paused path while the terminal path still drops resultType.
I decide the posture: which actions gate, and whether a prompt may stand in for a person.

## New in the protocol Revision 2026-07-28 adds a multi-round-trip request model (SEP-2322) and a per-request protocol marker (SEP-2575). It introduces one result field: resultType. ## How resultType works resultType has exactly two values (go-sdk v1.8.0, mcp/protocol.go): - `complete`: the call is finished, the result is final. This covers success AND error. Error-ness is carried separately, by isError. - `input_required`: the call is paused. The server returns InputRequests; the client must supply them and retry the call. The axis is "finished vs paused for the client", not "success vs error". The server stamps the field once, in setCompleteResultType (go-sdk mcp/server.go). A conforming 2026-07-28 client rejects a result that omits it. madtea sends only `complete` today, and the terminal path that drops the field is the bug tracked in #740. input_required is unused: madtea has no paused flow. ## Why input_required is worth using Use it where the needed input is a person's decision that the caller may not make alone. Do not use it for substance the caller owes. A close reason stays a required field (#167: elicitation is for consent, never for substance the caller owes). The test is "whose call is this", not "is it dangerous". ## The caveat that decides if it is real Elicitation asks the client. The client is not always a person. An unattended run can answer the prompt on its own. So input_required gates a person's decision only when a person is guaranteed to answer. Without that guarantee it is a convenience prompt, not an authorization boundary. For an unsafe action with no person present, a refusal is the stronger guarantee. ## Candidates to classify Sort each refuse-and-require or confirm-flag surface on two axes. First: is the action the caller's call, or a person's. Second: is a person guaranteed to answer. - Issue hard-delete (today refused on every surface). - madt_prune content-verified branch deletion. - The removed overrides (force_merge, --admin); no_revert stays. - Plaintext-credential consent (--insecure-storage). ## Scope - Product behavior: it must work for any user's config, not encode one policy. - Depends on #740 first. Do not build the paused path while the terminal path still drops resultType. - I decide the posture: which actions gate, and whether a prompt may stand in for a person.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#755

No description provided.

Rows
Columns