spend-guard
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPEND_GUARD_URL | No | Address of your Spend Guard server, e.g. https://guard.example.com. Optional: without it the server starts and lists its tools, but tool calls say it is not set up. | |
| SPEND_GUARD_AGENT_KEY | No | This agent's key (sg_agent_...), created by the owner with POST /v1/agents. Optional, like SPEND_GUARD_URL. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| request_paymentA | Ask to pay a known recipient by mobile money. Spend Guard checks the request against your spending policy and answers allowed (it's paid out), held (a person must approve it first) or denied. Amounts are in minor units: GHS 120.50 is 12050. The recipient must be an id from your allowed list (see get_my_limits). Always pass an idempotency_key tied to the thing being paid, like 'invoice-88', and reuse it if you retry: the same key never pays twice. If the answer is held or denied, don't retry, split the amount or switch recipient; tell the user. |
| check_paymentA | Look up a payment request you made earlier: whether it's still held, approved, rejected or expired, and how its payout went. |
| get_my_limitsA | Your spending policy and how much of it you've used today and this month: limits, allowed recipients, when payments need approval, and working hours. |
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: request_payment initiates a payment, check_payment looks up an existing payment's status, and get_my_limits returns policy/limits information. There is no overlap in action or resource, so an agent can easily choose the right tool.
All names use consistent snake_case with a clear verb_noun structure: check_payment, request_payment, get_my_limits. The pattern is predictable and readable.
Three tools are well-scoped for a narrow spend-guard workflow: initiate, inspect, and retrieve limits. Each tool earns its place, and there is no redundant surface.
The core lifecycle is covered: request a payment, check its status, and understand policy limits. Minor gaps exist, such as listing all payments or canceling a held payment, but these are workaroundable with the current surface.