MCP Tool Approvals, Explained: From Pending Call to Bounded Human Decision

A human-in-the-loop gate is useful only when the system preserves what was proposed, what was approved, how long the grant lasts, and what actually executed.

Approval is a state transition, not a modal dialog

Human approval is often drawn as a diamond between an agent and a tool. That picture omits the hard parts. What exact operation is waiting? Which human is authorized to decide? Does approval cover one call or a period of future calls? What happens if the arguments or business state change? How does the caller distinguish “pending” from a successful tool result?

A production approval mechanism must preserve a proposal, suspend execution before the side effect, create a decision record, define the scope and lifetime of the resulting grant, and expose enough state for the agent or application to continue safely. It must also remain separate from authorization: a human can approve a risk decision, but the downstream system still decides whether the authenticated actor may perform the action.

The tool sits beyond the execution gate, so neither a pending request nor a reviewer notification can be mistaken for a side effect. Expiry and denial return the system to a non-executing state rather than granting implicit future access.

How TrueFoundry MCP approval policies work

TrueFoundry documents approval policies for MCP tool calls routed through MCP Gateway. A policy matches a server and tool scope. When a gated tools/call arrives, the gateway creates or reuses a pending request for the same tool and requester, does not execute the tool, and notifies designated approvers. The caller receives a JSON-RPC result whose metadata indicates that approval is pending.

An approver can allow or deny the request and optionally provide a reason. Once allowed, calls from that requester to that server and tool can execute within the configured validity. The tool result includes approval metadata. When the grant expires, the next call creates a fresh request. A denial is recorded for that request but is not a permanent access revocation; a later call can raise another approval request.

This last behavior is easy to misread. Approval policy decides whether a normally accessible tool needs human assent at a moment in time. Durable denial belongs in access control: remove the requester’s access or disable the tool. Using repeated denial as an informal authorization policy burdens reviewers and creates noisy evidence.

Scope and validity are different dimensions

A policy can target named tools, tools marked destructive by the MCP server, or all tools on a server. When scopes overlap, the documented precedence favors the more specific match: named before destructive before all. Validity can be count-based for one execution or time-based for a configured number of minutes. When multiple policies apply, the most restrictive validity wins.

The resulting grant is scoped to the requester plus the specific MCP server and tool. It is not shared across users. The pending-request view includes the tool arguments, which gives reviewers useful context. However, the public documentation does not say that the grant cryptographically binds a digest of material arguments or business-state version. High-impact applications should add that binding themselves.

For example, approval of a refund tool is not necessarily approval of every refund amount, order, destination, or reason that could be passed during a time window. If those fields change the risk decision, the application should bind the reviewer’s decision to them and require a fresh decision after a material change.

The linked chain separates the documented gateway grant—requester, server, tool, and validity—from recommended application binding. Amount, recipient, resource version, and operation identity require separate enforcement when they materially change the risk decision.

Design an approval envelope

Pending is not failure—and not success

While approval is pending, MCP Gateway returns a successful JSON-RPC envelope with textual content instructing the caller to wait, isError set false, and approval metadata set to pending. That transport-level success means the gateway handled the request. It does not mean the tool ran.

Clients must inspect approval metadata and represent pending as a distinct state. If they only look for transport errors, they may tell the model that the tool succeeded or feed the waiting message back as ordinary tool output. Repeated calls from the same requester to the same tool reuse the pending request, which reduces notification spam, but callers should still back off and wait for a decision rather than spin.

After approval, the result passes through with approved metadata. The application should correlate that result with the original proposal and downstream operation. Approval evidence answers “was this human decision recorded under this gateway policy?” The system of record answers “what effect committed?”

Gateway approvals and TrueForge checkpoints are related, not identical

TrueForge also supports agent-turn pauses for tools configured to require approval. A paused turn emits an approval-required event and completes with required actions. The client locates the originating tool call, collects the reviewer’s decision, and creates a new turn with an allow or deny response.

That is an orchestration checkpoint inside the TrueForge session. MCP Gateway approval is a gateway policy applied to routed MCP calls, independent of which compatible client made them. An organization can use either or both. If both gate the same operation, define the intended order and user experience so reviewers do not approve the same risk twice without added value.

A common pattern is to use TrueForge checkpoints for task-specific interaction—the agent needs confirmation for this proposed action—and MCP Gateway approval for shared policy around a sensitive tool. The application still performs business authorization and state validation immediately before mutation.

