MoneyTools Settle

Pre-payment spend check

spend_check

0.002 USDC per call via x402, no key (unpaid call returns PaymentRequired; retry with params.meta["x402/payment"]). Advisory pre-sign check (your wallet's own hard limits still apply; we cannot block a payment): 'would this payment exceed my cap?'. Pass the 402 PAYMENT-REQUIRED (header or body) or amountUsd, plus payer and optional sessionId/host. Returns allow|deny with reasons and remaining budget; reserve:true also logs it as pending. 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_check"
  }
}

Input Schema

Name	Required	Description
`ref`	No	Your order / request id (idempotency key).
`host`	No	Seller hostname, e.g. api.example.com.
`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.
`network`	No	CAIP-2 network, default eip155:8453 (Base).
`reserve`	No	true = log this payment as pending if allowed.
`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.1/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the full payment flow (402 response, retry via params._meta['x402/payment']), that it is advisory only and cannot block payments, that reserve:true creates a pending log, and the auth requirement (mts_ key or trial key). These are exactly the behavioral traits an agent needs and are not contradicted by the annotations (readOnlyHint:false is consistent with reserve logging).

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

Conciseness3/5

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

The definition is dense and run-on, with multiple parentheticals and the purpose appearing after pricing and payment mechanics. Every sentence carries information, but the ordering and packing make it harder to scan than necessary.

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?

With 10 parameters and no output schema, the description supplies the important missing context: return values (allow|deny with reasons and remaining budget), the auth path, and the reserve side effect. It is nearly complete, though a clearer statement of parameter requirements (e.g., that either paymentRequired or amountUsd is needed) would close the remaining gap.

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 meaningful semantics: paymentRequired can be the header (base64) or the JSON body, and amountUsd is an alternative input path, with payer/sessionId/host framing the request. It also explains the effect of reserve:true. This goes modestly beyond what the schema alone conveys.

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?

The description states a specific function: an advisory pre-sign check answering 'would this payment exceed my cap?', and it clarifies it cannot block a payment. This distinguishes it from the sibling cap-management tools, though it does not name an alternative explicitly. The purpose is buried after pricing text rather than front-loaded.

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?

It gives clear invocation guidance: pass the 402 PAYMENT-REQUIRED header/body or amountUsd, plus payer and optional sessionId/host, and reserve:true to log as pending. It also routes keyless callers to settle_trial_key. It lacks explicit when-not-to-use guidance or a direct comparison to spend_cap_get.

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?