Loading ToolBench
MCP server for LNbits API integration with dynamic OpenAPI-based tool discovery for Lightning Network wallet operations
Server has 6 tools with explicit schemas and descriptions. Naming follows verb_noun convention (configure_, test_, get_, refresh_, list_, pay_). However, descriptions are inconsistent in depth and actionability. configure_lnbits has a detailed schema with 7 parameters, all typed and described. pay_lightning_address includes validation (regex pattern, minimum). But several tools (test_connection, get_configuration, refresh_tools, list_extensions) have minimal schemas (empty properties) and lack output schema documentation. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, IRREVERSIBLE). Error handling and recovery guidance are absent from descriptions. Parameter descriptions are present but generic, e.g., 'API key for LNbits authentication' lacks format/length constraints. No documented output schemas for any tool, forcing LLMs to guess response structure.
Configure LNbits connection parameters at runtime.
Show current LNbits configuration with masked API keys.
Show all discovered extensions and their tool counts.
Send sats to a Lightning address ([email protected]). Resolves the address via LNURL-pay, fetches an invoice, and pays it. Amount is in sats, NOT msats.
Re-fetch the OpenAPI spec from LNbits and rebuild the tool list. Use after enabling/disabling extensions.
Test the current LNbits connection by making a test API call.
Four tools (test_connection, get_configuration, refresh_tools, list_extensions) have empty input schemas with no properties defined. These tools lack output schema documentation entirely, leaving LLMs unable to plan downstream calls or extract structured data.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels in metadata (READ_ONLY, WRITE, IRREVERSIBLE). pay_lightning_address is marked IRREVERSIBLE but lacks confirmation/dry-run pattern. configure_lnbits modifies state (WRITE) but has no destructiveHint annotation.
Parameter descriptions lack actionable constraints. 'API key for LNbits authentication' does not specify format, length, or encoding. 'Bearer token for authentication' does not explain when to use it vs api_key.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
No error handling or recovery guidance in any tool description. pay_lightning_address could fail due to invalid address, insufficient balance, or network issues, but descriptions provide no guidance on what to do next. Missing pattern:recovery-guide.
configure_lnbits accepts multiple auth methods (api_key_header, api_key_query, http_bearer, oauth2) but does not document which is preferred, when to use each, or how they interact.