AgentWatch provides 13 tools with consistent naming (verb_noun pattern) and complete Zod schemas. All tools have descriptions and input parameters are typed. However, descriptions are brief (avg 80 chars, below the 194-char baseline), lack WHEN-to-use guidance, and output schemas are not documented. Error handling is minimal, tools return JSON without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Parameter descriptions are sparse; many lack format/constraint details. The server follows basic patterns but lacks LLM-optimization depth.

• Document output schemas for all tools. For agentwatch_get_trace, specify: returns array of {id: int, trace_id: string, agent: string, action: string, status: 'ok'|'error', timestamp: ISO8601, ...}. This enables LLMs to chain results to downstream tools.
• Expand descriptions to 100-200 chars with WHEN-to-use guidance. E.g., 'Find the root cause chain for a failure event by walking parent links. Use this after agentwatch_get_failures to understand why a specific event failed. Returns chain of events from failure back to origin.'
• Add tool annotations via MCP: mark agentwatch_report_heartbeat, agentwatch_trace, agentwatch_alert, agentwatch_resolve_alert with destructiveHint=true; mark read-only tools with readOnlyHint=true. This enables clients to apply safety policies.
• Enhance error messages with recovery guidance. E.g., 'No events found for trace abc123. Try agentwatch_get_failures to list recent failures and their trace IDs, then retry with a valid trace_id.'
• Add format constraints to parameter descriptions. E.g., 'context: JSON string (max 1KB) with keys like memory_usage, cpu_percent, error_count. Example: {"memory_usage": 512, "cpu_percent": 45}', but use enum/pattern in schema, not example values in description.