MoneyTools Settle

Record x402 payment

spend_record

Idempotent

0.002 USDC per call via x402, no key (unpaid call returns PaymentRequired; retry with params.meta["x402/payment"]). Record an x402 payment the agent made (or update a reserved one by spendId/ref): status settled|failed|pending|refunded, tx; verify:true checks a Base tx on-chain (read-only). Builds the spend log / receipts. 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": "spend_record"
  }
}

Input Schema

Name	Required	Description
`tx`	No	Settlement tx hash on Base, 0x + 64 hex.
`ref`	No	Your order / request id (idempotency key).
`host`	No	Seller hostname, e.g. api.example.com.
`note`	No	Free-text note (max 200 chars).
`payTo`	No	Seller receiving address 0x….
`payer`	No	Payer / agent wallet address 0x… (40 hex).
`apiKey`	No	Your MoneyTools Settle key mts_… (alternative to the X-API-Key header). No key: call settle_trial_key.
`status`	No	New status (see tool description).
`verify`	No	true = verify tx on Base (read-only).
`network`	No	CAIP-2 network, default eip155:8453 (Base).
`spendId`	No	Spend id sp_… from spend_check reserve.
`amountUsd`	No	USD amount as decimal string, e.g. "0.25".
`sessionId`	No	Your session / run id.
`paymentRequired`	No	The 402 PAYMENT-REQUIRED header (base64) or the 402 JSON body.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only flag it as a non-read-only, idempotent, open-world write; the description adds substantial context beyond that: the 0.002 USDC per-call x402 charge, the PaymentRequired retry flow via params._meta['x402/payment'], the mts_ key requirement with header/argument alternatives, the free trial fallback, and that verify:true is a read-only on-chain Base check. That is exactly the extra behavioral disclosure the annotations cannot carry.

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?

Dense but front-loaded: price and payment mechanics come first, then the core action, then auth, then fallback. Every clause carries information an agent needs, and parentheticals are used for the retry and read-only details rather than padding.

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

Completeness4/5

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

For a 14-parameter write tool with no output schema, the description covers cost, auth, retry, verification semantics and a fallback path. The only real gap is what the tool returns (a spend/receipt identifier or log entry), which is hinted at but never stated.

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 earns above that by supplying the actual status enum (settled|failed|pending|refunded) that the schema explicitly defers to it ('see tool description'), and by clarifying spendId/ref as the reserved-spend and idempotency identifiers.

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: 'Record an x402 payment the agent made', plus the update variant keyed by spendId/ref. It implicitly distinguishes itself from spend_log and receipt_create by saying it 'Builds the spend log / receipts', though that overlap is not spelled out as an explicit boundary.

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 clear conditions: record a payment you made, or update a reserved spend by spendId/ref, and routes keyless callers to settle_trial_key. It does not say when to prefer receipt_create or spend_check instead, so sibling disambiguation is partial.

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?