The server provides 4 tools for Prometheus querying with generally clear naming and basic parameter descriptions. However, several critical issues limit quality: (1) descriptions are in Chinese, making LLM processing unreliable; (2) output schemas are completely undocumented, callers have no idea what fields to expect; (3) parameter descriptions lack format constraints and examples; (4) no error handling guidance is provided; (5) tool descriptions lack depth about WHEN to use each tool vs alternatives. The naming convention (prometheus_query, prometheus_range_query, etc.) follows verb_noun pattern appropriately, but parameter names like 'query_time' and 'match' could be more explicit about expected format. Parameters are typed but lack concrete constraints (e.g., RFC3339 format for time parameters is mentioned in descriptions but not as schema constraints). All tools are read-only, so no destructive operation risks, but the absence of any schema documentation for response structure is a major gap.

• Translate all tool descriptions and parameter descriptions to English. Use clear, imperative language: 'Execute a Prometheus instant query' instead of '执行 Prometheus 即时查询'.
• Document the response schema for each tool. Example: 'prometheus_query returns: {status: string (success|error), data: {resultType: string, result: array}, warnings?: array}'.
• Add JSON Schema constraints to time/duration parameters: use pattern '^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$' for RFC3339 or a regex for Unix timestamps. Specify which format is preferred.
• Implement error wrapping: catch Prometheus API errors and return: '{success: false, error: {code: string, message: string, suggestion: string}}'. Example suggestion: 'Invalid PromQL syntax. Check query for typos or missing operators.'
• Add descriptions clarifying when to use each tool: 'prometheus_query: for instant snapshots (e.g., current CPU usage). Use prometheus_range_query for time-series trending. Use prometheus_series to list available metrics.'
• Add optional 'description' field to prometheus_query_label_values explaining the metric context. E.g., if matching on 'pulsar_lb_cpu_usage', explain what that metric measures.
• Consider adding a 'validate_query' tool that checks PromQL syntax without executing it, allowing agents to self-correct before running expensive range queries.
• Document pagination/result limits: state maximum number of results returned by each tool (e.g., 'Returns up to 1000 series'). Add optional limit parameter if not already present.

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

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