Skip to main content
Glama

Score a planned spend before an agent pays

score_spend
Read-onlyIdempotent

Score one planned payment and return approve, ask_human, or block before any tool sends money. Use before a crypto transfer, gift card, subscription, or paid API call. Do not use it for uptime (check_mcp_server_health, check_api_status), to judge whether a host or wallet is trusted (check_merchant), or to read remaining free scores (get_quota). Does not transfer funds. Returns score 0-100, verdict (approve means pay, ask_human means stop and ask a person, block means do not pay), reasons, and recommended_action. Scoring is deterministic, so rewording purpose will not change the verdict. amount is USD, not token units. api_key, when set, is a SpendGate sg_live_ key, not a Toolweather tw_ key from get_api_key. Uses SpendGate's quota (100/day anonymous, 1,000/day with an sg_live_ key), then $0.001 via x402, not the Toolweather check quota.

Input Schema

NameRequiredDescriptionDefault
amountYesPlanned spend in USD, not in token atomic units. Compared with daily_budget_remaining and monthly_budget_remaining when those are set.
api_keyNoOptional SpendGate key (sg_live_…). Not a Toolweather tw_ key; that key belongs in the X-API-Key header. Omit to use the anonymous IP/session cap, which can reset on rotating egress.
purposeNoShort human description. Used as the category when category is omitted. Rewording it does not change a v1 verdict.
agent_idNoYour agent or key id. Echoed back, not scored in v1.
categoryNoOne of status_check, api_call, saas, infra, gift_card, crypto_transfer, irreversible. Unknown categories are scored as unknown risk, not rejected.
currencyNoPayment currency. Defaults to USDC. Does not convert amount; amount stays in USD.
endpointNoAlias of merchant when the payee is an API URL. Pass one of them, not both for different payees.
merchantNoMerchant name or https endpoint URL that would receive the spend. The call does not pay this URL.
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.
daily_budget_remainingNoUSD still available today. Amount above this is blocked. Omit if you have no daily cap to enforce.
monthly_budget_remainingNoUSD still available this month. Amount above this is blocked. Omit if you have no monthly cap.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • changedInput schema / properties / agent_id / description
      Previous value: -"Your agent or key id. Echoed, not scored in v1."New value: +"Your agent or key id. Echoed back, 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 in token atomic units. Compared with daily_budget_remaining and monthly_budget_remaining when those are set."
    • changedInput schema / properties / api_key / description
      Previous value: -"Optional SpendGate key (sg_live_…). Not a Toolweather key. For a stable daily cap pass an sg_live_ key, or call get_api_key first for a Toolweather key. Anonymous callers share a smaller IP/session cap that can reset on rotating egress."New value: +"Optional SpendGate key (sg_live_…). Not a Toolweather tw_ key; that key belongs in the X-API-Key header. Omit to use the anonymous IP/session cap, which can reset on rotating egress."
    • 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: +"One of status_check, api_call, saas, infra, gift_card, crypto_transfer, irreversible. Unknown categories are scored as unknown risk, not rejected."
    • changedInput schema / properties / currency / description
      Previous value: -"Payment currency. Defaults to USDC."New value: +"Payment currency. Defaults to USDC. Does not convert amount; amount stays in USD."
    • changedInput schema / properties / daily_budget_remaining / description
      Previous value: -"USD still available today. Amount above this is blocked."New value: +"USD still available today. Amount above this is blocked. Omit if you have no daily cap to enforce."
    • changedInput schema / properties / endpoint / description
      Previous value: -"Alias of merchant when the payee is an API URL."New value: +"Alias of merchant when the payee is an API URL. Pass one of them, not both for different payees."
    • changedInput schema / properties / merchant / description
      Previous value: -"Merchant name or https endpoint URL that will receive the spend."New value: +"Merchant name or https endpoint URL that would receive the spend. The call does not pay this URL."
    • changedInput schema / properties / monthly_budget_remaining / description
      Previous value: -"USD still available this month. Amount above this is blocked."New value: +"USD still available this month. Amount above this is blocked. Omit if you have no monthly cap."
    • changedInput schema / properties / purpose / description
      Previous value: -"Short human description. Used as the category when category is omitted."New value: +"Short human description. Used as the category when category is omitted. Rewording it does not change a v1 verdict."
  2. Changed1 schema field changed
    • changedInput schema / properties / api_key / description
      Previous value: -"Optional SpendGate key (sg_live_…). Not a Toolweather key. Anonymous callers share a smaller daily cap."New value: +"Optional SpendGate key (sg_live_…). Not a Toolweather key. For a stable daily cap pass an sg_live_ key, or call get_api_key first for a Toolweather key. Anonymous callers share a smaller IP/session cap that can reset on rotating egress."
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses that the tool does not transfer funds, that scoring is deterministic (rewording won't change a v1 verdict), the exact return fields, and the quota/pricing model (100/day anonymous, 1,000/day with an sg_live_ key, then $0.001 via x402). That is rich behavioral context 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.

Conciseness4/5

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

Well front-loaded with the action and routing before less critical detail, and every sentence carries information. There is some overlap between description and per-parameter docs (the sg_live_ vs tw_ distinction appears twice), which costs a point on conciseness for a long definition.

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 an 11-parameter scoring tool with no output schema, the description supplies the return values (score, verdict, reasons, recommended_action) and disambiguates key params and quota behavior. Nothing an agent needs to call 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: amount is USD not token units, api_key is an sg_live_ key not a tw_ key, and purpose is used as the category when category is omitted. These clarify cross-parameter relationships rather than restating the schema.

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+resource ('Score one planned payment') and the exact return contract (approve, ask_human, block) before any tool sends money. It explicitly distinguishes itself from siblings by naming what it is not (check_mcp_server_health, check_api_status, check_merchant, get_quota).

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?

Gives explicit when-to-use ('Use before a crypto transfer, gift card, subscription, or paid API call') and when-not-to-use with the alternative for each case (uptime → health tools, trust → check_merchant, remaining quota → get_quota). No routing decision is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources