The server provides 17 tools for managing a bitcoind/phoenixd Lightning wallet. Tool names follow clear verb_noun patterns (get-balance, list-channels, create-invoice, pay-invoice). Descriptions are present for most tools and are reasonably specific. However, the server has critical gaps: (1) Two tools (pay-offer, pay-on-chain) lack descriptions entirely, scoring 0 for description. (2) Input schemas are present and use Zod with type annotations, but schema documentation is sparse, parameters like 'from' and 'to' in list-incoming-payments lack min/max bounds, enums where appropriate, and clarity on millisecond epoch format. (3) Output schemas are not documented anywhere, the LLM cannot infer what fields are returned by these tools, preventing downstream composition and chaining. (4) Error handling is absent from tool descriptions; no recovery guidance for failed payments or network errors. (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite multiple irreversible operations (pay-invoice, close-channel, pay-on-chain). (6) Tools like bump-fee and pay-invoice accept financial amounts without explicit validation hints or min/max bounds. Averaging across 17 tools: read-only tools (get-balance, get-node-info, list-channels, decode-invoice, decode-offer, list-incoming-payments, get-incoming-payment, list-outgoing-payments, get-outgoing-payment) score ~65-70 due to adequate naming and descriptions but missing output schemas. Write/irreversible tools score 40-55 due to missing descriptions (pay-offer, pay-on-chain), lack of error guidance, and no confirmation/dry-run patterns. Overall 51 reflects a functional but incomplete foundation.

• Add non-empty descriptions to pay-offer and pay-on-chain. Minimum 50 characters explaining what each does, when to use it, and what risk level applies.
• Document output schemas for all 17 tools. For each tool registration, add a comment or docstring showing the expected return type (e.g., 'Returns {balance_sat: number, pending_msat: number}' for get-balance). Consider creating TypeScript interfaces for each tool's response and documenting them inline.
• Add tool annotations to every tool registration. Example: `server.tool('get-balance', ..., { readOnlyHint: true }, ...)` for reads; `server.tool('pay-invoice', ..., { destructiveHint: true }, ...)` for irreversible ops. Use idempotentHint: true for safe retries (e.g., decode operations).
• Add error recovery guidance to all irreversible financial tools. Example for pay-invoice: 'Pays a bolt11 invoice. Fails if invoice is expired, amount exceeds wallet balance, or channel is closed. If failed, call get-balance to check funds or list-channels to verify channel status before retrying.'
• Replace string-type 'from'/'to' parameters with explicit number types in list-incoming-payments and list-outgoing-payments. Document as: 'Timestamp in milliseconds since Unix epoch (e.g., 1700000000000 for Nov 2023). Default 0 (beginning of time), default to for now in ISO 8601 if human-readable is needed.'
• Add min/max bounds to all numeric parameters. Example: 'feerateSatByte: number (1-1000, recommended 1-50 for typical transactions)'. Use z.number().min(1).max(1000) in Zod.