Skip to main content
Glama

Audit budget controls

audit_budget
Read-onlyIdempotent

Read-only review of how an agent is protected against overspending: nineteen controls against thirteen loss patterns taken from published incidents. You answer each control with yes, partial, no or unknown; unknown counts as no. Answer at least six. Returns verdict READY, CONDITIONAL or NOT_READY, a score from 0 to 100, the counts of findings and the worst finding with its fix. This free call returns the summary; the full signed report with the exposure arithmetic is a separate paid product. Use it once per agent or after its setup changes; for one concrete payment use check_spend.

Input Schema

NameRequiredDescriptionDefault
ev_checkNoyes, partial, no or unknown. Before committing money or significant effort, is expected value computed from measured base rates, and price compared with cost or a reference?
idempotencyNoyes, partial, no or unknown. Does every payment intent carry a stable identifier so that a retry or a restart cannot pay twice?
keys_scopedNoyes, partial, no or unknown. Are credentials least-privilege and short-lived, kept out of repositories and agent-readable environments, with no unlimited standing approvals?
loop_breakerNoyes, partial, no or unknown. Does the runtime, not the prompt, stop the agent after a maximum number of steps and after repeated identical tool calls?
outcome_metricNoyes, partial, no or unknown. Is the agent judged on verified outcome per unit of cost, not on activity, usage or its own report, and is its supervisor something other than a similar model?
reconciliationNoyes, partial, no or unknown. Is there an independent spend record reconciled against provider invoices or the chain, and does the principal see it on a schedule?
aggregate_budgetNoyes, partial, no or unknown. Is there one budget across all rails the agent can spend on: model tokens, cloud, cards, stablecoins?
delivery_bindingNoyes, partial, no or unknown. Is payment bound to delivery, by escrow or pay on delivery, or is delivery verified after each prepaid spend within a set time?
system_of_recordNoyes, partial, no or unknown. Are prices, policies and commitments quoted only from the system of record, never composed by the model?
budget_period_usdYesthe budget of the agent for one period in US dollars; required
irreversible_gateNoyes, partial, no or unknown. Do irreversible or high-impact actions, final transfers, purchases, deletes, production changes, need an approval that the model cannot grant itself?
billing_path_knownNoyes, partial, no or unknown. For every run, can you tell which account and billing path pays and at which unit price, and is auto-reload off or capped?
counterparty_checkNoyes, partial, no or unknown. Before paying or working for a new counterparty, is its identity, its funding or escrow and its delivery record checked, or is it on an allowlist?
progress_stop_lossNoyes, partial, no or unknown. Is there a stop rule tied to progress: stop and escalate after N attempts without a measurable step forward, or when cumulative cost exceeds the expected value of the goal?
untrusted_input_gateNoyes, partial, no or unknown. Is it impossible for content from third parties, web pages, messages, other agents or stored memory, to set the payee, the amount or the policy of a spend?
cost_per_run_measuredNoyes, partial, no or unknown. Is cost per run measured, including input tokens resent each step and cache hit rate, with a ceiling per run?
hard_cap_outside_modelNoyes, partial, no or unknown. Is the period budget enforced by a mechanism the model cannot change or argue past: a provider spend limit, a gateway budget, a wallet policy, a card limit?
per_action_cap_enforcedNoyes, partial, no or unknown. Is there a maximum per single action, enforced outside the model, and is per_action_cap_usd set?
alerts_cover_all_channelsNoyes, partial, no or unknown. Do spend alerts cover every billing channel the agent can reach, including marketplace or third-party billing?

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed19 schema fields changed
    • changedInput schema / properties / aggregate_budget / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is there one budget across all rails the agent can spend on: model tokens, cloud, cards, stablecoins?"
    • changedInput schema / properties / alerts_cover_all_channels / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Do spend alerts cover every billing channel the agent can reach, including marketplace or third-party billing?"
    • changedInput schema / properties / billing_path_known / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. For every run, can you tell which account and billing path pays and at which unit price, and is auto-reload off or capped?"
    • changedInput schema / properties / budget_period_usd / description
      Previous value: -"budget for one period, required"New value: +"the budget of the agent for one period in US dollars; required"
    • changedInput schema / properties / cost_per_run_measured / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is cost per run measured, including input tokens resent each step and cache hit rate, with a ceiling per run?"
    • changedInput schema / properties / counterparty_check / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Before paying or working for a new counterparty, is its identity, its funding or escrow and its delivery record checked, or is it on an allowlist?"
    • changedInput schema / properties / delivery_binding / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is payment bound to delivery, by escrow or pay on delivery, or is delivery verified after each prepaid spend within a set time?"
    • changedInput schema / properties / ev_check / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Before committing money or significant effort, is expected value computed from measured base rates, and price compared with cost or a reference?"
    • changedInput schema / properties / hard_cap_outside_model / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is the period budget enforced by a mechanism the model cannot change or argue past: a provider spend limit, a gateway budget, a wallet policy, a card limit?"
    • changedInput schema / properties / idempotency / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Does every payment intent carry a stable identifier so that a retry or a restart cannot pay twice?"
    • changedInput schema / properties / irreversible_gate / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Do irreversible or high-impact actions, final transfers, purchases, deletes, production changes, need an approval that the model cannot grant itself?"
    • changedInput schema / properties / keys_scoped / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Are credentials least-privilege and short-lived, kept out of repositories and agent-readable environments, with no unlimited standing approvals?"
    • changedInput schema / properties / loop_breaker / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Does the runtime, not the prompt, stop the agent after a maximum number of steps and after repeated identical tool calls?"
    • changedInput schema / properties / outcome_metric / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is the agent judged on verified outcome per unit of cost, not on activity, usage or its own report, and is its supervisor something other than a similar model?"
    • changedInput schema / properties / per_action_cap_enforced / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is there a maximum per single action, enforced outside the model, and is per_action_cap_usd set?"
    • changedInput schema / properties / progress_stop_loss / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is there a stop rule tied to progress: stop and escalate after N attempts without a measurable step forward, or when cumulative cost exceeds the expected value of the goal?"
    • changedInput schema / properties / reconciliation / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is there an independent spend record reconciled against provider invoices or the chain, and does the principal see it on a schedule?"
    • changedInput schema / properties / system_of_record / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Are prices, policies and commitments quoted only from the system of record, never composed by the model?"
    • changedInput schema / properties / untrusted_input_gate / description
      Previous value: -"yes, partial, no or unknown"New value: +"yes, partial, no or unknown. Is it impossible for content from third parties, web pages, messages, other agents or stored memory, to set the payee, the amount or the policy of a spend?"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic safety profile (readOnly, idempotent, non-destructive); the description supplies the substantive behaviour: grading rule for 'unknown', minimum answer count, the three verdicts, the 0-100 score, the returned finding set, and the free-vs-paid boundary for the signed report. That is context no structured field provides.

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?

Information-dense and front-loaded: capability, then answering protocol, then return values, then the commercial boundary, then routing to check_spend. Slightly compressed in the middle clause, but no sentence is filler.

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 19-parameter read-only audit with no output schema, the description covers the input protocol, the output shape and the follow-on paid product. An agent has everything needed to call it and interpret the result.

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 description coverage is 100%, so per-parameter meaning is already documented and the baseline is 3. The description nevertheless adds semantics the schema does not carry: the 'unknown counts as no' scoring rule and the six-answer minimum that gates whether a verdict is produced.

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?

Opens with a specific verb+resource+scope ('Read-only review of how an agent is protected against overspending') and quantifies the instrument (nineteen controls against thirteen loss patterns). It also names the sibling it is not, so an agent can separate it from check_spend 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?

Explicit when-to-use ('once per agent or after its setup changes') and an explicit alternative for the contrasting case ('for one concrete payment use check_spend'). Prerequisites and the answering convention ('unknown counts as no', 'answer at least six') are stated rather than 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