Server has 8 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly adequate) and input schemas with type definitions. However, parameter descriptions are sparse or missing context. Output schemas are undocumented, LLMs cannot predict what fields to expect from responses. Error handling is absent from tool definitions. Tool naming follows verb_noun convention (execute_query, get_schema) but lacks specificity in some cases (detect_anomalies, profile_data). No tool annotations (readOnlyHint, destructiveHint) despite all being read-only. Parameter constraints (e.g., method enum for detect_anomalies) are present but not consistently applied. Missing: pagination guidance, output field documentation, error recovery hints, and composition guidance.

• Document output schemas for all tools. Example: execute_query returns {rows: [{col1: string, col2: number, ...}], row_count: integer, execution_time_ms: integer}. Include field types and whether fields are always present.
• Add range/enum constraints to parameter descriptions. E.g., 'limit: Maximum rows to return (1-10000, default 100)' and 'method: Anomaly detection algorithm. Use zscore for normally-distributed data, iqr for skewed data, isolation_forest for multivariate outliers.'
• Add readOnlyHint: true to all tool schemas since all are read-only. This signals to agents that these tools are safe to call speculatively.
• Include error recovery hints in descriptions. E.g., execute_query: 'If query times out (>30s), try reducing limit or adding WHERE clauses. If syntax error, call validate_query first.'
• Document pagination behavior: 'Results capped at server max_rows (see db://status resource). For large datasets, use WHERE clauses or call multiple times with different filters.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry