Five tools with complete schemas and descriptions, but descriptions are generic and lack LLM-optimized guidance. All tools are read-only with clear naming (verb_noun pattern). Parameters have types and descriptions, but lack constraints (enums, ranges, format specs). Output schemas are not documented. Error handling is minimal, responses use generic {'ok': True/False} pattern without recovery guidance. No tool annotations (readOnlyHint, etc.). Composition is sound: tools chain well (metric_name flows through multiple tools), but descriptions don't explain when to call each tool vs. alternatives.

• Document output schemas for each tool. E.g., 'Returns {"ok": bool, "definitions": [{"name": str, "formula": str, "owner": str}]}' for get_metric_definition. This enables LLMs to plan multi-step workflows.
• Expand descriptions to 100-150 chars with WHEN guidance. E.g., 'Compare two cohorts (current vs. baseline) with statistical significance. Call after get_metric_definition to understand metric structure. Returns p-value, effect size, and per-group breakdowns.'
• Add parameter constraints in descriptions. E.g., 'row_limit: Maximum rows to return (1-500, default 200). Larger limits may timeout.' and 'z_threshold: Z-score threshold for significance (0.5-3.0, default 1.96 for 95% CI).'
• Implement structured error responses with recovery hints. E.g., '{"ok": false, "error": "QueryRejected: table 'events' not in allowlist", "retryable": false, "hint": "Use query_metrics with allowlisted tables: events, users, sessions. Call get_metric_definition first to see available metrics."}'
• Add tool annotations via FastMCP. Mark all tools with readOnlyHint=true since they are read-only. This signals to MCP clients that tools are safe for autonomous execution.