Four tools with basic verb-noun naming (lookup_*, trace_*, run_query). All have descriptions (10-150 chars, within baseline range). Input schemas present with type and description for each parameter. However, critical gaps: no output schemas documented anywhere; descriptions lack WHEN/WHY context and dependency hints; no error handling guidance; no pagination for list-like operations; no parameter constraints (enums, ranges); descriptions are minimal (avg ~80 chars vs baseline 194). Tools appear to be read-only (good for safety) but lack idempotency/retry guidance. No tool annotations (readOnlyHint present in metadata but not in schema). Schema quality is basic, parameters are typed but lack format/pattern/enum constraints. Overall: functional but well below production baseline.

• Document output schema for each tool. E.g., lookup_domain should return {domain_name: string, description: string, metrics: [{name: string, value: number}], ...}. Include field types and whether arrays are paginated.
• Expand descriptions to 150-250 chars. Add WHEN/WHY: 'Call this to retrieve domain metadata and associated metrics. Use before trace_metric_impacts to understand domain scope. Returns domain description and up to 50 metrics; use pagination for larger result sets.'
• Add enum constraint to trace_metric_impacts.direction: {type: 'string', enum: ['upstream', 'downstream'], description: 'Direction to trace: upstream for drivers or downstream for dependents'}.
• For run_query, add input validation: document max query length, timeout (e.g., 30s), result row limit (e.g., 10,000), and SQL injection prevention. Return error: 'Query timeout after 30s. Try adding LIMIT clause or narrowing date range.'
• Add error handling guidance to all tools. E.g., lookup_metric: 'If metric not found, returns {error: 'Metric not found', available_metrics: [...]}. Try search_metrics() with partial name.'