spend-guard
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPEND_GUARD_RAILS | No | Payment rails: mock (default, pays nothing), near, arc, gateway, or a comma list. The paying rails need testnet keys that are not set here. | |
| SPEND_GUARD_LEDGER | No | Decisions file (default ~/.spend-guard/ledger.jsonl). off keeps it in memory. | |
| SPEND_GUARD_POLICY | No | Path to a policy JSON file. Without one, every payment waits for the user's approval. | |
| SPEND_GUARD_MOCK_NETWORK | No | Network the mock rail pretends to pay on (default near-testnet). | |
| SPEND_GUARD_DASHBOARD_PORT | No | Approval dashboard port on 127.0.0.1 (default 4400). off: no dashboard, and payments that need approval are declined. | |
| SPEND_GUARD_APPROVAL_TIMEOUT | No | Seconds a payment waits for approval before it is declined (default 55). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pay_and_fetchA | Fetch a URL and, if it answers HTTP 402 (an x402 paywall), pay it through the user's Spend Guard. The payment goes out only if it fits the user's budget, goes to an address the service is known to use and is not a price spike; larger payments and unknown services wait for the user to approve them on the dashboard. Returns the HTTP status, what was paid (amount, payee, transaction) and the response body. Redirects are not followed. A refused payment is final: tell the user what was refused and why, and do not try to pay another way. |
| spending_statusA | What has been spent today against the user's daily budget, payments waiting for the user's approval, and the latest payments with their outcome (paid, denied, declined or failed) and every reason. Check it before a series of paid calls. |
| spending_policyA | The rules the guard enforces: the networks it can pay on, the daily and per-payment limits, the amount above which the user approves, the price-spike ratio, and the known services with the addresses they may be paid at. Read only: only the user can change them. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: one performs fetch-and-pay, one reports spending state, and one describes policy. There is no overlap in action or resource, so an agent can easily pick the right tool.
Names are readable but use mixed conventions: pay_and_fetch is verb_and_verb while spending_status and spending_policy are noun phrases. The shared spending_ prefix helps, but the set does not follow a predictable verb_noun pattern.
Three tools is slightly thin but well matched to a narrow spend-guard purpose. Each tool earns its place, though a few more operations could be reasonable.
The surface covers the core lifecycle: paying via fetch, checking budget/status, and reading enforced policy. Minor gaps exist around explicit history or approval workflows, but these are intentionally left to the user dashboard.