The Human Gate: Designing MCP Tool Approvals at the Gateway Boundary

MCP gives clients and servers a standard way to discover and invoke tools. It deliberately does not standardize one approval UI or one human-in-the-loop workflow. The 2026-07-28 Tools specification says implementations are free to choose their interaction model, while recommending that applications keep a human able to deny tool invocations. TrueFoundry's MCP Tool Approvals sit in that implementation space: the Gateway can hold a matched tools/call, create an approval request, notify an approver, and return a successful result carrying TrueFoundry-specific approval metadata so a compatible caller can distinguish waiting for approval from tool execution failed. The engineering value is not that MCP standardized approval—it did not—but that approval can be enforced at a shared tool boundary, scoped to identity and tool, and correlated with the execution path without turning a transient human decision into permanent authorization policy.

‍

1. Start at the Protocol Boundary

The most important distinction is between what MCP standardizes and what the Gateway implements. MCP standardizes tool discovery, invocation, schemas, results, and—in the 2026-07-28 revision—richer ways for a tool workflow to require additional input. The specification's user-interaction guidance is intentionally looser: applications should make tool exposure and invocation visible and should give a human the ability to deny operations, but the protocol does not mandate a particular confirmation interface or approval lifecycle. That leaves room for a gateway to impose organization-wide policy without pretending that its policy object is part of MCP itself.

TrueFoundry's documented flow can be read as six steps. A tools/call reaches the MCP Gateway and matches an approval policy; the Gateway holds the call instead of invoking the downstream tool; it creates or reuses the pending approval request and notifies the configured approver path; the caller receives a successful result whose _meta.approval_status communicates that execution is pending; a human approves or denies; and, on approval, the Gateway releases execution according to the configured validity. Repeated calls for the same pending requester/tool context can reuse the pending request rather than generating a new approval notification each time.

The pause is an implementation-level state, not a protocol error. That is a good client contract because an orchestrator that understands the metadata can branch on “waiting for approval” instead of treating the tool as unavailable. But the burden is explicit: clients that do not understand the TrueFoundry metadata are not guaranteed to wait correctly. The 2026-07-28 MCP specification also defines input_required results for multi round-trip requests and moves long-running Tasks into an extension; those are standardized MCP mechanisms with different wire semantics. The approval gate should therefore be described as compatible with an increasingly interruptible MCP world, not as an MCP Task inserted by the Gateway.

The audit linkage is correlation, not magic. The documented result metadata gives the execution path an approval status and request identifier that can be used to correlate the call with the approval workflow. Do not infer that every tool-result payload itself contains the approver identity, decision timestamp, reason, or validity window unless those fields are separately present in the approval record or trace. “Correlatable to an approval decision” is the defensible property; “self-contained compliance record” is not.

2. The Security Semantics Are in the Scope

The approval feature is easiest to reason about when it is treated as a narrow authorization checkpoint rather than as a universal safety layer. Four properties matter.

First, validity changes the meaning of “approved.” With one-execution validity, approval is tied to the pending execution. With a time-based grant, the human decision creates temporary authority for later invocations of the same requester + MCP server + tool tuple until the window expires. That is useful when repeated confirmation would add no judgment, but it also means later argument sets may execute without a fresh human review. The more argument-sensitive or irreversible the action, the stronger the case for one-execution approval or for an additional argument-level policy.

Second, requester scoping prevents approval transfer. An approval granted to one identity should not silently authorize another identity merely because both agents reach the same server and tool. That makes the resolved requester identity part of the security boundary, not just an audit label.

Third, denial is intentionally ephemeral. A denial answers “not now” for the pending request. If an identity should never call the tool, the durable answer belongs in server access, tool exposure, or another standing policy layer. Keeping those concepts separate prevents a queue of one-off approval decisions from becoming an accidental authorization database.

Fourth, policy precedence needs precise language. Matching scope and grant lifetime are different questions. More-specific approval configuration determines which tool policy applies, while validity should resolve toward the more restrictive lifetime when applicable. Do not compress both ideas into the slogan “most restrictive policy wins” without saying which dimension is being resolved.

‍