Lightdash Analytics
Use the Lightdash MCP server as the source of truth for the user's governed semantic layer.
Discover before querying
- Set the active project if the server requires one.
- Use
route_agentwhen available; otherwise list the available explores. - Inspect the selected explore and fields before composing a metric query.
- Use verified content as a reference when it matches the request.
Never invent explore names, field IDs, metric definitions, filter values, or query UUIDs. Search field values when a string filter must match an existing value.
Answering questions
Prefer run_metric_query for questions that fit the semantic layer. Use run_sql, when it is available, only when the requested analysis cannot be represented through a governed explore.
If a metric query is still running, poll get_query_result with the returned query UUID. When a visual would clarify the result, render a completed metric query with render_chart.
State the metric, time period, filters, and any important caveats in the answer. Treat an empty result as a valid result rather than a failed query.
Creating content and changing analytics
Before creating a chart or dashboard, inspect the relevant schema and existing content. Validate the query first, then use the server's creation workflow.
For dbt or content-as-code changes, work in a branch and use the Lightdash CLI workflow: preview the change, validate it, review it, then merge. Do not deploy or start AI writeback unless the user explicitly asks for that external change.
Built-in Lightdash skills
The MCP server can expose additional Lightdash skills and references. Use list_skills when the client does not surface MCP resources directly, then read only the skill or reference relevant to the task.

