MoneyTools Approval Relay

Request human approval

request_approval

Create a human approval request for an irreversible action. Returns approve_url (pass it to the responsible human through your own channel) and approval_id. Optional wait_seconds keeps the call open (progress notifications every 10 s when the client sends a progressToken) until the human decides. 3 free per day, then 0.005 USDC via x402 (params._meta["x402/payment"]).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action_summary": "<action_summary>"
    },
    "name": "request_approval"
  }
}

Input Schema

Name	Required	Description
`risk`	No	Risk level shown to the approver (default med)
`requester`	No	Optional label shown to the approver, e.g. agent or job name
`callback_url`	No	Optional public https URL that receives a POST with the signed receipt when decided
`expires_in_s`	No	Seconds until the request expires unanswered (default 3600)
`wait_seconds`	No	Optional: wait up to this many seconds for the decision before returning (0 = return immediately; >25 needs an SSE-capable client)
`action_summary`	Yes	Plain-language description of the irreversible action awaiting approval

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing return fields, the requirement to deliver approve_url through the caller's own channel, progress-notification cadence every 10 s when a progressToken is sent, and the quota/pricing model (3 free per day, then 0.005 USDC via x402 in params._meta). The 'irreversible action' phrasing describes the action being approved, not the tool itself, so it does not conflict with destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with purpose then returns then behavior/cost. No filler; each clause carries operational information an agent needs before calling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still names the returned fields, explains delivery responsibility, wait semantics, and pricing. Nothing essential for correct invocation is missing for a 6-parameter tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains wait_seconds' progress-notification behavior and documents the x402 payment channel that does not appear in the input schema at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a human approval request') plus the scope ('for an irreversible action'), and names the return artifacts (approve_url, approval_id). The create verb distinguishes it from the get_approval and verify_receipt siblings without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for an irreversible action' gives a clear usage trigger, and the description explains the two modes of use: fire-and-forget (deliver approve_url yourself) versus blocking (wait_seconds). It doesn't explicitly state when to use get_approval instead for later polling, so it stops short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All MoneyTools Approval Relay tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?