Six tools with basic descriptions but significant gaps in schema completeness and parameter documentation. Tool names follow verb_noun convention (mc_test, mc_deploy, mc_upgrade, mc_setup, mc_search_docs_semantic, erc7201_slot), which is good. However, most tools lack detailed parameter descriptions and output schemas are not documented. Only mc_search_docs_semantic and mc_deploy/mc_upgrade have visible parameter schemas with descriptions. Error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Descriptions are adequate (10-100 chars) but lack context on when to use each tool or what they return.

• Add output schema documentation for all tools. Example for mc_test: 'Returns {success: boolean, output: string, exit_code: number, duration_ms: number}'.
• Expand tool descriptions to 80-150 chars with WHEN/WHY context. E.g., mc_deploy: 'Deploy a smart contract to the blockchain using a Forge script. Use broadcast=false for dry-run validation before broadcast=true for actual deployment.'
• Add tool annotations in the MCP handler: mark mc_test, mc_search_docs_semantic, erc7201_slot with readOnlyHint=true; mark mc_deploy, mc_upgrade with destructiveHint=true; mark mc_setup with idempotentHint=true.
• Add error recovery guidance to mc_deploy and mc_upgrade descriptions: 'If deployment fails, check logs and retry with broadcast=false to validate the script.'
• Constrain mc_search_docs_semantic limit parameter: add 'limit must be 1-100 (default 5)' to description and enforce in handler.

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

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