The server exposes 15 tools via FastMCP with visible input schemas and descriptions. However, critical gaps limit production readiness: (1) Tool descriptions are minimal (10-25 chars on average), well below the 50-200 char baseline for LLM optimization. Example: 'Fetch the height(block id) of the latest(best) block in the requested blockchain.' is only 79 chars and lacks clarity on WHEN to use vs similar tools. (2) Parameter descriptions exist but are often generic or assume domain knowledge (e.g., 'blockchain to fetch from' doesn't specify the format 'lowercase with dashes'). (3) No output schema documentation visible, tools fetch from external APIs but no explicit return type documentation is provided, forcing LLMs to guess response structure. (4) Error handling is not evident in the code, no recovery guidance, no categorization of retry-ability. (5) The aggregate_* tools accept free-form SQL queries, which is a security/injection risk not addressed. (6) No evidence of pagination defaults, limits, or structured result capping despite querying large datasets. Tools are individually sound (naming follows verb_noun, parameters are typed), but lack the polish and LLM-optimized documentation that characterizes A-grade tools.

• Expand tool descriptions to 50-150 chars with explicit WHEN/WHY guidance. E.g. 'Get the current height of a blockchain. Use this to fetch the latest block data or plan relative block queries. Faster than get_block_overview which fetches full block details.'
• Add format constraints to parameter descriptions: 'blockchain: Lowercase name with dashes (e.g., ethereum, bitcoin-cash, arbitrum-one). Call list_blockchains_and_modules to see valid options.'
• Document output schemas for all tools. At minimum, specify: 'Returns a JSON object with fields: data (object), library (object), context (removed for brevity).'
• Wrap SQL parameter in aggregate_* tools with input validation. Reject queries not starting with SELECT, containing DROP/DELETE/INSERT, or exceeding 500 chars. Return clear error: 'Only SELECT queries supported. Your query: [truncated]'
• Add error handling with recovery guidance. E.g., 'If blockchain not found, try calling list_blockchains_and_modules to verify the name.' Implement try-catch in tool bodies.
• Add pagination to list_blockchains_and_modules and aggregate_* tools. E.g., add limit (default 50, max 1000) and offset parameters. Document result count in response.
• Create an enum constraint for 'blockchain' parameter across all tools. Either include it in schema or add to parameter description: 'One of: ethereum, bitcoin, arbitrum-one, [see list_blockchains_and_modules]'
• Add documentation on which tools are read-only (all of them appear to be) in tool descriptions. E.g., 'Read-only. Fetches data without side effects.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry