MoneyTools Settle

Watch timed-out settlement

settle_watch

Watch a timed-out/unknown x402 settlement: re-checked on-chain for up to 24h; POSTs your webhook when it becomes settled/failed/expired. Needs a key mts_ (X-API-Key header or apiKey argument). No key? call settle_trial_key (free, 50 calls/7 days). Full plan 1 USDC/30d incl. 1,000 calls via x402.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "settle_watch"
  }
}

Input Schema

Name	Required	Description
`tx`	No	Settlement tx hash on Base, 0x + 64 hex.
`nonce`	No	EIP-3009 authorization nonce, 0x + 64 hex.
`payTo`	No	Seller receiving address 0x….
`payer`	No	Payer / agent wallet address 0x… (40 hex).
`amount`	No	Expected amount in USDC atomic units (6 decimals), e.g. "10000" = 0.01 USDC.
`apiKey`	No	Your MoneyTools Settle key mts_… (alternative to the X-API-Key header). No key: call settle_trial_key.
`webhook`	No	Public https URL we POST to when the status resolves.
`validBefore`	No	Authorization validBefore (unix seconds).
`paymentPayload`	No	The x402 PAYMENT-SIGNATURE / X-PAYMENT payload (base64 JSON or object).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the 24h re-check window, the webhook POST on resolution, the terminal states (settled/failed/expired), and the auth/pricing model. Annotations already cover the safety profile (readOnlyHint=false, openWorldHint=true) and the description is consistent with them. Minor gaps remain: no polling cadence and no description of the webhook payload.

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

Conciseness4/5

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

Front-loaded with the core action and lifecycle, then auth, then pricing fallback — a sensible order. Four short clauses with little waste; the pricing sentence is slightly promotional but does help the agent decide whether it can call the tool at all.

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

Completeness3/5

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

Covers the lifecycle, auth, and terminal outcomes for a fairly complex async tool with 9 parameters and no output schema. It omits what the call returns (e.g., a watch identifier) and does not point to settle_watch_status for later polling, leaving the agent without the follow-up path after registering a watch.

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

Parameters3/5

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

Schema coverage is 100% and every parameter already carries a precise description (tx format, amount in atomic units, apiKey alternative to the header), so baseline 3 applies. The description adds only the auth note ('mts_ key, X-API-Key header or apiKey argument') and does not clarify which of the 9 optional parameters must be combined to establish a watch, which is the real ambiguity in the schema.

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

Purpose4/5

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

States a specific verb and resource plus its scope: watching a *timed-out/unknown* x402 settlement and re-checking on-chain. That scope constraint tells an agent this is for unresolved settlements rather than fresh verification. It does not explicitly separate itself from behaviorally adjacent siblings such as settle_verify or settle_watch_status, so it falls short of a 5.

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?

Gives a clear trigger condition (settlement timed out or unknown) and an explicit alternative for the no-key case: call settle_trial_key. However, it offers no guidance on when to use this versus settle_verify or settle_watch_status, and no exclusions, so the agent must infer those boundaries.

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

All MoneyTools Settle 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?