Skip to main content
Glama

Agent Spend Governor — ATOMIC reserved lease (PAID $0.02)

v1_governance_reserve

Reserve an atomic budget lease for an AI agent's paid actions by specifying a USD amount, intent, and optional TTL; USDC settlement occurs on Base.

Instructions

Agent Spend Governor — ATOMIC reserved lease (PAID $0.02)

Remote route: POST /v1/governance/reserve (0.02 USD x402/base/usdc on eip155:8453).

Input Schema

NameRequiredDescriptionDefault
amountYesSpend amount in USD. Must be >= 0 and <= 1e12. Values above the bound are rejected with 422.
intentYes
agent_idYes
ttl_secondsNo

Output Schema

NameRequiredDescriptionDefault
statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.3/5.0
Behavior3/5

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

Annotations already cover the safety profile (not read-only, not idempotent, open-world). The description does add genuinely useful non-annotation context: the call is paid at 0.02 USD via x402/USDC on eip155:8453 and the operation is atomic. However, it says nothing about what the lease holds, what happens on expiry, or how the reservation is later released or settled.

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?

It is short and front-loaded, but the first sentence merely echoes the tool title, which is wasted space given how little substantive information follows. The route/price sentence is the only sentence that earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paid, non-idempotent mutation with a lease/TTL model, the description omits the lifecycle an agent needs: what is reserved, whether retries double-charge given idempotentHint=false, and how the lease is released. The output schema covers return values, but the operational context does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25% — just 'amount' is documented — and the description supplies no parameter meaning at all. It never explains 'intent', 'agent_id', or what a 300-second 'ttl_seconds' lease implies, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description largely restates the title ('Agent Spend Governor — ATOMIC reserved lease') and adds only a route and price. 'ATOMIC reserved lease' is jargon that never resolves into a concrete verb+resource statement an agent can act on, and nothing distinguishes it from siblings like v1_governance_settle, v1_budget_preflight, or v1_agent_treasury_authorize.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance. Given a sibling set containing budget preflight, treasury authorize/commit/release, and governance settle, an agent cannot tell at which stage of a spend lifecycle this reserve step belongs.

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

Deploy Server

Other Tools