Amplitude warehouse metrics and the Data Warehouse MCP server

What it is

Warehouse metrics are named, reusable calculations defined once against your warehouse tables - the same idea as a metric layer in a modern data stack - so that "activation rate" or "weekly active users" means the same thing everywhere it's used inside Amplitude, instead of getting redefined slightly differently in every chart that needs it.

The Data Warehouse MCP server is a separate but related capability: Model Context Protocol is an open standard for letting AI tools query external data sources through a defined, permissioned interface rather than raw credentials. Amplitude's MCP server for warehouse data lets an AI agent (Amplitude's own AI features, or a third-party agent someone connects) ask questions against your warehouse-native metrics without that agent needing direct warehouse access.

When you need it

• Multiple dashboards or teams have quietly drifted into slightly different definitions of the same core metric, and you need one governed calculation that every downstream chart reads from instead of re-deriving.
• You're building or evaluating an AI-agent workflow (an internal chatbot for self-serve metrics, or a third-party MCP-compatible tool) and want it to answer questions against real warehouse data under the same governance and access controls as your human analysts, rather than a separate, less-controlled data path.
• Your data team wants to move metric logic out of individual dashboard configurations and into a warehouse-adjacent layer that's version-controlled and auditable the way a dbt model is, rather than living inside whichever BI tool happened to build the first chart.

Implementation, done properly

1. Inventory the metrics that actually have competing definitions across your dashboards before building anything - the value of a metrics layer is consolidation, and consolidating without first finding where the definitions actually diverge just adds a new layer on top of the old confusion.
2. Define each metric's calculation once, at the warehouse-metrics layer, with clear ownership (a named person or team responsible for the definition) - the same governance discipline a tracking plan needs for events applies here to metrics.
3. Where the Data Warehouse MCP server is in scope, treat its access scoping deliberately: decide which metrics and tables an AI agent is permitted to query before connecting anything, the same way you'd scope a service account's database permissions - broad, ungoverned access defeats the purpose of a controlled interface.
4. Test the MCP connection with a narrow, known question first (a metric you can verify by hand) before trusting it for open-ended exploratory queries - an AI agent given warehouse access can construct a technically-valid but analytically-misleading query if the underlying metric definitions aren't precise enough to constrain it.
5. Document both layers together: which metrics exist, what they mean, and which are exposed to AI-agent queries versus human-only dashboard use - this pairing (metric governance plus access governance) is what keeps an MCP-connected warehouse from becoming a way to accidentally bypass the same discipline your tracking plan enforces elsewhere.

How to verify it worked

1. Pick one warehouse metric, calculate it independently with a direct SQL query against the warehouse, and confirm it matches what Amplitude's charts display for the same metric and time window - the standard sanity check for any metrics-layer claim.
2. Confirm every dashboard that's supposed to be using the shared metric definition actually is - check for a lingering dashboard-local calculation that was never migrated over, which would keep producing the exact inconsistency the metrics layer was built to eliminate.
3. For the MCP server: ask the connected AI agent a question with a verifiable, known answer, and confirm its response matches - then ask a slightly ambiguous follow-up question and check whether it asks for clarification or silently guesses at intent, since silent guessing is the failure mode most likely to produce a confidently wrong answer.
4. Review the MCP server's access logs (if available) periodically to confirm the queries an agent is actually running stay within the scope you intended when you set up the connection - access scoping decided once at setup can drift in practice as new use cases get added informally.

Related: Warehouse-native Amplitude: how it works · Amplitude AI agents: what they do and when to use them · North star metric, defined