Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PORTNoThe port the process listens on. The process binds 0.0.0.0.4317
SQLITE_PATHNoPath 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_URLNoPublic base URL for the service, e.g. https://botsupply.onrender.com. Required for paid Stripe checkout when Stripe is enabled.
STRIPE_SECRET_KEYNoSecret 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_SECRETNoSigning 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 13 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityNo data
ResponsivenessSyncing