Single tool 'tempo_query' has a complete input schema with 7 parameters, all properly typed and described. However, the tool description is generic (41 chars) and lacks context on when/why to use it. No output schema is documented, LLMs cannot predict what fields to expect from Tempo responses. Parameter descriptions are adequate but lack format constraints (e.g., what constitutes a valid Tempo query string, time format examples). No error handling guidance provided. The tool accepts credentials as parameters (username, password, token), violating secret-injection patterns. Overall definition is functional but incomplete for production LLM integration.

• Move username, password, and token to server-side environment variables (TEMPO_USERNAME, TEMPO_PASSWORD, TEMPO_TOKEN). Accept only the URL as a parameter, or omit it if using a default.
• Expand tool description to 100-150 chars: 'Query Grafana Tempo for distributed traces. Use this to search traces by service, duration, or span attributes. Returns trace IDs and metadata. Requires Tempo server URL and optional authentication.'
• Document the output schema explicitly: 'Returns an object with fields: traces (array of trace objects), total_count (number), next_cursor (string for pagination). Each trace contains: trace_id, service_name, duration_ms, span_count, start_time.'
• Add format constraints to parameter descriptions: 'start' and 'end' should specify 'ISO 8601 format (e.g., 2024-01-15T10:30:00Z) or relative time (e.g., -1h, -30m, now)'. 'query' should reference Tempo query syntax or link to docs.
• Add error handling guidance: 'If Tempo is unreachable, verify TEMPO_URL and network connectivity. If auth fails, check username/password. If query is invalid, review Tempo query syntax at [docs link].'

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

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