Loading ToolBench

Reading the current corpus…

btc-lightning-mcp-server MCP server · F · ToolBench

← Browse

btc-lightning-mcp-server

github.com/ehallmark/btc-lightning-mcp-server

MCP server for Bitcoin Lightning Network operations via LND node

2026-07-28+STREAMABLE_HTTP5 tools

47/100

Definition Quality51

Protocol Readiness65

Supportability28

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: Streamable HTTP

Current-spec patterns detected

Summary

Server has 5 tools with basic descriptions and minimal input schemas. Naming is verb-first (pay_, create_, check_, get_) which is good. However, schemas are incomplete: most parameters lack descriptions, and output schemas are undocumented. Error handling is absent, no recovery guidance, no categorization. The server exposes raw protobuf JSON responses without shaping, violating mxe:strip-api-responses. No tool annotations (readOnlyHint/destructiveHint). Overall, this is a D-grade server with functional but poorly documented tools.

Tools (5)

check_invoice_is_settledread onlyauthsource verified50/100

Check if an invoice is settled.

check_wallet_balanceread onlyauthsource verified45/100

Check my wallet balance.

create_invoicewriteauthsource verified57/100

Create an invoice for the given amount and return the invoice payment request.

get_public_inforead onlyauthsource verified48/100

GetInfo returns general information concerning the lightning node including its identity pubkey, alias, the chains it is connected to, and information concerning the number of open+pending channels.

pay_invoicewriteauthsource verified57/100

Pay a payment request.

Issues (5)

CRITICALtool-description ↗

Parameter descriptions missing on all tools. 'payment_request', 'amount', 'r_hash' lack descriptions explaining format, constraints, or expected values. LLMs cannot infer parameter meaning from names alone.

pay_invoicecreate_invoicecheck_invoice_is_settled

CRITICALresponse-shaper ↗

Output schemas undocumented. Tools return raw MessageToJson() or primitive types without documenting structure. LLMs cannot plan downstream calls or extract required fields (e.g., invoice payment request format, balance field name).

pay_invoicecreate_invoiceget_public_info

HIGHrecovery-guide ↗

No error handling or recovery guidance. Tools return raw exceptions without actionable messages. If payment fails or invoice lookup fails, LLM receives no guidance on retry strategy or next steps.

pay_invoicecreate_invoicecheck_invoice_is_settled

Recommendations

Add parameter descriptions to all tools. Example: 'amount' → 'The invoice amount in satoshis (positive integer, 1 - 21000000)'. 'r_hash' → 'The payment hash as 32 bytes or base64-encoded string. Use base64 if passing as string.'
Document output schemas. Example for create_invoice: 'Returns {payment_request: string, r_hash: string, add_index: integer, creation_date: integer}'. For check_wallet_balance: 'Returns {total_balance: integer (satoshis), confirmed_balance: integer}'.
Implement error handling with recovery guidance. Catch exceptions and return structured errors: {error: 'payment_failed', reason: 'insufficient_balance', suggestion: 'Check wallet balance with check_wallet_balance() first'}.
Add tool annotations via FastMCP. Mark pay_invoice and create_invoice with destructiveHint=true. Mark read-only tools with readOnlyHint=true. This enables agents to reason about side effects.
Shape API responses to return only agent-relevant fields. Strip internal protobuf metadata, timestamps, and verbose nesting. Return compact JSON: {payment_request, r_hash, expiry_seconds} instead of full protobuf dump.

Score history

Overall score trend

First recorded score · v2 rubric

47/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	47	2026-07-28+	v2