mcp-grafana
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GRAFANA_URL | Yes | The URL of the Grafana instance (e.g. http://localhost:3000). | |
| GRAFANA_MODE | No | Access mode: read-only (default) → read-write → admin. A tool is registered only if the mode allows its capability. Read-only exposes the 11 read tools; edits need read-write; deletes need admin. | read-only |
| GRAFANA_TOKEN | Yes | A Grafana service account token (e.g. glsa_...). Give it the least role that works — Viewer for read-only use, Editor to create/update, Admin only if you must delete. | |
| GRAFANA_DRY_RUN | No | Validate and log writes without executing them. | |
| GRAFANA_AUDIT_LOG | No | A JSON audit line per guarded operation, on stderr (default on). | true |
| GRAFANA_ALLOW_DELETE | No | Deletes are irreversible, so on top of admin mode they also require this flag. | |
| GRAFANA_FOLDER_ALLOWLIST | No | Confine which folders can be written to. | |
| GRAFANA_PROTECTED_FOLDERS | No | Mark folders (e.g. production) that may be read but never modified or deleted. | |
| GRAFANA_DATASOURCE_ALLOWLIST | No | Restrict which datasources query_datasource may hit. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_healthA | Check the Grafana instance is reachable and return its version and database status. |
| searchA | Search dashboards and folders by name/tag. Use this first to find a dashboard's UID before get_dashboard. Returns title, uid, type (dash-db | dash-folder), folder and tags. |
| list_dashboardsB | List dashboards (optionally filtered by tag). Shorthand for search with type=dash-db. |
| get_dashboardA | Return the full dashboard JSON model (panels, targets, templating, time) plus meta (folder, version, url) for a dashboard UID. This is the model you edit and pass back to create_or_update_dashboard. |
| list_foldersA | List dashboard folders with their UIDs and titles. |
| get_folderC | Return a folder's details by UID. |
| list_datasourcesA | List configured datasources (uid, name, type, url). Secrets (secureJsonData, passwords, tokens) are never returned. Use the uid with query_datasource. |
| get_datasourceA | Return a single datasource by UID (secrets redacted). |
| query_datasourceA | Run a query against a datasource through Grafana's unified query API and return the result frames. For Prometheus/Loki set |
| list_alert_rulesA | List Grafana-managed alert rules (via the provisioning API): title, condition, folder, state. |
| list_annotationsB | List annotations (events overlaid on graphs), optionally within a time range or by tag. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Most tools have distinct resource+action purposes (get_health, get_dashboard, get_folder, get_datasource, query_datasource, list_alert_rules, list_annotations). The only real overlap is list_dashboards vs search, but the description explicitly frames list_dashboards as shorthand for search with type=dash-db, which mitigates the ambiguity.
Names follow a clear verb_noun convention (list_*, get_*, query_*), making the pattern predictable. 'search' is the lone deviation without an explicit noun, and 'get_health' is slightly idiosyncratic, but overall consistency is strong.
11 tools is well within the ideal 3-15 range for a Grafana integration. Each tool maps to a concrete resource or operation, and none feel redundant or filler.
Read coverage is broad (dashboards, folders, datasources, alert rules, annotations, health), but the surface is almost entirely read-only. Notably, get_dashboard references passing the model back to 'create_or_update_dashboard,' a tool that does not exist, and there is no create/update/delete for dashboards, folders, annotations, or alert rules — a meaningful lifecycle gap.