ADR-134: A builtin's declared write effect implies human approval 

A remote tool's effect is not its consent 

The effect coupling stops at the remote boundary, and that is load-bearing, not a convenience.

McpTool::getEffect() returns NON_IDEMPOTENT_WRITE for every imported tool, a pure search tool included. That value is a fail-closed assumption about a body this codebase cannot inspect (ADR-116: Central tooling authority — nr_llm owns builtin + MCP tools), not the tool's statement about itself. Treating it as one would suspend every MCP tool on every call and leave the shipped MCP client unusable.

The remote axis therefore has a source of its own, and it is not the server: the readOnlyHint annotation is stored verbatim for display and read by no resolver, because a remote server must not be able to influence its own authorisation. It is an operator-declared, server-level column, added below.

The operator declares it, per server 

tx_nrllm_mcp_server.requires_approval is that column, built like data_class beside it (ADR-094: Tool data classes and provider trust zones): the operator declares it, the server never does, and there is no code here to derive it from.

It differs from data_class in having a default, and defaults to 1 — approval required. A data class has no safe guess, so an undeclared server is inert instead. A yes/no does have one: a server nobody has judged asks first. The reading is fail-closed the whole way down — McpServerRecord::approvalRequired() treats only a literal 0 as "no approval", so a missing column, a NULL, an empty string or a value from a schema this version does not know all come back as "required". The alternative would be a byte this code cannot read letting an unattended remote write through.

The flag reaches the scan on the tool, not through a lookup. McpToolProvider already builds every McpTool from the very server record that carries it, so it is a constructor argument, surfaced by RemoteApprovalInterface::requiresApproval(). The scan runs once per tool call in the loop; giving it a repository would put a query on that path and a persistence dependency into a class that must not know MCP exists.

RemoteApprovalInterface extends RemoteToolInterface deliberately. A free-standing "declare your own approval" interface would quietly make a write-without-approval builtin expressible again, which the last section of this ADR says is not to be. Extending the remote marker means a class cannot reach for the declaration without also claiming that its behaviour lives outside this codebase — the one case in which an operator declaration beats reading the code.

Every server requires approval, existing ones included. The default of 1 lands on every pre-existing row when the schema updates, and nothing corrects it afterwards: there is no upgrade wizard, and the state after an update is the state after a fresh install. The assurance therefore rests on the schema alone, which is what McpServerApprovalDefaultTest pins by dropping the column, writing a row the way the previous version did, and running the add/change migration PackageSetup runs.

A pinned install was the alternative, in the shape of ADR-113: Fail-closed tool data-class enforcement switch/ADR-115: Tool data-class enforcement is the default for new installs: a wizard that writes an explicit 0 on the servers already importing tools, so a new default cannot stop an integration that runs today. It was written and then removed. MCP here is planned and not yet in production use, so the running integrations such a wizard preserves do not exist, and what remained was a fail-open path through the very assurance this decision introduces — one that, matching on the value rather than its origin, could not tell a 1 the schema wrote from a 1 an operator chose, and so would have switched approval off on a server nobody had judged.

Turning the flag off is an operator's decision, taken per server once they know what that server's tools do. It is a tick in the record, not something an upgrade does on their behalf.

Registration bans the implicit combination too 

ToolRegistry already refuses a tool that implements both RequiresApprovalInterface and RequiresInputInterface (ADR-105: Typed user-input suspension (WAITING_FOR_INPUT)): the approval-resume path carries no user input, so the combination is unsupported. This decision makes a declared write a second way to be approval-bound, and the ban therefore extends to it — a non-remote, write-declaring tool may not implement RequiresInputInterface either.

The extension is not defensive tidying. Without it the combination is not "handled by the runtime", it is dead:

1. The approval scan runs before the input scan, so the tool suspends AWAITING_APPROVAL, never WAITING_FOR_INPUT.
2. ToolLoopService::resume() refuses an input-requiring pending call ("requires user input that was not provided") — correctly, since the approval path carries no data.
3. The model re-requests, the approval scan binds again, and the cycle repeats: one operator decision spent per turn and the tool never executes.
4. submitInput() is unreachable. It requires status WAITING_FOR_INPUT, and the approval suspension's SuspendedRunState carries neither inputToolName nor inputSchema.

The refusal in step 2 is the mechanism of the defect, not its handling: it is what makes the cycle permanent. Nothing in the run reports the cause, and the operator sees only a tool that asks and asks. A registration failure at container boot names it.

What this costs is real and is the cost ADR-105: Typed user-input suspension (WAITING_FOR_INPUT) already accepted: a tool that needs both a human's data and a human's consent cannot be built. The runtime has no combined approval+input pause — ADR-105 banned the combination rather than build one — so allowing the declaration would promise a flow that does not exist.

The registration predicate mirrors the loop's, remote exemption included, so it can never reject a tool the approval scan would have let through. It sits in the constructor, which sees only the compile-time builtins; provider-supplied tools (the remote ones) are exempt from the coupling anyway.