The sequence preserves four claims: the harness records the task checkpoint, the gateway records the approval grant, the application authorizes current business state, and the authoritative system records what committed.

A worked example: production database change

An agent proposes a migration using a tool marked destructive. The gateway policy matches the destructive scope and creates a pending request. The reviewer sees the tool, requester, arguments, policy, and requested validity. They allow one execution.

Before the database service runs the migration, it verifies the authenticated subject and agent are authorized for the target environment, checks that the migration digest matches the reviewed proposal, confirms the schema version has not changed, and records an operation ID. If any material input differs, the action returns to review. If execution times out, the service queries the migration record before retry.

The gateway’s count-based validity prevents the grant from becoming standing permission. The argument digest and state check prevent a valid grant from authorizing a different operation. The database remains authoritative for whether the migration committed. Each layer makes a narrow claim and leaves evidence for the next.

Review ergonomics are part of safety

A technically correct gate can still fail if reviewers lack context or receive too many low-value requests. The review surface should emphasize the fields that change risk: actor, target, action, diff, amount, destination, data classification, current state, reversibility, and expected outcome. Generated prose can summarize, but the material fields should come from typed records.

Route requests to approvers who understand the resource, not a generic queue. Set timeouts and escalation paths. Measure approval latency, denial rate, abandonment, repeated requests, post-approval failures, and reversals. A falling denial rate may indicate better proposals—or rubber-stamping—so combine workflow metrics with sampled decision quality.

Failure tests for approval systems

• Change a material argument after approval and verify the application demands reauthorization or a new approval.
• Attempt to consume another requester’s grant.
• Apply named, destructive, and all-tool policies simultaneously; verify specificity and restrictive validity.
• Deny a request, call again, and verify the new pending request is understood rather than treated as permanent denial.
• Remove tool access while a request is pending; verify approval cannot restore revoked authorization.
• Return a pending JSON-RPC result to several clients; verify none interprets transport success as tool execution.
• Timeout after downstream commit; verify operation reconciliation prevents a duplicate.

Define grant consumption and escalation

A count-based “Once” grant sounds simple, but a production system still needs to define what consumes it. The safest interpretation is one identified execution of the approved operation, not the next syntactically valid call that happens to reach the same tool. Concurrent callers, automatic retries, and parallel agent threads can otherwise race to use the grant.

Time-based grants need guard conditions beyond a clock. If the requester loses access, the tool is disabled, the policy changes, the target crosses a risk threshold, or the resource state changes materially, the application should treat the prior decision as stale even when the gateway validity window remains open. Gateway access and business authorization should be re-evaluated at execution time.

Escalation should also be explicit. A request that receives no decision by its deadline may expire, route to an alternate qualified reviewer, or leave the task paused. It should not default to approval because the agent is waiting. Emergency paths should use narrower capabilities, shorter validity, stronger evidence, and retrospective review rather than bypassing the decision record entirely.

Finally, separate policy tuning from reviewer performance. High approval volume may indicate that a tool is too broad, a threshold is too low, or the workflow is delegating the wrong decisions. The durable fix can be a safer tool contract or better authorization—not simply adding more reviewers.

Record which rule created the request and which rule permitted execution. Without both versions, investigators cannot tell whether the human decision, the policy configuration, or later application state explains the outcome.

The operational rule

Human-in-the-loop should mean more than “a person clicked approve.” A defensible mechanism identifies the pending operation, reviewer, decision, policy, scope, validity, execution attempt, and committed effect. It also makes clear which parts the platform enforces and which remain application-owned.

TrueFoundry MCP Gateway provides a shared approval surface for routed tools, while TrueForge can pause and continue an agent workflow around a specific proposal. Together they can make decisions inspectable. They do not turn approval into business authorization or exactly-once execution—and saying that plainly makes the architecture stronger.

References

1. TrueFoundry — MCP Tool Approvals.
2. TrueFoundry — MCP Gateway Overview.
3. TrueForge — Use an Agent.
4. TrueForge — SDK Concepts.

Editorial disclosure. This article reflects TrueFoundry’s engineering interpretation of the cited public materials as of September 17, 2026. Product capabilities are scoped to linked documentation. Examples and operating defaults are illustrative; they are not legal advice, an audit opinion, an independent benchmark, or a guarantee of security, safety, or compliance.

‍