This server defines 21 tools across blockchain operations (blocks, contracts, ENS, bridges, deployment). Strengths: consistent parameter naming, clear descriptions for most tools, enumerated network choices. Critical weaknesses: NO input schemas visible in the provided source code for ANY tool, making verification impossible; descriptions lack depth about when/why to use tools; missing output schema documentation; error handling and recovery guidance absent; no tool annotations (readOnlyHint, destructiveHint); several high-risk tools (execute_bridge, deploy_contract, write_contract) lack confirmation mechanisms despite irreversible consequences. Per-tool analysis reveals schema gaps dominate the score.
NO input schemas visible in source code. The provided tool definitions show parameter descriptions but no explicit JSON Schema definitions (type, properties, required fields).
NO output schemas documented. The rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' No tool description specifies what fields are returned, types, or structure. This prevents agents from chaining tools and understanding what data is available.
Recommendations
Define explicit JSON Schema input for each tool. Specify types (string, number, array, object), required fields, enum values for network and bridge parameters, min/max lengths for blockHash/blockNumber, and description text that summarizes constraints in human-readable form.
Document output schemas for all 21 tools. Specify what fields are returned (e.g., block_number, timestamp, transactions, gas_used), their types, and relationships. Example for get_block_by_hash: 'Returns: {block_number: number, hash: string, timestamp: number, transactions: string[], miner: string, gas_used: string, gas_limit: string}'.
Implement server-side secret injection for private keys. Remove privateKey from tool parameters. Instead, accept a 'signer_id' or 'account_alias' string, and resolve it to the actual private key stored in environment variables or a vault (e.g., process.env.SIGNER_${signerID}). Document in the tool description: 'Private key is resolved server-side from environment; do not include it in the request.'
Add confirmation/dry-run mechanics for irreversible tools. For execute_bridge, deploy_contract, deploy_create2: (1) Add a 'dry_run' boolean parameter (default true) that returns estimated gas, fees, and potential outcome WITHOUT committing. (2) Add a 'require_confirmation' parameter that, when true, returns a confirmation_token instead of executing, forcing a second call with that token. Document: 'This tool modifies blockchain state irreversibly. Set dry_run=true first to preview consequences.'
Irreversible operations lack confirmation/dry-run support and error guidance. Tools execute_bridge (IRREVERSIBLE), deploy_contract (IRREVERSIBLE), deploy_create2 (IRREVERSIBLE), and write_contract (WRITE) are high-risk. Descriptions do NOT warn agents about consequences or offer confirmation mechanics.
Private key exposure. Multiple tools accept 'privateKey' as a parameter (execute_bridge, write_contract, deploy_contract, deploy_create2). Use server-side secret injection via environment variables or vault. Agent traces log every parameter, secrets in params leak into logs.' This is a critical security vulnerability.
Tool descriptions lack LLM-optimization depth. They lack WHEN to use the tool, WHAT it returns, or dependencies. Descriptions should explain context, not just repeat the name.
No tool annotations. Per current spec (2026-07-28), tools should declare readOnlyHint, destructiveHint, or idempotentHint. This metadata helps agents understand consequences. All 21 tools lack these annotations despite clear risk profiles (7 READ_ONLY, 4 IRREVERSIBLE, 1 WRITE).
Ambiguous parameter dependencies and types. 'read_contract' accepts 'abi' as an array and 'args' as an array, but descriptions don't explain the ABI format (Solidity JSON ABI?), how 'args' maps to function parameters by position/name, or error handling when types mismatch. 'deploy_contract' has 'constructorArgs' without explaining how it correlates with the ABI's constructor. LLMs will struggle.
Missing permission/scope declarations. 'read:email', 'write:calendar'). This enables least-privilege agent configurations and clear audit trails.' No tool states what on-chain permissions or account roles it requires.
Enhance tool descriptions to 100+ characters with LLM-optimized context. Example: 'Get a block by hash' → 'Retrieve a specific block by its hash. Use this to inspect a particular block's transactions, miner, timestamp, and gas usage. Returns block details including all transaction hashes; use get_block_with_transactions for full transaction data.'
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) for MCP 2026-07-28 compliance. Mark all get_* tools with readOnlyHint: true. Mark execute_bridge, deploy_contract, deploy_create2 with destructiveHint: true. Mark idempotent tools (those safe to retry) with idempotentHint: true.
Document parameter constraints explicitly. For network: 'One of: ethereum, bsc, arbitrum, polygon, optimism, base, avalanche, fantom, sepolia, mumbai, amoy, arbitrum-sepolia, optimism-sepolia, base-sepolia.' For amount/value: 'String representation of wei (e.g., "1000000000000000000" for 1 ETH). Must be a positive integer or '0'.' For abi: 'Array of contract ABI objects in Solidity JSON format. Example: [{"type": "function", "name": "transfer", "inputs": [...], "outputs": [...]}].'
Add error recovery guidance. Document common failures and recovery paths. Example for deploy_contract: 'If deployment fails with OutOfGas, increase gasLimit and retry. If fails with InvalidAddress, check bytecode is valid hex (0x...). If fails with InsufficientBalance, fund the account first.'
Implement result limits and pagination. For get_block_range: 'Returns up to 100 blocks. If endBlock - startBlock > 100, only the first 100 are returned; use pagination tokens to fetch subsequent batches.' Return a next_cursor or offset for chaining calls.
Add per-tool scope/permission declarations. Example for write_contract: 'Requires: blockchain:write, account:sign. Only works if the provided account has sufficient gas balance on the target network.' For deploy_contract: 'Requires: blockchain:deploy, account:sign, account:fund.'
Add audit logging guidance. Document that all calls to execute_bridge, write_contract, deploy_contract, deploy_create2 MUST be logged with user ID, timestamp, parameters (excluding privateKey), and result (tx hash, status, error). Store for 90+ days for compliance.
Clarify ABI and constructor argument mapping. Document: 'abi must be a JSON array of function/constructor objects. For write_contract/read_contract, functionName is matched against abi[].name. args must be an array of values in the same order as the function signature's input parameters. Type coercion is NOT automatic; pass numbers as strings if the ABI specifies uint256.'
Add network-specific notes. Document that some networks have different gas limits, confirmation times, or bridge availability. Example: 'bridge tool: Stargate supports ethereum↔arbitrum but not fantom↔polygon. Call get_supported_bridges first to verify route availability.'