Three read-only tools with basic Zod schemas and descriptions. Tool names follow verb_noun pattern (get*, list*). Descriptions are present but generic (avg 95 chars, below 194-char baseline). Schemas use Zod enums with descriptions, but output structure is undocumented, responses are JSON strings, not structured objects. No error handling guidance, no pagination despite potentially large result sets, no per-tool risk annotations. Composition is sound (each tool has one responsibility), but parameter descriptions lack detail on constraints and dependencies.

• Document output schema for each tool. Define typed response objects: getRollupSpecs → {chainId, description, opcodes: [{opcode, name, description}], precompiles: [...], systemContracts: [...], blockTime, finality, ...}. Return structured JSON, not stringified text.
• Enhance parameter descriptions with explicit constraints and defaults. E.g., 'execEnv (optional): Execution environment. Defaults to "evm" if rollup has single environment; required if rollup supports multiple (e.g., Arbitrum: evm, wasm).'
• Add error handling with recovery guidance. If rollupName not found, return: {error: 'Rollup not found', available: ['Arbitrum', 'Optimism', ...], suggestion: 'Did you mean Arbitrum?'}
• Document result limits and pagination. Add to listRollups/listExecutionEnvironments descriptions: 'Returns up to 100 rollups. For large datasets, implement offset/limit parameters.'
• Expand tool descriptions to include WHEN to use each. E.g., 'Use listRollups first to discover available rollups and their chainIds. Then call getRollupSpecs to fetch detailed opcodes, precompiles, and system contracts for a specific rollup.'