Loading ToolBench
MCP server for Grafana observability stack — Loki, Grafana, Tempo, Metrics (Prometheus). Intent-based tools for AI agents to investigate latency, errors, and traces.
Five tools with complete input schemas and descriptions, but quality is uneven. All tools follow verb_noun naming (investigate_, find_, trace_, correlate_, summarize_) and have 10 - 1024 char descriptions. However, descriptions lack actionable context about when to use each tool vs. alternatives, and parameter descriptions are minimal. No output schemas documented. Error handling not visible in tool definitions. Tools are read-only (good for safety) but lack guidance on recovery paths or result interpretation.
Given an error ID or error string, find related log entries and the associated distributed trace. Returns matched log lines and a trace summary with error spans.
Find and summarize error logs for a service. Returns error rate, deduplicated error messages with counts, and trace IDs associated with errors.
Investigate a latency spike for a service over a time window. Returns p50/p95/p99 latency, error rate, anomaly detection, and references to the slowest traces.
Get a full health summary for a service: request rate, error rate, latency percentiles, health classification, and top recent errors.
Find slow requests for a service and identify the bottleneck span in each trace. Returns trace IDs, durations, and the single slowest span per trace.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'p50/p95/p99 latency, error rate, anomaly detection') but no formal JSON Schema for response structure. LLMs cannot plan downstream operations or extract fields reliably.
Parameter descriptions are minimal. 'service' is described as 'Service name as labeled in Prometheus/Loki/Tempo' but lacks guidance on format (alphanumeric? dots? hyphens?). 'window_minutes' has range constraints (1 - 10080) but no rationale for the upper bound or typical values.
No tool-to-tool chaining guidance. When investigate_latency_spike detects an anomaly, should the agent call find_errors or trace_slow_requests next? Descriptions do not clarify the intended workflow or when each tool is preferred.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Error handling not visible in tool definitions. No guidance on retryable vs. fatal errors, or recovery steps if a service is not found or query times out. Agents will not know whether to retry, ask the user, or abandon the investigation.
correlate_error_to_trace parameter 'error_id' is overloaded: accepts 'Error ID, error message substring, or trace ID'. No enum or format constraint. LLMs may pass ambiguous values (e.g., a partial message that matches multiple errors) without knowing the precedence or expected format.