Veyline MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAYLOAD_RAIL_URL | No | Payload rail base URL. | https://payload-rail.fly.dev |
| PAYLOAD_RAIL_API_KEY | Yes | Your own Payload rail API key for an existing Veyline organization. Sent to the rail only as a Bearer Authorization header. Required for tool calls; with no API key configured, the server still starts and lists its tools, but every tool call returns a clear "API key not configured" error. |
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 |
|---|---|
| veyline_statusB | Read the current authenticated organization Veyline entitlement and tier. Does not authorize a payment. (Rail A2A skill veyline_status.) |
| veyline_usageB | Read the current authenticated organization quota and usage. Does not change policy. (Rail A2A skill veyline_usage.) |
| veyline_preflightA | Request a signed, short-lived, policy-enforced payment preflight. No funds are transferred. Requires Veyline execution scope and the original authoritative x402 quote. Pass the payment intent (recipient, amount, asset, network) and, when available, the original x402 quote object. (Rail A2A skill veyline_preflight.) |
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 3 tools
The three tools are mostly distinct: status reads entitlement/tier, usage reads quota consumption, and preflight requests a signed payment authorization. Status vs. usage overlap somewhat (both are read-only org-state reads about the same domain), but the descriptions make the boundary clear enough to select correctly.
All tools follow the same predictable pattern: a shared veyline_ prefix with a single snake_case scope noun (status, usage, preflight). No mixed conventions or stylistic outliers.
Three tools is on the thin side but defensible for a narrow read-only entitlement/usage plus preflight surface. Each tool earns its place with no redundancy.
The surface covers reads (entitlement, usage) and preflight authorization, but there is no tool to check preflight status, revoke/cancel a preflight, or submit/settle the actual payment path, leaving a lifecycle dead end after preflight. Agents must complete payment execution elsewhere.