Tool Approval Propagation and Agent-Oriented MCP Server Design for Large Toolsets #1203

I think the architecture is viable, but I would avoid making the high-level orchestrator tool look atomic if it can trigger sensitive downstream tools.

The clean pattern is to make the composite tool resumable:

• the top-level MCP tool starts an orchestration run and returns a stable run id
• a downstream tool that needs approval pauses before execution and emits a structured pending-approval event to the orchestrator
• the orchestrator returns that pending state to the originating MCP client: downstream tool name, argument digest, resource identity, proposed side effect, approval id, and expiry
• the client approves or denies through a separate approval-response or resume tool
• the orchestrator resumes only if the run id, approval id, argument digest, and resource identity still match; any drift requires a fresh approval

That keeps the user in the loop at the real side-effect boundary instead of approving a vague high-level task and hoping the sub-agent chain stays inside the intended scope.

For the tool-confusion part, I would combine this with progressive disclosure rather than hiding everything behind one broad "do task" tool. Let the client see a small set of task-level tools, but keep an operator-visible receipt that records which downstream tools became reachable, which approvals were requested, and which exact calls executed.

The receipt is the important part for maintainability: it should show both the original orchestration intent and the specific downstream mutation that was approved.

Disclosure: I work on Armorer Labs.

I think there are really two authorization modes being mixed together here, and separating them makes the architecture much cleaner:

Delegation is appropriate when the user has already granted bounded standing authority.

Interactive approval is appropriate when the effective action cannot be authorized until runtime.

Those are not interchangeable.

For example, a user might delegate:

search flights, read calendars, estimate prices

with bounded scope, cost, and expiry. A sub-agent can safely exercise that authority without interrupting the user.

But if orchestration later resolves into:

purchase_ticket(account=X, price=$742)

and that mutation was not covered by the delegated authority, the correct behavior is not to extend the delegation chain. It is to suspend the run and request a new authorization decision for that resolved action.

So I would model the boundary roughly as:

intent -> resolution -> authorization mode -> execution

where the authorization mode is one of:

• delegated: an existing capability or proof covers the resolved action
• interactive: execution pauses until the originating user or client approves
• denied: no applicable authority exists

The important invariant is that authorization is evaluated against the resolved effective action, not merely the high-level orchestration tool.

This also answers the protocol architecture question: putting an orchestrator behind an MCP server is reasonable, but the high-level tool should not be treated as one atomic authorization boundary if it can resolve into materially different downstream effects.

For large toolsets, I would also avoid using orchestration as the only solution to tool overload. Progressive disclosure and discovery reduce schema pressure without introducing another autonomous decision boundary, while orchestration is useful when the task itself genuinely requires decomposition.

So I would use:

progressive disclosure for tool selection

delegation for pre-authorized bounded authority

pause/resume for new consequential authority

Those solve three different problems and compose cleanly.