This blockchain MCP server has 5 well-defined tools with explicit schemas and descriptions visible in src/mcp/server.ts. Tool naming follows verb-noun conventions (get-chains, get-balance, read-contract, prepare-transaction, get-transaction-status). Descriptions are present and substantive (89-200 chars), explaining not just what the tool does but also prerequisites (e.g., read-contract mentions ETHERSCAN_API_KEY for auto-fetching ABIs). Input schemas are fully typed with parameter descriptions. However, output schemas are not explicitly documented in the code samples provided, we can infer structure from the implementation (e.g., get-chains returns chain objects with id/name/nativeCurrency), but LLMs would benefit from explicit response documentation. Error handling is present but could be more granular: the code shows basic try-catch blocks in http handlers (e.g., markSubmitted catches and returns errors) but lacks structured error categories or recovery guidance. Tool composition is sound: prepare-transaction generates unsigned transaction URLs (keeping private keys client-side), and get-transaction-status tracks prepared transactions, these chain well. One critical security pattern is well-executed: private key custody is preserved via external signing URLs rather than exposing credentials as parameters.

• Document all output schemas explicitly. For each tool, declare the response structure as a JSON Schema or type signature. Example for get-chains: 'Returns { chains: Array<{ id: string, name: string, nativeCurrency: { name: string, symbol: string, decimals: number }, explorerUrl: string, testnet: boolean }> }'.
• Enhance error messages with recovery guidance. When read-contract fails due to invalid ABI, return: 'Invalid ABI: expected a function signature string like "function balanceOf(address) view returns (uint256)" or a JSON ABI array. Call get_contract_abi(address, chainId) first if you don't have the ABI.' This guides LLM retry logic.
• Add numeric constraints to prepare-transaction parameters. In the schema, specify minimum/maximum for gasLimit (e.g., 21000 - 10000000), and clarify the 'value' format: 'Amount of native token in decimal notation (e.g., "0.01" for 0.01 ETH). Must be >= 0.'
• Clarify the 'abi' parameter format in read-contract with a constraint example: Accept one of: (1) A single function signature: 'function balanceOf(address user) view returns (uint256)' (2) An array of signatures: ['function balanceOf(address) view returns (uint256)', 'function allowance(address, address) view returns (uint256)'] (3) A full JSON ABI array. Prefer signature strings for simplicity.
• Add a confirmation tool for high-value transactions. Create a 'confirm-transaction' tool that requires explicit user approval before prepare-transaction signs. This follows the confirmation-request pattern and prevents accidental transfers.

Inferred effective spec: 2026-07-28+.

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