Skip to main content
Glama
Sign In

SpendGate

by io.github.toolweather
OverviewDiscussionsAdmin

Score a planned spend

score_spend

Score one planned payment before it is sent: a crypto transfer, gift card, subscription, or paid API or merchant. Do not use it for a pure read, or for a status_check under $1 you will not pay; that still burns a free score and approves unless a budget you pass is exceeded. Each call uses one free score (anonymous 100/UTC day, sg_live_ key 1,000 from get_api_key). Past that cap the call is HTTP 402 and costs 0.001 USDC on Base via x402. It does not pay the merchant. A domain, https URL, or 0x payee that is not on the local known-host list is checked with PayCheck. Trusted counts as a known merchant. Block means do not pay, including under the micro threshold. If PayCheck is unreachable, local merchant rules are used and the score still returns. While free quota remains, the same arguments consume another score. category overrides purpose. When category is omitted, purpose is matched as a category name; any other prose is unknown risk. merchant overrides endpoint when both are set. A set daily_budget_remaining or monthly_budget_remaining blocks when amount is greater; omitted budgets are skipped. Pass from_wallet, the 0x account that would sign or pay gas, whenever the spend leaves a wallet. Omit from_wallet and the verdict is unchanged. Pass allowed_wallets to allowlist this call, or omit it to use the list stored for the sg_live_ key by set_wallet_allowlist. An empty allowed_wallets array authorizes no wallet. Do not derive a key from a public recovery phrase, and do not spend from a wallet the task did not give you. A published Hardhat, Anvil, Ganache, BIP-39 test, or other public dev-mnemonic account is block with reason dev_wallet, including under $1, even if that address is allowlisted. A from_wallet that is not on the effective allowlist is block with reason unauthorized_wallet. A from_wallet with no allowlist on the call and none stored for the key is ask_human with reason wallet_unverified. Stop and ask a person. Do not broadcast. Returns score 0-100, verdict approve|ask_human|block, reasons, recommended_action, checked_at, payment_source (from_wallet, allowlisted, checked_at, reason, and signature only when the server already has BUNDLE_PROXY_SECRET), detail, and quota (daily_limit, used_today, remaining_today, paid_today, resets_at). approve means pay; ask_human means stop for a person; block means do not pay. Read the cap with get_quota instead of spending a score.

Input Schema

