danke-mcp defines 6 tools with clear verb-noun naming (danke_register, danke_send, danke_balance, danke_withdraw, danke_profile, danke_leaderboard). All tools have descriptions (avg ~100 chars, within 10-1024 range). Input schemas use Zod with type definitions and descriptions for most parameters. However, two tools (danke_register, danke_balance) have empty input schemas with no parameters documented. Output schemas are not explicitly documented, responses are inferred from code (text content blocks). Error handling returns user-friendly messages but lacks recovery guidance or error classification. Parameter descriptions are present but minimal (avg ~50 chars). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, IRREVERSIBLE, READ_ONLY). Missing pagination for danke_leaderboard despite potentially large result sets.

• Add explicit input schemas to danke_register and danke_balance. Even with no parameters, declare {} as an empty object schema with a description like 'No parameters required.'
• Document output schemas for all tools. For danke_balance, specify: {balance_sats: number, total_received: number, dankes_received: number, total_sent: number, dankes_sent: number}. For danke_profile, specify the profile object structure (username, display_name, user_type, member_since, description, stats). For danke_leaderboard, specify the leaderboard array structure (rank, username, display_name, sats_received, dankes_received).
• Add tool annotations to all tools: danke_register with idempotentHint=true; danke_send and danke_withdraw with destructiveHint=true; danke_balance and danke_profile with readOnlyHint=true. This enables agents to reason about safety and retry logic.
• Enhance error messages with recovery guidance. E.g., 'User not found. Try danke_profile with a different username or pubkey.' For withdrawal failures, suggest 'Check that the Lightning invoice is valid and has not expired.'
• Add pagination to danke_leaderboard: accept offset and limit parameters (default limit=10, max=100), return total_count and next_offset in response. Document that results are capped at 100 per call to prevent context exhaustion.