veyra-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VEYRA_TOKEN | Yes | Your 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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
| get_paymentA | Get canonical state for one payment request, including which rail settled it and, once confirmed on a real rail, |
| list_paymentsC | List this agent's recent payments. |
| cancel_paymentC | Cancel a payment only while still cancellable. |
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 7 tools
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.
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.
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.
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.