Bridge between Lightning Network and Model Context Protocol
Lightning MCP has 6 tools across two implementations (fastmcp and official SDK). Tool naming is inconsistent: 'lightning/createInvoice' vs 'create_invoice' (camelCase vs snake_case). Descriptions are present but minimal (10-50 chars), below the 194-char baseline for production tools. Input schemas are visible and properly typed, but parameter descriptions are sparse. Critical issue: tools 1-4 (fastmcp) and 5-6 (example_mcp_server.py) are duplicates with different naming conventions, creating confusion. No output schemas documented. Error handling and recovery guidance absent. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having READ_ONLY and IRREVERSIBLE operations.
Create a Lightning Network invoice for the specified amount
Get the current wallet balance
Check the status of a Lightning Network payment.
Create a Lightning Network invoice.
Get the current wallet balance.
Pay a Lightning Network invoice.
Duplicate tools with inconsistent naming: 'lightning/createInvoice' (camelCase) vs 'create_invoice' (snake_case). LLMs will conflate these as the same tool, causing confusion and wasted reasoning cycles.
Descriptions are too short (10-50 chars vs 194-char baseline). 'Create a Lightning Network invoice' lacks context on when to use it, what it returns, or prerequisites. Descriptions should explain WHAT, WHEN, and WHY.
No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., payment_hash, payment_request). Responses are unstructured.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
No tool annotations despite clear risk levels (IRREVERSIBLE, WRITE, READ_ONLY). Missing destructiveHint and readOnlyHint annotations prevent agents from understanding operation safety.
No error handling or recovery guidance. If payInvoice fails, LLM has no guidance on retry strategy, user-fixable vs fatal errors, or next steps.