SolPal exposes 17 tools across Solana, node management, and weather domains. Tool naming follows verb_noun convention (get_wallet_balance, create_sol_transfer, search_nodes), which is good. However, critical gaps undermine quality: (1) Parameter descriptions are minimal or absent for complex inputs (e.g., 'filters' object in search_nodes has no guidance on valid keys); (2) Output schemas are completely undocumented, no tool specifies what fields are returned, forcing LLMs to guess; (3) Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors; (4) Several tools combine multiple concerns (edit_person_node, edit_event_node, edit_community_node all use generic 'updates' object with no schema); (5) Destructive operations (create_sol_transfer with execute=true) lack confirmation/dry-run patterns. Descriptions are present but generic (avg ~50 chars, well below the 194-char baseline for A+ tools). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk differences.

• Document output schema for every tool. Specify field names, types, and whether results are paginated. Example: 'Returns {balance: number (lamports), address: string, timestamp: ISO8601}.'
• Replace generic 'updates' object with explicit parameters or a constrained schema. For edit_person_node, list valid fields: name, walletAddress, email, phone, notes. Specify which are mutable.
• Add dry-run support to create_sol_transfer: 'If execute=false, return estimated gas and preview without broadcasting. If execute=true, require explicit confirmation via a separate confirm_transaction tool.'
• Document search_nodes filters parameter with examples: 'filters: {category?: string, minMembers?: number, createdAfter?: ISO8601}'. Use enum or pattern constraints.
• Add tool annotations to all tools. Mark create_* and edit_* with destructiveHint=true. Mark get_* and search_* with readOnlyHint=true. Mark idempotent operations with idempotentHint=true.