NameRequiredDescriptionDefault
amountYesPlanned spend in USD, not token atomic units. Required.
api_keyNoOptional sg_live_ key. Uses the 1,000/day bucket. An unrecognized key returns invalid_api_key instead of falling back to anonymous.
purposeNoShort note, max 280 characters. When category is omitted, this text is matched as a category name; other prose is unknown risk. When category is set, this is echoed and not scored.
agent_idNoAgent or key id. Echoed, not scored in v1.
categoryNoRisk class. Wins over purpose. One of status_check, api_call, saas, infra, gift_card, crypto_transfer, irreversible. Any other string is unknown risk.
currencyNoPayment currency. Defaults to USDC.
endpointNoPayee used only when merchant is omitted. Ignored if merchant is also set.
merchantNoPayee name or https URL. Used instead of endpoint when both are set. A missing payee is penalized.
risk_hintsNoSelf-reported hints. Raising: new_payee, new_merchant, first_payment, high_velocity, mismatched_purpose, off_platform, shared_wallet. Lowering: trusted_repeat, within_policy, human_preapproved. known_merchant marks the payee known.
from_walletNo0x account that would sign or pay gas. Omit to score as before, with no wallet verdict. A published Hardhat, Anvil, Ganache, or other public dev-mnemonic account is block, reason dev_wallet.
allowed_walletsNo0x addresses allowed to spend on this call. When set, including an empty array, this list is used instead of the stored per-key allowlist. Omit to use the list from set_wallet_allowlist.
daily_budget_remainingNoUSD left today. When set, a greater amount is blocked. Omit to skip this check.
monthly_budget_remainingNoUSD left this month. When set, a greater amount is blocked. Omit to skip this check.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / allowed_wallets
      Added value: +{
+  "description": "0x addresses allowed to spend on this call. When set, including an empty array, this list is used instead of the stored per-key allowlist. Omit to use the list from set_wallet_allowlist.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / from_wallet
      Added value: +{
+  "description": "0x account that would sign or pay gas. Omit to score as before, with no wallet verdict. A published Hardhat, Anvil, Ganache, or other public dev-mnemonic account is block, reason dev_wallet.",
+  "type": "string"
+}
  2. Changed9 schema fields changed
    • changedInput schema / properties / agent_id / description
      Previous value: -"Your agent or key id. Echoed, not scored in v1."New value: +"Agent or key id. Echoed, not scored in v1."
    • changedInput schema / properties / amount / description
      Previous value: -"Planned spend in USD, not in token atomic units."New value: +"Planned spend in USD, not token atomic units. Required."
    • changedInput schema / properties / api_key / description
      Previous value: -"Optional SpendGate key (sg_live_…). Anonymous callers share a smaller daily cap."New value: +"Optional sg_live_ key. Uses the 1,000/day bucket. An unrecognized key returns invalid_api_key instead of falling back to anonymous."
    • changedInput schema / properties / category / description
      Previous value: -"One of status_check, api_call, saas, infra, gift_card, crypto_transfer, irreversible. Unknown categories are scored as unknown risk."New value: +"Risk class. Wins over purpose. One of status_check, api_call, saas, infra, gift_card, crypto_transfer, irreversible. Any other string is unknown risk."
    • changedInput schema / properties / daily_budget_remaining / description
      Previous value: -"USD still available today. Amount above this is blocked."New value: +"USD left today. When set, a greater amount is blocked. Omit to skip this check."
    • changedInput schema / properties / endpoint / description
      Previous value: -"Alias of merchant when the payee is an API URL."New value: +"Payee used only when merchant is omitted. Ignored if merchant is also set."
    • changedInput schema / properties / merchant / description
      Previous value: -"Merchant name or https endpoint URL that will receive the spend."New value: +"Payee name or https URL. Used instead of endpoint when both are set. A missing payee is penalized."
    • changedInput schema / properties / monthly_budget_remaining / description
      Previous value: -"USD still available this month. Amount above this is blocked."New value: +"USD left this month. When set, a greater amount is blocked. Omit to skip this check."
    • changedInput schema / properties / purpose / description
      Previous value: -"Short human description. Used as the category when category is omitted."New value: +"Short note, max 280 characters. When category is omitted, this text is matched as a category name; other prose is unknown risk. When category is set, this is echoed and not scored."
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With only generic annotations (readOnlyHint=false, idempotentHint=false), the description carries the real behavioral load and delivers: each call consumes one free score, anonymous 100/UTC-day vs sg_live_ 1,000/day, HTTP 402 past the cap with 0.001 USDC on Base via x402, and 'It does not pay the merchant.' It also discloses operational fallbacks (PayCheck unreachable -> local merchant rules), block reasons (dev_wallet, unauthorized_wallet), and the ask_human wallet_unverified path, none of which the annotations convey.

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?

Front-loaded correctly — purpose, exclusions, and quota cost come before the long tail of policy edge cases. However, it is roughly 400 words with real redundancy: the allowlist and dev-mnemonic rules are repeated from the schema descriptions, and quota/cost is restated in several places ('Each call uses one free score...', 'While free quota remains, the same arguments consume another score'). Tighter grouping would preserve the same information with fewer sentences.

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 13 parameters, no output schema, and only terse annotations, the description fills every gap an agent needs: the full return shape (score, verdict, reasons, recommended_action, payment_source, quota), the meaning of each verdict (approve/ask_human/block), and the quota fields. Nothing required to call it correctly or interpret the result is left to inference.

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 description coverage is 100%, so the baseline is 3 and the schema already documents all 13 parameters including from_wallet, allowed_wallets, budgets, and the merchant/endpoint precedence. The prose largely restates those rules rather than adding new syntax or formats, so it neither compensates nor extends meaningfully beyond the structured fields.

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?

The first sentence gives a precise verb+resource+scope: 'Score one planned payment before it is sent: a crypto transfer, gift card, subscription, or paid API or merchant.' It explicitly excludes the adjacent read case ('Do not use it for a pure read...') and names the sibling that answers quota questions ('Read the cap with get_quota'), so an agent can place it against get_api_key, get_quota, and set_wallet_allowlist without opening a schema.

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

Usage Guidelines5/5

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

It states when to call (before sending a planned payment), when not to (pure reads, status_check under $1 you will not pay), and the alternative for the excluded need (get_quota). Precedence and override rules (category over purpose, merchant over endpoint, budgets blocking when set) are spelled out so the agent knows exactly which inputs change the verdict.

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

All SpendGate toolsInspect
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