Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PORTNoHTTP server port (when TRANSPORT=http)3402
NWC_URINoNostr Wallet Connect URI for autonomous Lightning payments
TOR_PROXYNoSOCKS5 proxy for .onion addresses (e.g. socks5h://127.0.0.1:9050)
TRANSPORTNoTransport mode: stdio or httpstdio
SOCKS_PROXYNoGeneric SOCKS5 proxy for all requests when set
CASHU_TOKENSNoPath to Cashu token store file
HNS_GATEWAY_URLNoHTTP gateway for Handshake (.hns) domains (e.g. https://hns.to)
CREDENTIAL_STORENoPersistent macaroon/credential storage~/.402-mcp/credentials.json
MAX_AUTO_PAY_SATSNoSafety cap; payments above this require human confirmation1000
TRANSPORT_PREFERENCENoPreferred transport order for multi-URL services (comma-separated)onion,hns,https,http

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
l402-configA

Introspect the MCP's payment capabilities: which wallets are configured, spending limits, and stored credential count. Call this first to understand what payment methods are available.

l402-discoverA

Probe an endpoint to discover its L402 pricing without committing to payment. Returns the cost in sats, available payment methods, and credit tiers (if toll-booth server). The challenge is cached so a subsequent l402-pay can reuse it.

l402-fetchA

Fetch a URL, paying its HTTP 402 challenge (L402, IETF Payment, Cashu or LNURLcash) when autoPay is true and the price is within MAX_AUTO_PAY_SATS, maxCostSats and the spend limits. Reuses stored credentials. Without autoPay, a 402 comes back with its price and paymentHash so the user can decide; l402-pay can then pay it. For x402 services, which this server supports only in an experimental custom format, returns the payment details for the user to pay in their own wallet. Response bodies are marked as untrusted content. With widget hosts, call l402-fetch-preview first to show the price.

l402-payA

Pay a challenge that l402-fetch or l402-discover returned, by its paymentHash, and store the credential so the next l402-fetch succeeds. For human wallets, polls the payment page for settlement for up to 120s; call it straight after showing the payment URL to the user. An invoice that did not come from such a challenge is paid only if the human approves it in the client.

l402-credentialsA

List all stored L402 credentials. Shows origin, cached credit balance, and server type. Balance values are cached and may be stale; check lastUsed timestamp.

l402-balanceA

Check cached credit balance for a server. Returns the last known balance from the credential store without making a network request. The "stale" flag is true if the balance was last updated more than 5 minutes ago.

l402-store-tokenA

Store an L402 token (macaroon:preimage) obtained from a payment page. Use this when a user pastes back a token from a toll-booth payment page. The token is stored as a credential so subsequent l402-fetch calls are authenticated.

l402-buy-creditsA

Buy credits from a toll-booth server with volume discounts. Omit amountSats to discover available tiers. Provide amountSats to purchase a specific tier. Only works with toll-booth servers.

l402-reconcileA

Resolve a payment whose outcome is unknown. While one is unresolved, auto-pay to that service is paused. Call with no arguments to list them, or with a paymentHash to ask the wallet (NWC lookup_invoice, or the Cashu mint for a reserved melt). A settled payment stores its credential when it can; a failed one is cleared. A preimage that hashes to the payment hash also settles it. abandon: true asks the human to confirm that the payment did not go out.

l402-redeem-cashuA

Redeem Cashu ecash tokens directly on a toll-booth server, avoiding the Lightning round-trip. Handles the two-step flow automatically (create invoice then redeem token). Only works with toll-booth servers.

l402-searchA

Search Nostr relays for paid API announcements (kind 31402) and return their URLs, pricing and capabilities. Topic and payment-method filters are sent to the relays; the query text is matched locally. Announcement text is written by whoever published it and is marked as untrusted content.

l402-fetch-previewA

Preview payment requirements for a URL without spending any sats. Returns cost, protocol, and payment method so a confirmation dialog can be shown. Use this before l402-fetch to give the user a chance to approve or cancel payment. For widget hosts, the result drives a payment confirmation dialog.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 12 tools

Disambiguation3/5

Most tools have distinct purposes, but l402-discover and l402-fetch-preview overlap significantly: both probe a URL to return pricing without payment. l402-balance and l402-credentials also both expose cached credit balances, though at different scopes.

Naming Consistency4/5

All tools share a consistent l402- prefix and snake_case style, which makes the set feel cohesive. However, not all follow the same verb_noun pattern: l402-balance, l402-config, and l402-credentials are noun-style names, while most others are verb-led.

Tool Count5/5

Twelve tools is well-scoped for a payment-focused MCP server that needs to cover discovery, preview, fetching, paying, reconciliation, credentials, balance, and credit management. Each tool earns its place in the workflow.

Completeness4/5

The core L402 lifecycle is well covered: discover, preview, fetch, pay, store tokens, reconcile unknowns, buy credits, and redeem ecash. Minor gaps exist such as no explicit credential deletion or configuration update, but agents can complete the main payment flows without dead ends.

Maintenance

ActivityActive
ResponsivenessUnresponsive