This server has 3 tools with CRITICAL deficiencies across naming, descriptions, and schemas. Tool names lack clarity and don't follow verb_noun patterns consistently. Descriptions are present but generic and under-optimized (10-50 chars for most). Output schemas are completely undocumented, LLMs cannot infer the response structure. No error handling guidance. No parameter descriptions beyond the bare minimum in one tool. The codebase shows DDD architecture but the tool interface is poorly suited for agent consumption.

• Add explicit input schemas to get-recommended-fees and get-ping. Even if they take no parameters, define them as empty objects in the tool registration (e.g., {} or { type: 'object', properties: {} }).
• Expand tool descriptions to 80-150 characters, following the pattern: '[WHAT] Retrieves [RESOURCE/ACTION]. Use when [WHEN]. Returns [KEY FIELDS].' Example: 'Retrieves the recommended transaction fees for Bitcoin network (fast, standard, economy). Use this to estimate fee costs. Returns fees in satoshis per byte.'
• Add parameter descriptions to the get-block hash field: 'The 64-character hexadecimal Bitcoin block hash. Example: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f'
• Document output schemas as JSON Schema in comments or docstrings. Example for get-recommended-fees: '{ fastestFee: number, halfHourFee: number, hourFee: number, economyFee: number, minimumFee: number }'
• Add error handling guidance to descriptions. Example: 'If the hash is invalid, the tool returns an error message. Validate hash format (64 hex chars) before calling. If the Mempool API is unavailable, retry in 5 seconds.'
• Rename get-ping to verify-service-health to be more explicit and verb-driven. Or add it only if it serves a specific agent purpose (e.g., checking service availability before expensive calls).
• Use Zod schema descriptions in the tool registration. Instead of just z.string().length(64), use z.string().length(64).describe('64-character hex block hash. Example: 000000...').