Claude + MCP: certified metrics only

Claude is useful when it can ask for numbers. It is dangerous when it invents the SQL that produces them. The fix is not a longer system prompt. It is a tool surface that cannot express free-form SQL at all.

datahashi exposes metrics over MCP so Claude (or any MCP client) can list certified metrics, inspect their definitions, and run structured semantic queries. Humans in the console and agents on MCP use the same request shape. Neither path accepts client SQL.

What Claude gets

Point Claude Desktop (or your Claude API agent) at the datahashi MCP server with an OAuth sign-in. The agent receives six tools:

• list_catalog - names and short descriptions of metrics, dimensions, and curated views the credential can see
• describe_metric - definition, unit, grain expectations, and allowed dimensions for one or more metrics
• run_semantic_query - a structured request: metric names, dimensions, filters, order, limit
• drill_down - one aggregated cell, broken into finer rows
• refine_semantic_query - a change to the previous query, then the same governed run
• list_dimension_values - distinct values for one dimension

None of those tools accept or return SQL. There is no query_warehouse escape hatch. If a metric is not in the catalog for that credential, Claude cannot ask for it by inventing a table name.

Configure the safe default

1. Publish a semantic model as an immutable artifact (YAML authored, validated, then published with its access rules).
2. Grant the agent a role that exposes named metrics and the dimensions they need, not raw measures, unless you explicitly want that analysis.
3. Connect Claude over MCP with OAuth. Prefer short-lived tokens over a pasted long-lived warehouse key.
4. In the agent instructions, tell Claude to answer metric questions only via those six tools, and to refuse when the catalog has no match.

The instruction layer is hygiene. The hard guarantee is the tool schema: Claude cannot widen a governed credential by asking nicely.

A typical turn

User: “What was average order value by region last quarter?”

Claude calls list_catalog, finds avg_order_value and Customer.region, optionally calls describe_metric to confirm filters and unit, then calls run_semantic_query with metrics, dimensions, a time grain on the order date, and any required filters. datahashi compiles fan-out-safe SQL inside your warehouse. Claude sees rows and labels - not the SQL text, not a path around row-level rules.

If the user asks for something outside the model (“join these two raw tables and guess margin”), the tools have nothing to offer. Claude should say so instead of improvising.

Why this beats “SQL tool + careful prompt”

A generic SQL MCP tool plus a prompt that says “be careful” still lets the model hallucinate joins, skip refund filters, or read rows a policy was meant to hide. Governance as a post-filter on agent-written SQL fails the moment the agent writes creative SQL.

With datahashi, governance is the request shape. Field grants, row-level rules, and cost ceilings apply on the server for every call. Metering records what the principal scanned. The thin semantic layer stays thin: transforms live in the warehouse; the model names certified metrics and decides who may ask.

Prove it before you trust it

Run the same Semantic Query in the console and from Claude for one pinned published version. Same metric names, same dimensions, same number. That is the bar for “certified metrics only” - not a demo transcript where the model sounded confident.

Wire Claude to the catalog. Keep free-form SQL out of the loop.