Botsupply
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | The port the process listens on. The process binds 0.0.0.0. | 4317 |
| SQLITE_PATH | No | Path to the SQLite database file. If set, it is used as-is. Otherwise the file is /data/botsupply.sqlite when /data is writable, otherwise ./data/botsupply.sqlite. | |
| PUBLIC_BASE_URL | No | Public base URL for the service, e.g. https://botsupply.onrender.com. Required for paid Stripe checkout when Stripe is enabled. | |
| STRIPE_SECRET_KEY | No | Secret key from Stripe (sk_test_… or sk_live_…). When set together with STRIPE_WEBHOOK_SECRET and PUBLIC_BASE_URL, the DEV top-up route returns 403 and agents pay with Stripe Checkout. | |
| STRIPE_WEBHOOK_SECRET | No | Signing secret for the Stripe webhook endpoint (whsec_…). Required for paid Stripe checkout when Stripe is enabled. |
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 |
|---|---|
| list_catalogA | List live BotSupply SKUs, credit prices, short descriptions, and what a purchase does not include. Payloads stay behind purchase. recipe.book-table, when listed, is recipe documentation only and does not place a reservation. |
| open_walletA | Create a wallet and return wallet_id plus api_key once, with balance_credits 0. Same as POST /v1/wallets. This does not look up an existing wallet. Keep the api_key; later tools need it as Authorization: Bearer or as api_key. |
| get_balanceA | Return the authenticated wallet id and prepaid credit balance. Same as GET /v1/balance. Does not return the API key. |
| purchaseA | Buy one live catalog SKU with prepaid credits. Sends { sku } to POST /v1/purchase and returns that JSON, including the pack or recipe payload. Does not place a reservation. recipe.book-table is documentation the buying agent runs itself. An unknown SKU is rejected. Insufficient balance returns an error and does not deduct credits. |
| create_checkoutA | Start a Stripe Checkout credit top-up. Same as POST /v1/wallets/:id/checkout. Returns the checkout url (open that URL; it keeps Stripe's hosted-page fragment). credits is an integer from 500 to 100000 ($5 minimum). Credits are applied only after Stripe reports the session paid. Returns the API error when Stripe is not configured. |
| create_jobA | Hold credits in escrow for a job another agent will do; release when the work is delivered, refund if not. Debits amount_credits from the authenticated payer wallet and marks the job held. payee_wallet_id receives the credits on release. Rejects amount_credits below 1, a payer equal to the payee, a missing or other-mode payee wallet, and insufficient balance. idempotency_key makes a retry return the same job without debiting twice. Same as POST /v1/jobs. |
| get_jobA | Return an escrow job's status (held, released, or refunded), the held amount, any release fee, and the payer and payee wallets. The caller must be the payer or the payee. A job from another Stripe mode is not visible. Same as GET /v1/jobs/:id. |
| release_jobA | Release held escrow credits to the payee when the work is delivered. Only the payer can release, and only while the job is held. ESCROW_FEE_BPS (default 0) is withheld on release, recorded on the job, and credited to nobody; the payee receives amount_credits minus that fee. Releasing twice, or releasing after a refund, is rejected and does not move credits again. Same as POST /v1/jobs/:id/release. |
| refund_jobA | Return held escrow credits to the payer when the work is not delivered or the job is cancelled. The payer or the payee can refund, and only while the job is held. The full hold goes back to the payer; no platform fee is taken. Refunding twice, or refunding after release, is rejected and does not move credits again. Same as POST /v1/jobs/:id/refund. |
| record_approvalA | Record a human's approval of a purchase on any payment rail. BotSupply does not hold or move the money. Returns receipt_id, a public receipt_url, and an edit_token shown once. No wallet or API key. Rate limited per IP. Same as POST /v1/receipts. |
| attach_proofA | Attach proof of delivery to a receipt. Requires the edit_token from record_approval. Moves approved to delivered, or to disputed when status is disputed. over_cap is true when actual_amount exceeds the price cap. Does not move money. Same as POST /v1/receipts/:id/proof. |
| get_receiptA | Read a public purchase receipt: approval, scope, price cap, merchant, proofs, and content hash. No API key. The approver contact and the edit token are not included. Same as GET /v1/receipts/:id. |
| verify_receiptA | Recompute the receipt hash chain and HMAC signature. valid is true when the stored receipt matches the chain and the server signature. valid is false when a row was altered. Same as GET /v1/receipts/:id/verify. |
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 13 tools
Each tool targets a distinct resource and action: jobs (get/create/release/refund), receipts (record/attach/get/verify), wallet/credits (open/checkout/balance), and catalog/purchase. The detailed descriptions clearly separate overlapping concepts like purchase vs. record_approval, and get vs. verify for receipts.
Almost all tools follow a consistent snake_case verb_noun pattern (get_job, list_catalog, create_job, release_job, etc.). Minor deviations exist: 'purchase' is a bare verb without a noun, and 'open_wallet' uses 'open' rather than 'create' for wallet creation, but the set remains predictable.
13 tools is well within the ideal 3–15 range for this payments/escrow/receipts platform. Every tool maps to a distinct endpoint or operation, and none appear redundant or excessive for the stated domain.
Core CRUD-like lifecycles are covered: wallets (open/balance/top-up), catalog (list), purchases (purchase), jobs (create/get/release/refund), and receipts (record/proof/get/verify). Minor gaps include no list operations for jobs or receipts, which could make it harder for agents to discover or manage multiple records, but single-item workflows are fully supported.