SRE

Connect Grafana with a URL and a service-account token.

The tools are Grafana's own MCP server, not a reimplementation of the Grafana API.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

Connecting takes a Grafana instance URL and one of three credentials: a service-account token, which is the recommended path and the one the agent's tools require; basic auth with a username and password; or OIDC, where you supply an issuer and a public PKCE client id and sign in through your browser. Lucid Train then downloads Grafana's own official mcp-grafana binary from Grafana's GitHub releases and registers it as a local stdio MCP server, passing the instance URL and credential to it as environment variables. Credentials are stored in the OS keychain.

The token is the one that matters

Create it under Administration, then Service accounts, then Add token. It arrives with a glsa_ prefix. This is the credential the agent's tools actually authenticate with, so it is the one to set up first even if you also want browser sign-in for the dashboard panel.

The OIDC footgun, stated rather than hidden

If you choose OIDC, browser sign-in authenticates the dashboard panel and the Grafana API calls the app makes on your behalf. It does not authenticate the agent's MCP tools, which still need a service-account token supplied alongside it. That is two credentials for one connection, and it surprises people, so the connect card says so at the point of entry rather than failing later with a confusing error.

Grafana's server, not ours

The tools come from mcp-grafana, which Grafana publishes and maintains. Lucid Train fetches the current release and runs it as a child process over stdio. The practical consequence is that the tool surface is whatever that release exposes, so it tracks Grafana's own roadmap rather than ours, and an upstream addition arrives without an update here.

Where the credential lives

Credentials go into the operating system keychain through the connect card, never into the chat transcript and never into the browser layer of the app. The agent is explicitly instructed to refuse a token pasted into conversation and to point at the connect card instead, because a credential in a transcript is a credential in every future context window.

Not a telemetry destination

One thing to be clear about, since it is the assumption people arrive with: this is not a telemetry destination. You do not point an OTLP exporter at Lucid Train and you do not send it traces. It connects to the Grafana you already run and reads through it. Your data stays where it is, and if you have no Grafana there is nothing here to connect to.

The three connection modes

ModeWhat you supplyAgent tools work
TokenService-account token (glsa_…)Yes
BasicUsername and passwordYes
OIDCIssuer, PKCE client id, and a tokenOnly with the token
FAQ

Questions

Can I connect Prometheus or Loki directly?

No. They are reached as datasources through a connected Grafana instance. There is no standalone connector for either.

Do I need both OIDC and a token?

If you use OIDC, yes. Browser sign-in covers the dashboard panel; the agent's MCP tools authenticate with a service-account token regardless.

Where is my token stored?

In the OS keychain. It never enters the chat transcript, and the agent is instructed to refuse one pasted into conversation.

Do I send you my metrics?

No. Nothing is exported to Lucid Train. It reads from your Grafana instance using your credential, on your machine.

Can I use my Grafana Cloud OTLP or access-policy token?

No, and this is the most common setup failure. An access-policy token starting glc_ authorises telemetry ingestion only. It returns 401 against the dashboard API, which is the API used to list and render dashboards and the one the agent's tools call. You need a service-account token starting glsa_ instead. The connect dialog says so at the point of entry and the error message names the distinction, because pasting the wrong one looks like a broken integration rather than a wrong credential.

So what is OTLP for here?

Nothing, on your side. OTLP appears in the app only to tell you which token not to paste. Lucid Train does not ingest OpenTelemetry data and is not an observability backend; it reads from the Grafana that already holds yours.

Related

Last updated