Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
RPC_URLNoEthereum RPC endpoint URL.
AGENT_IDNoAgent identity used in stdio mode. Defaults to the OS user.
CHAIN_IDNoEthereum chain ID (e.g., 8453 for Base mainnet, 84532 for Base Sepolia).
TRANSPORTNoTransport type for the MCP server. 'stdio' for local, 'streamable-http' for hosted HTTP.stdio
ENABLE_SENDSNoSet to 'true' to enable sending transactions. Sends are off by default.false
MAX_FEE_GWEINoMaximum gas fee cap in Gwei to protect against mispriced RPCs.
IMPREST_API_KEYSNoComma-separated list of API keys with identities (e.g., 'sk-...:agent-name'). Required for HTTP transport.
IMPREST_ADMIN_KEYSNoComma-separated list of admin API keys for the approval flow. Optional, for HTTP transport.

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
request_paymentA

Request to pay an address. The spend policy decides whether it is allowed, blocked, or requires human approval. Use this whenever you need to send a payment; do not attempt to move funds any other way.

Args: recipient: destination 0x address amount: amount to send, in whole units of asset (e.g. 0.05, 50) reason: what the payment is for (recorded in the audit log) asset: what to send — "ETH" (native, the default) or a token symbol such as "USDC". Each asset has its own policy limits.

request_approvalA

Grant a token spender an allowance so a contract (a marketplace, subscription, or swap) can later pull funds. The policy decides whether it is allowed, blocked, or needs human approval.

imprest approves an EXACT amount only — never an unlimited allowance, the vector behind most token drains. The allowance is capped by, and counts against, the same per-asset limits as a direct payment, and the TOTAL of live allowances across all spenders is itself capped (an allowance outlives budget windows, so it is tracked as a standing liability). Approving 0 revokes the spender's allowance and frees cap.

Args: spender: the 0x address being granted the allowance amount: the allowance, in whole units of asset (e.g. 25 for 25 USDC); 0 revokes this spender's existing allowance asset: the token symbol (e.g. "USDC"); native ETH cannot be approved reason: what the approval is for (recorded in the audit log)

pay_x402A

Fetch a paid HTTP resource, paying for it over the x402 protocol ("402 Payment Required"). Use this for pay-per-request APIs that quote a price in the 402 response; the spend policy decides whether the quoted price is allowed, blocked, or requires human approval.

The payment is a signed one-time authorization for EXACTLY the quoted amount — never more — and it only happens if the quote passes policy.

Args: url: the resource to fetch (https) max_amount: the most you expect this to cost, in whole token units (e.g. 0.01 for 1 cent of USDC). If the server demands more, the request is refused before policy even runs. reason: what the purchase is for (recorded in the audit log)

list_pending_approvalsA

(operator only) List payments/approvals waiting for a human decision.

Requires an admin identity — an agent cannot see or clear its own pending approvals. Over stdio the local operator is the admin.

resolve_approvalA

(operator only) Approve or reject a pending payment and, on approval, execute it. This is the resume path for needs_approval.

A human approval overrides only the approval threshold — the hard limits (per-transaction cap, budgets, deny/allow list) are RE-CHECKED against the current ledger at approval time, so an approval that would now bust a budget is refused rather than forced through.

Args: payment_id: the audit id of the pending row (from list_pending_approvals) approve: True to approve and execute, False to reject note: optional operator note recorded on the row

get_balanceA

Get the balance of an address (read-only).

Args: address: the 0x address to check asset: "ETH" (native, default) or a token symbol such as "USDC"

get_gas_priceA

Get the current gas price in gwei (read-only).

get_audit_log

Return the full history of this agent's payment attempts and what the policy decided about each — approved, denied, or executed.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 7 tools

Disambiguation4/5

Each tool has a distinct purpose: direct payment, token allowance, paid HTTP fetch, operator pending-action management, and read-only balance/gas. However, 'request_approval' can be misread as requesting human approval, which overlaps conceptually with list_pending_approvals/resolve_approval, though the descriptions make the distinction clear.

Naming Consistency4/5

The tool names mostly follow a consistent verb_noun pattern: request_*, list_*, resolve_*, get_*. 'pay_x402' is a slight outlier as a verb plus protocol identifier, and 'request_approval' is semantically a bit misleading, but there is no mixed casing or chaotic verb usage.

Tool Count5/5

Seven tools is well-scoped for a crypto spend-control server: three spend paths (payment, allowance, x402), two operator approval tools, and two read-only helpers. The set is neither bloated nor too thin.

Completeness4/5

The core lifecycle is covered: requesting payments, granting/revoking allowances, paying for HTTP resources, and operator approval of pending actions. Minor gaps include no audit/history listing, no way to query current allowances or policy limits, and agents cannot list their own pending requests, but these are workable around.

Maintenance

ActivitySlowing
ResponsivenessNo issues