Skip to content
DataHashi Docs
Console

Use with an LLM agent (MCP)

datahashi exposes the same semantic layer to LLM agents over MCP (Streamable HTTP / JSON-RPC), so an agent grounds itself in your actual model — real metric and dimension names — instead of guessing at your schema or writing SQL against your warehouse.

This is a deliberate design choice, not a convenience wrapper: an agent that emits a structured Semantic Query is validated against your model before it ever compiles to SQL — an invalid metric, an unreachable join, or a non-additive measure used somewhere it can’t be is rejected the same way it would be for any other caller. Text-to-SQL isn’t on the table here; the agent never sees or writes SQL.

Agent query flow over MCP An LLM agent calls MCP tools such as list_catalog and run_semantic_query. The request is validated and compiled against your model before it reaches the warehouse. A direct raw-SQL path from the agent to the warehouse is blocked. LLM agent MCP tools list_catalog run_semantic_query +3 more tools Validate & compile against your model Warehouse ✕ No raw SQL — every query is validated against your model first
The agent never sees SQL — it selects names from your catalog, and the compiler is the only thing that queries the warehouse.

Connect

Section titled “Connect”

Point an MCP client at:

https://engine.datahashi.com/mcp

using the same bearer token you’d use for REST:

Authorization: Bearer <your-api-key>

It’s the same gateway, the same auth, and the same identity binding as /v1/query — your workspace and mode (governed or explore) come from the token, not from anything the agent sends. An agent holding a governed key can never ask for raw measures, no matter how it phrases the request.

Tools

Section titled “Tools”
ToolREST equivalentWhat it does
list_modelsGET /v1/modelsList your workspace’s semantic model names.
list_catalogGET /v1/catalogOne model’s metrics, dimensions, curated views, and (explore mode) raw measures.
describe_metricGET /v1/describeLook up one metric, dimension, or measure by name — including which dimensions are reachable from it.
run_semantic_queryPOST /v1/queryRun a Semantic Query and get columns + rows back.
drill_downPOST /v1/drill-downExpand one aggregated result cell into its underlying raw rows.

The intended loop for an agent: call list_catalog (and describe_metric for reachable dimensions on a specific metric) to ground itself in what exists, then call run_semantic_query with names it actually saw — never a guessed name. describe_metric also reports which dimensions are legally combinable with a given metric, so an agent can avoid a doomed query instead of learning the hard way from a 400.

Why not text-to-SQL

Section titled “Why not text-to-SQL”

An agent that writes raw SQL against your warehouse can hallucinate joins, invent columns, or reach data it shouldn’t. Emitting a Semantic Query instead means every agent request is validated against your published model and your row-level security and cost policy — the identical guarantees every other consumer of datahashi already gets. There is no separate, looser “LLM path.”