MoneyTools Settle

Set agent spend caps

spend_cap_set

Idempotent

0.002 USDC per call via x402, no key (unpaid call returns PaymentRequired; retry with params.meta["x402/payment"]). Advisory spend caps that complement your wallet's enforced hard limits (Coinbase Agentic Wallet / CDP spendControls); cannot block payments. Set per-call / per-day (rolling 24h) / per-session USD limits and optional allow-lists (payTo, hosts, networks) for a payer wallet address (replaces the previous policy for that payer). Optional ownerLock secret so the agent cannot loosen the caps later. Advisory and non-custodial. 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_cap_set"
  }
}

Input Schema

Name	Required	Description
`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.
`ownerLock`	No	Owner secret (>=12 chars); once set, caps can only be loosened with it.
`perDayUsd`	No	Max USD per rolling 24h.
`allowHosts`	No	Allowed seller hostnames.
`allowPayTo`	No	Allowed seller payTo addresses.
`perCallUsd`	No	Max USD per single payment, e.g. "0.10".
`allowNetworks`	No	Allowed CAIP-2 networks.
`perSessionUsd`	No	Max USD per sessionId.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Goes well beyond the annotations by disclosing payment mechanics (x402, PaymentRequired retry, 0.002 USDC), auth requirements (mts_ key), the advisory/non-custodial limitation, and ownerLock irreversibility. However, it does not state what the response contains or confirm that fields omitted from a call are dropped when the prior policy is replaced, which matters for an idempotent overwrite operation.

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 purpose is buried mid-paragraph after payment and pricing boilerplate, and the trailing plan pricing plus trial-key upsell is marketing rather than invocation guidance. Each sentence carries information, but the ordering is backwards for an agent that needs to know what the tool does first.

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?

For a 9-parameter mutation tool with no output schema, the description covers auth, cost, retry path, the advisory limitation, overwrite semantics, and the ownerLock escape hatch. Nothing an agent needs to invoke it correctly is missing.

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: setting caps replaces the entire previous policy for that payer, caps are advisory only, and ownerLock is the sole way to loosen them later. The per-day rolling-window and per-session tie-ins are also restated, so an agent understands the parameters' policy-level effect, not just their types.

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: sets per-call / per-day (rolling 24h) / per-session USD limits plus optional allow-lists for a payer wallet, and notes it replaces the previous policy for that payer. That is detailed enough to distinguish it from spend_cap_get (read) and spend_check (evaluate) without opening any schema.

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 context for when this applies: advisory caps that complement the wallet's enforced hard limits, and it explicitly says it cannot block payments, so an agent knows not to rely on it for enforcement. It does not name a read/update alternative, but the advisory-vs-enforced framing is genuine selection guidance.

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?