| name | grafana |
| description | Queries Grafana dashboards, alerts, and Explore using connected datasources. Use when investigating metrics, firing alerts, building panels, or exploring logs/traces in Grafana. |
Grafana
Purpose
Operate a connected Grafana instance: find dashboards and alert rules, run metric/log queries, interpret panels, and make focused dashboard or alert changes with verified tool output.
When to Use
- User asks about Grafana dashboards, panels, datasources, or Explore queries.
- Investigating firing alerts, silences, or on-call context in Grafana.
- Adding or updating panels, variables, or alert rules when Grafana MCP tools are available.
- Correlating metrics/logs during incidents (with lead-incidents or monitor-slos as needed).
When NOT to Use
- Datadog, CloudWatch, or other vendors without a Grafana connection → use datadog, cloudwatch, or the vendor skill.
- Designing SLOs or error-budget policy → error-budget-management, monitor-slos.
- Authoring skills in this repo → create-skill / publish-skill.
Expected Outcome
- Queries and resource lookups backed by real tool responses (UIDs, links, sample values).
- Clear incident or investigation summary with time range and datasource noted.
- Explicit blockers when credentials, datasource, or permissions are missing.
Inputs to Gather
- Grafana base URL or org context if multiple instances exist.
- Time range (
from/to or relative) and timezone for incidents.
- Dashboard UID/title, alert rule name/UID, folder, or datasource name.
- Service, namespace, or label selectors relevant to the question.
Workflow
- Confirm Grafana MCP tools are available; read tool schemas before calling.
- Set or confirm the evaluation time window.
- List or search dashboards/alerts when IDs are unknown; then get details.
- Run queries in the correct language (PromQL, LogQL, etc.) for the datasource—do not invent metric names.
- For changes, prefer preview or non-destructive reads; confirm destructive edits with the user.
- Summarize findings with UIDs/links and suggested next steps.
Domain guidance
- Time range first — relative windows (
now-1h) or absolute UTC for incidents.
- Resource identity — dashboard UID, alert rule UID, folder, datasource; search before guess.
- Query language — match datasource type (Prometheus/Mimir → PromQL, Loki → LogQL).
- Alerts vs dashboards — for pages, check alert state, labels, silences, and notification policy before editing panels.
- Tool fidelity — use only tools exposed by the integration; never fabricate panel JSON or query results.
Typical tasks
| Task | Approach |
|---|
| Firing alert | Rule status → labels → backing query for window → threshold comparison |
| Dashboard change | Get dashboard → confirm datasource/variables → add/update panel → return link |
| Explore investigation | Pick datasource → run query → narrow labels/time → export key series or log lines |
Examples
User: "Why is api-latency-p99 alerting?"
→ Locate rule, note state/labels, run backing query for alert window, compare to threshold, list top label contributors.
User: "Add a 5xx rate panel to the payments dashboard."
→ Resolve dashboard UID, confirm datasource and labels, add panel with validated query, return dashboard URL/UID.
Tool Availability Rules
| Access | Behavior |
|---|
| Full tool access | Execute workflows, verify outputs, report errors. |
| Read-only | Inspect dashboards/alerts/queries; provide exact steps or dispatch for writes. |
| No integration | State limitation; do not fabricate query results or panel data. |
Related tool sets
Review / Decision / Execution Criteria
- Prefer read-only investigation before mutating dashboards or alert rules.
- Cite dashboard UID, rule name, datasource, and time range in conclusions.
- Confirm alert silences and notification changes with the user.
Output Format
- Request and time range evaluated.
- Key metrics/log findings (table or bullets) with datasource and query noted.
- Resource links/UIDs and alert state if relevant.
- Errors, blockers, or missing permissions.
- Suggested next steps.
Quality Bar
- Grounded in tool output; distinguish observation from hypothesis.
- Actionable for on-call (what to check next, not generic advice).
- Respect pagination and rate limits on list/search calls.
Safety and Boundaries
- Do not expose secrets, tokens, or PII from queries or annotations.
- Do not fabricate alert firings, query results, or successful writes.
- Confirm production dashboard/alert changes and silences when impact is broad.
Escalation / Dispatch Rules
- Cross-vendor observability → suggest datadog or cloudwatch when data lives outside Grafana.
- SLO/error-budget decisions → error-budget-management or monitor-slos.
- Incident coordination → lead-incidents, postmortem-authoring after mitigation.
References
skills/old_skills.json (grafana) — legacy catalog (Sheets boilerplate removed).skills/skill.instruction.md, skills/meta.instructions.md
