Related Servers

Most tools target a clearly distinct resource or action (list_labels vs list_annotations vs list_silences vs get_dashboard vs run_panel_query), and the descriptions explicitly disambiguate the risky pairs: grafana_query tells you to prefer grafana_query_prometheus/grafana_query_loki, and grafana_list_alert_rules points to grafana_list_alerts for instances. The residual overlaps are grafana_query (generic /api/ds/query) versus the two datasource-specific query tools, and grafana_request acting as a catch-all over nearly everything. Both are framed as escape hatches, which mitigates but does not eliminate the risk of misselection.

There is a single grafana_ prefix and a clear verb_noun cadence: list_* (labels, datasources, alerts, alert_rules, silences, annotations), query_* (prometheus, loki, and bare query), get_dashboard, run_panel_query, search. The deviations are small but real: grafana_search omits its object (search_dashboards would fit the pattern), grafana_auth_status is noun-only with no verb, and grafana_query / grafana_request carry no target noun.

Fourteen tools is squarely in the well-scoped band, and each one earns its place: datasource discovery, label discovery, three query paths (Prometheus, Loki, generic), dashboard read plus panel replay, four alerting-state readers, annotations, auth check, and one read-only HTTP escape hatch. Nothing looks padded, and the escape hatch keeps the surface from ballooning into a tool per API endpoint.

The read-side lifecycle for Grafana investigation is covered end to end: discover datasources and labels, query metrics/logs/arbitrary sources, find and read dashboards, re-run panel queries with variables filled, and inspect alerts, rules, silences and annotations. The gaps are real but workaroundable: the surface is read-only, and grafana_get_dashboard refers to a grafana_save_dashboard tool that is not registered, which is a dangling pointer an agent may chase.