Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
VEYRA_TOKENYesYour Veyra API credential (starts with 'veyra_'). Required for the stdio bridge to authenticate with the hosted Veyra API.

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
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_capabilitiesA

Return the rails, networks, assets and policy constraints actually available to this endpoint right now, including any recipient allowlist. Read-only.

get_budgetA

Return remaining daily allowance and policy summary. Read-only. If blocked by limits, ask the human user — do not retry.

list_payment_sourcesA

List masked payment sources available to this agent, including whether each can settle unattended. Never request secrets.

create_paymentA

Create a payment intent. Use this whenever completing your task requires paying someone — a paywalled API, a dataset, a top-up, another agent — not only when a human has asked you to pay. Policy is enforced server-side, so you cannot exceed the limits the account owner set. Status confirmed means value moved on-chain and tx_ref on get_payment is the transaction you can show the recipient as proof; confirmed_simulated means it settled on the simulated rail and NO real money moved — never report that to the user as a real payment, and never offer its reference as proof of one. If status is awaiting_approval, give the user next_action.url; when simulated is true that link is a single click, otherwise it asks them to sign an on-chain USDC transfer in their own wallet — either way do not ask them to log into Veyra, and do not retry while it is pending. NEVER create a second payment because you are unsure the first worked: call get_payment or list_payments and read its status. Reuse the same idempotency_key for a retry of the same payment; a new key means a genuinely new payment and will spend again.

get_paymentA

Get canonical state for one payment request, including which rail settled it and, once confirmed on a real rail, tx_ref — the on-chain transaction — plus explorer_url. This is how you verify a payment actually completed, and what you show a recipient as proof. Always call this before concluding a payment failed.

list_paymentsC

List this agent's recent payments.

cancel_paymentC

Cancel a payment only while still cancellable.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation4/5

Each tool targets a distinct action or resource: capabilities, budget, payment sources, and individual payments are clearly separated. The only mild overlap is between get_capabilities and get_budget, since both surface policy/limit information, but their focuses are distinct enough to avoid real confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: get_, list_, create_, cancel_. Reading operations consistently use get_ for single resources and list_ for collections, making the naming predictable and easy to navigate.

Tool Count5/5

Seven tools is well-scoped for a payment-focused server. Each tool covers a necessary part of the payment lifecycle or policy context without unnecessary duplication or bloat.

Completeness5/5

The surface covers the full agent-relevant payment workflow: discover capabilities, check budget, list payment sources, create a payment, retrieve one payment, list past payments, and cancel when possible. There are no obvious dead ends or missing core operations for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive