MCP server for interacting with the Voltage Payments API to manage wallets and process Lightning Network payments
Server has 9 tools with basic descriptions and parameter schemas. Naming follows verb_noun convention (get_, create_, delete_, pay_, generate_, check_). However, critical gaps exist: (1) descriptions are minimal (10-50 chars), lacking WHEN/WHY context and prerequisites; (2) parameter descriptions are present but generic, missing constraints (enums, ranges, formats); (3) no output schemas documented, LLMs cannot plan downstream calls; (4) create_wallet accepts a bare 'dict' with undocumented required fields; (5) no error handling guidance; (6) destructive operations (delete_wallet, pay_bolt11_invoice) lack confirmation or dry-run patterns. Tool names are clear but descriptions do not meet the 50-200 char LLM-optimized baseline. Schemas are present but incomplete.
Check the status of a payment by its ID
Create a new wallet in the organization
Delete a specific wallet by its ID
Generate a BOLT11 invoice for receiving a payment
Get all wallets for the organization
Get a list of payments with optional filtering parameters
Get a specific wallet by its ID
Descriptions are too short (10-50 chars) and lack WHEN/WHY context. LLMs cannot determine when to select a tool vs. similar alternatives. E.g., 'Get all wallets for the organization' does not explain prerequisites, return structure, or when to call it instead of get_wallet.
create_wallet accepts a bare dict parameter with undocumented required fields (id, environment_id, line_of_credit_id, name, network, limit). No schema validation, no enum constraints, no format hints. LLMs cannot construct valid requests without trial-and-error.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., wallet_id from create_wallet response). Breaks tool composition and forces discovery detours.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Get the ledger for a specific wallet by its ID
Pay a BOLT11 invoice
Destructive operations (delete_wallet, pay_bolt11_invoice) lack confirmation, dry-run, or recovery guidance. Agents can irreversibly delete wallets or send payments without safeguards. No error classification (retryable vs. fatal) to guide agent recovery.
Parameter descriptions lack constraints. E.g., sort_order accepts 'ASC' or 'DESC' but description does not enumerate valid values. kind accepts 'bolt11, onchain, or bip21' but as free-form string, not enum. LLMs will hallucinate invalid values.