Loading ToolBench
Python Grafana FastMCP server/CLI with SSE, Streamable HTTP and STDIO transports. Provides access to Grafana instance and surrounding ecosystem including dashboards, datasources, Prometheus, Loki, incidents, OnCall, alerting, Sift investigations, Pyroscope, and admin capabilities.
This FastMCP server exposes 21 Grafana tools with moderate-quality definitions. Tool names follow verb_noun patterns (search_dashboards, get_dashboard, create_dashboard, etc.), which is good. However, most input parameters lack detailed descriptions or type information beyond basic type declarations. Parameter descriptions are often single generic phrases like 'Dashboard UID' or 'Search query string' without explaining constraints, expected formats, or when to use each tool vs. alternatives. No output schemas are documented in the visible code, critical for LLM chaining. Error handling appears absent; no recovery guidance is visible. Security-sensitive tools like create_dashboard and update_incident accept raw object parameters without schema validation or field documentation. Many tools return Grafana API responses directly without apparent filtering for token count or irrelevant metadata. Tool descriptions are terse (15-40 chars), missing WHEN-to-use context and dependencies (e.g., 'Call list_datasources first if you need to pick one'). The server is production-deployable via Docker/HTTP, but tool definitions themselves are below the bar for confident LLM usage.
Create a new dashboard
Create a new incident in Grafana Incident
Generate a deeplink URL for Grafana resources
Get details of a specific alert rule
Retrieve a dashboard by UID
Get details of a specific datasource
Get details of an on-call schedule
List alert rules in Grafana
Output schemas not documented. No visible return type specifications for any of the 21 tools, making it impossible for LLMs to plan downstream tool chaining or extract the correct fields from responses.
Parameter descriptions are minimal (12-25 chars). E.g., 'Dashboard UID' does not explain what a UID is, its format, how to obtain it, or whether a numeric ID also works.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 60 | - | v1 |
List notification contact points
List all datasources in Grafana
List on-call schedules in Grafana OnCall
List teams in Grafana
Execute a LogQL query against Loki
Execute a PromQL query against Prometheus
Query profiling data from Grafana Pyroscope
Resolve an incident
Search for dashboards in Grafana
Search for incidents in Grafana Incident
Start a Sift investigation in Grafana ML
Update an existing dashboard
Update an existing incident
Dashboard and incident mutation tools (update_dashboard, create_dashboard, create_incident, update_incident) accept 'object' type parameters with no schema or field documentation. LLMs cannot construct valid payloads without knowing required/optional fields, types, and constraints.
No error handling documentation. Tools do not indicate which errors are retryable, which require user intervention, or how LLMs should recover (e.g., 'UID not found, try search_dashboards first').
Tool descriptions are terse (15-40 chars) and lack WHEN-to-use context. E.g., 'Search for dashboards in Grafana' does not say when to call this vs get_dashboard, what query syntax is supported, or whether it searches titles, tags, or both.
No tool annotations for destructive operations. create_dashboard, update_dashboard, create_incident, update_incident, resolve_incident, and start_sift_investigation lack risk markers (destructiveHint) to signal to LLMs that these modify state and may require confirmation.
No result pagination or limits documented. list_datasources, list_alert_rules, list_contact_points, list_oncall_schedules, and list_teams do not specify max result counts or pagination support, risking context window exhaustion if thousands of items exist.
No documented dependencies or tool discovery hints. E.g., update_dashboard and create_dashboard do not hint that LLMs should call search_dashboards or list_datasources first if they lack UIDs.