# Grafana MCP Server Comparison

## Overview

[Grafana's MCP server](https://github.com/grafana/mcp-grafana) (3K stars, Go) exposes Grafana dashboards, datasources, alerts, and other monitoring resources as MCP tools. It is a resource-oriented server — tools map directly to Grafana API resources rather than arbitrary operations.

---

## How Grafana MCP works

1. **Resource-oriented tools**: Each tool corresponds to a Grafana resource (dashboard, datasource, alert rule, etc.). Operations are CRUD-style: `list_dashboards`, `get_dashboard`, `search_dashboards`. This is the most consistent tool naming convention of any MCP server.

2. **Per-domain tool files**: Tools are organized into Go files by domain (`dashboards.go`, `datasources.go`, `alerts.go`). Each file registers its tools via a registration function.

3. **Go binary**: Single compiled binary with all tools. Lightweight — no runtime dependencies beyond the Go standard library and Grafana HTTP client.

4. **Auth**: Grafana API key or service account token. Simple token-based auth, similar to our Bearer token approach.

5. **OTel integration**: Some MCP implementations in the Grafana ecosystem use OTel for trace propagation, leveraging Grafana's existing observability infrastructure.

---

## How our system differs

| Aspect            | Grafana MCP                   | Coda MCP Server                 |
| ----------------- | ----------------------------- | ------------------------------- |
| **Language**      | Go                            | TypeScript                      |
| **Domain**        | Monitoring/observability      | Royalties platform              |
| **Tool pattern**  | Resource-oriented CRUD        | Mixed (search, query, mutation) |
| **Execution**     | In-process (HTTP client)      | HTTP proxy to Express API       |
| **Auth**          | API key / service account     | Bearer token forwarded          |
| **Naming**        | `list_X`, `get_X`, `search_X` | Domain-specific names           |
| **Observability** | Grafana-native                | OTel tracing + MCP logging      |

---

## What we are NOT adopting and why

1. **Resource-oriented tool naming**: Our tools are not pure CRUD operations. A `revenue_overview_skill` combines multiple data sources; a `graphql_explore_skill` combines search + type resolution + optional query execution. Resource-oriented naming would fragment these into many small tools.

2. **Go implementation**: Our monorepo is TypeScript. A Go MCP server would be a separate service to deploy and maintain.

---

## What we are adopting

### 1. Consistent tool naming convention

Grafana's `verb_resource` pattern (`list_dashboards`, `get_dashboard`) is the most readable naming convention among MCP servers. Our tools already follow this loosely (`search_accounts`, `get_product`), but skills break the pattern (`revenue_overview_skill`, `account_overview_skill`). The skill naming is intentional — skills are composite operations, not single resources — but the `_skill` suffix convention should be documented as a deliberate divergence.

### 2. OTel semantic conventions for monitoring tools

Grafana's ecosystem uses OTel span attributes that map to their own monitoring infrastructure. Our `mcp.tool.name` and `mcp.tool.call.duration_ms` attributes align with the published OTel semantic conventions for MCP (in the `semantic-conventions-genai` repo). This validates our approach.

---

## References

- [grafana/mcp-grafana](https://github.com/grafana/mcp-grafana) (GitHub)

---

_Comparison conducted 2026-05-10._