This server has 3 tools with moderate quality issues. Tool naming follows verb_noun convention reasonably well (blockchain_events_create, blockchain_events_manage, system_info), and all three tools have descriptions and input schemas. However, parameter descriptions are sparse in several cases, output schemas are completely undocumented, and error handling guidance is absent. The 'blockchain_events_manage' tool combines multiple disparate actions (list, get, delete, activate) into a single tool with an action enum, violating the single-responsibility principle. Parameter names like 'blockchain' and 'network' lack context about valid values. Most critically, there is no documentation of what these tools return, making it impossible for LLMs to plan downstream operations or extract needed fields.

• Document the full output schema for each tool in the source code (src/tools/{create,manage,index}.ts) and reference it in tool registration. Example: 'Returns {referenceId: string, eventType: string, callbackUrl: string, status: string, createdAt: ISO8601}'.
• Split blockchain_events_manage into four separate tools: list_blockchain_subscriptions (action removed, just list), get_blockchain_subscription (action removed, just get), delete_blockchain_subscription, activate_blockchain_subscription. Each tool has a single, clear purpose.
• For blockchain and network parameters, define enums or provide a discovery tool. Add a tool like 'get_supported_blockchains' that returns {blockchains: [{name: 'bitcoin', networks: ['mainnet', 'testnet']}, ...]} so LLMs know valid values.
• Add a full description to confirmationToken explaining it is a security token obtained from a prior confirmation step, its expected format (e.g., 'hex string, 32 chars'), and how it prevents accidental deletion.
• Expand system_info description to 150+ chars: 'Retrieve account metadata including available API credits (in units), supported blockchains and networks, current API usage (requests this period, quota remaining), and rate limit status. Use this to check credit balance before creating subscriptions or to troubleshoot rate limit errors.'
• Add a confirmation mechanism: before executing delete or activate, return a confirmation request with a uniquely generated confirmationToken and require the LLM to call the tool again with that token. Document this in the tool description.

Inferred effective spec: 2026-07-28+.

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