Connect Cursor to governed metrics via MCP

Cursor can talk to governed metrics the same way it talks to other MCP servers: a local or remote MCP endpoint, a short tool list, and prompts that stay inside those tools. datahashi exposes metrics through MCP so coding agents get catalog discovery and typed queries without raw warehouse access.

What you connect

You register a datahashi MCP server in Cursor’s MCP settings. The server advertises six tools:

• list_catalog to see available metrics and domains
• describe_metric to pull definitions, grain, and allowed filters
• run_semantic_query to execute a governed query
• drill_down to open one aggregated cell
• refine_semantic_query to change the previous query and run it again
• list_dimension_values to check real values before filtering

That is the whole surface for metric work. Cursor does not need a general SQL tool pointed at production. Keeping the catalog thin reduces prompt drift and makes reviews easier: every metric call looks the same in the chat transcript.

Setup flow that stays boring

Point Cursor at your datahashi MCP URL or local process. Authenticate with the credentials your org already uses for semantic access (service token or user-scoped key, depending on policy). Confirm the six tools appear in the MCP tool picker. Then ask Cursor, in plain language, to list metrics in a domain you care about.

A healthy first session looks like this: call list_catalog, pick one metric, call describe_metric, then call run_semantic_query with a short window and an allowed dimension. If any step fails, fix auth or permissions before wiring the server into daily coding workflows.

Why governed MCP beats ad hoc warehouse plugins

Many teams already give Cursor warehouse credentials “for debugging.” That path invites accidental writes, broad selects, and copy-pasted secrets in rules files. MCP with datahashi keeps Cursor on read-shaped semantic calls. Definitions live in the semantic layer, not in a scattered set of SQL snippets in the repo.

When a metric definition changes, Cursor picks it up through describe_metric. You do not chase outdated CTEs across agent rules. When a query is wrong, you fix the metric or the filters once, and every Cursor session benefits.

Prompt habits that work in Cursor

Teach the agent a fixed order: catalog, describe, run. Ask for explicit date ranges. Prefer metrics by name over vague business phrases. If the agent proposes raw SQL, refuse and redirect to run_semantic_query. Those habits survive model upgrades better than long custom system prompts.

For product and platform work, keep examples in your Cursor rules: “Use datahashi MCP tools only for metrics. Never invent table names.” Short rules beat encyclopedias. Pair them with CI or review checks that flag commits introducing warehouse DSNs into agent config.

Security and environment notes

Use least-privilege tokens scoped to the semantic layer. Prefer separate tokens for personal Cursor use versus shared CI agents. Rotate on the same schedule as other developer credentials. Do not paste production secrets into chat to “unblock” a tool call; fix MCP auth instead.

Log MCP tool usage if your org requires audit trails. Cursor sessions that call run_semantic_query should be attributable to a person or a bot identity. That makes it possible to investigate odd spikes without blaming the warehouse blindly.

What success looks like

Success is a Cursor chat that answers “what was activation last week by plan?” by listing the metric, confirming the definition, and returning a governed result. No spreadsheet export. No shadow dashboard. Just MCP tools, a short transcript, and numbers that match the rest of the company.

Connect Cursor to datahashi once, keep the tool list at three, and let governed metrics travel with the editor your team already lives in.