ADR 0405: One Standards MCP tool and atomic proposal batches

Status: accepted on 2026-09-16. Amends ADR 0339 and ADR 0354.

The MCP surface exposed discern_standards for measurement and pinning beside discern_standards_propose for one proposal. The distinction made two closely related public tools compete for agent attention. The scalar proposal contract also turned simultaneous breaches into a sequence of config commits: every later proposal made earlier bindings stale and forced caller-managed renewal.

MCP clients may give only a leading portion of a server's tool list immediate attention. The server already orders its tools deliberately, but its seven-item lifecycle prefix left an expensive standalone test tool close to that boundary while map discovery was much later.

The MCP surface has one discern_standards tool with a required action of measure or propose. Measurement retains names, force, and pin. Proposal accepts an ordered array of unique { name, reason } entries. The existing scalar discern standards propose CLI command remains available as a compatibility surface, but it is not a separate MCP tool.

One proposal action validates every request before effects, measures every selected Standard against one clean committed HEAD through the shared producer planner, changes every selected limit in one config-only commit, and binds every proposal record to that commit. Reasons carry technical justification only; consent and landing authority remain separate exact evidence. A changed value or reason requires fresh owner agreement.

Atomic reconciliation with already recorded proposals and carrying gate Proof across the proposal commit remain separate follow-up work. Until reconciliation exists, a batch that would create a new proposal refuses any existing active or stale proposal state before measurement or writes rather than creating sibling staleness.

The MCP lifecycle prefix contains exactly eight tools in this order: status, start, prepare, done, update, await, accept, and map. Progress and the standalone test tool follow it. This is a bounded-client discovery invariant, not a claim about one client's fixed loading threshold.

Agents have one Standards entry point and can record simultaneous breaches without proposal-created sibling staleness. Shared producers execute once inside a batch, and a repeated identical batch is idempotent. The required action makes the tool's intent explicit at validation and in the logbook. Removing one MCP tool and moving map into the eight-tool prefix improves relative discovery without changing the complete tool inventory's behavior.

Existing proposals are deliberately not reconciled with new batches yet. Proposal commits still invalidate exact Proof in the ordinary way, so the documented post-proposal gate remains required until a separately proven carry-forward path exists.