Both tools have minimal descriptions (under 100 chars) and critically, input schemas are loaded from external JSON files (docs-ai-schema.json, idf-ops-schema.json) that are NOT visible in the provided source code. Per hard scoring rules, when schemas cannot be verified in source, schema score must be 0. Tool names lack action verbs (esp_docs_ai, idf_operations are vague). No parameter descriptions visible. No output schema documentation. Error handling is basic (isError flag only, no recovery guidance). Security concern: idf_operations is a WRITE tool with no permission checks or dry-run capability.

• Rename tools with clear action verbs: 'query_esp_docs' (or 'search_esp_documentation'), 'execute_idf_operation' or split into 'build_idf_project', 'flash_idf_firmware', 'monitor_idf_device'.
• Inline parameter schemas into McpTools.java or provide them in source comments so they can be verified. Include type, description, enum constraints, and min/max for all parameters.
• Add per-parameter descriptions explaining format, valid values, and dependencies. E.g., 'operation: One of [build, flash, monitor]. build compiles the project; flash writes to device (DESTRUCTIVE); monitor opens serial console.'
• Implement confirmation step for idf_operations: add a 'dry_run' parameter or require explicit 'confirm=true' before executing flash/build. Return what would happen without doing it.
• Enhance error responses with recovery guidance: 'API_KEY not set. Set environment variable API_KEY=<your-kapa-key>.' or 'IDF project not found at /path/to/project. Ensure ESP-IDF is initialized.'