Coroot MCP demonstrates solid definition quality with all 13 tools properly named with action verbs (get_, investigate_), clear descriptions explaining purpose and context, and complete JSON Schema input definitions with type constraints and parameter descriptions. Tools are read-only and composable. However, descriptions could be more LLM-optimized (some exceed 200 chars), output schemas are not documented in the provided code, and error handling patterns are not visible. Tool names are well-chosen but some parameters lack granular detail (e.g., 'query' parameters in logs/traces tools lack format guidance). No tool annotations (readOnlyHint, etc.) are present. The avg tool name length is 22 chars (within baseline p10=10, p90=27), and descriptions average 168 chars (within acceptable range). All tools have descriptions, and all required parameters are present. Schema completeness is high, every tool exposes its input schema explicitly with property types and descriptions.

• Document the output schema for each tool. Include a 'Returns' section in the tool definition specifying the structure of the response object, field types, and key fields that downstream tools may need (e.g., applicationId, incidentId, etc.). This should be visible in the tool definition, not buried in implementation.
• Add tool annotations to all tools. Use readOnlyHint=true for all 13 read-only tools to signal safety to agents. This follows MCP 2026-07-28 spec and helps agents reason about composition and retry safety.
• Clarify query syntax for get_logs_overview and get_traces_overview. Document the query language (e.g., 'Coroot query syntax: support field=value, AND/OR operators, regex patterns'). Provide 1 - 2 example valid queries in a separate examples field (not in the description itself, to avoid LLM literal reuse).
• Define expected error codes and recovery guidance. Document that invalid projectId returns a 400 with a suggestion to list projects, that missing incidentId returns 404 with a hint to call get_incident_* first, etc. Implement per-error recovery guidance following the recovery-guide pattern.
• Cap and paginate overview responses. For tools returning many items (get_applications_overview, get_nodes_overview, etc.), add limit and offset parameters and document default/max values (e.g., 'Returns up to 50 items by default; use offset for pagination'). Document the total_count in the response schema so agents know when to paginate.
• Include cross-linking IDs in responses. Ensure that get_applications_overview returns applicationId values that feed directly into get_application_logs or get_service_health. Avoid forcing agents to do extra lookups by breaking the tool chain.