Exposing Metrics via MCP Without Exposing the Database

Exposing metrics via MCP without exposing the database requires a governed data model. For API-first and agent-first teams, the right headless analytics backend separates metric definitions from the frontend and serves pre-calculated, queryable datasets through controlled interfaces. An MCP server gives agents access to those metrics without giving them access to production.

Why connecting AI agents directly to databases is a data modeling failure, not just a security risk

“Just give the agent read-only credentials” is the intuitive starting point. Read-only access is necessary, but it is insufficient. It prevents the agent from changing records while leaving the agent free to choose the wrong definition of a business metric. If the agent must construct that definition from raw tables, the business has delegated modeling to the moment a question is asked. The agent will find a number that may differ from the business’s number.

For example, two agents can query the same production table with different SQL and return different revenue figures. Both queries can be valid SQL while neither expresses the business’s agreed definition. A raw table does not settle what “revenue” means. Without a named, governed metric, each agent must supply its own interpretation through joins, filters, and aggregation windows.

Direct access also places analytical queries beside writes, transactions, and user-facing reads on a production system. The performance cost is real and unpredictable. Credentials embedded in agent configuration and missing access controls compound the problem, but even perfectly secured raw-SQL access leaves the metric undefined. The focus therefore changes from how agents can reach the database safely to how they can receive only pre-defined, pre-calculated, governed metrics.

What MCP actually is and why its architecture makes a governed metrics layer possible

The Model Context Protocol, or MCP, is an open standard for connecting AI applications to external tools and data through a consistent client-server interface. MCP clients in an AI application or agent host send structured JSON-RPC 2.0 requests to servers. The server controls the exposed surface. It declares which functions exist, which parameters they accept, and which data they return, rather than granting the model unmediated access to the underlying system.

Its three primitives separate different governance decisions. Resources provide read-only contextual data, such as schema definitions, while Tools provide executable functions that an agent can call. Prompts supply reusable workflow templates. For a metrics service, that distinction allows structural context to remain separate from the capability that retrieves a result. Knowing that a dataset exists need not confer permission to query every field within it.

MCP also replaces bespoke integration work with a shared interface. Without that interface, M AI applications connecting to N data sources require M×N custom integrations, while the shared interface requires M+N implementations. The Linux Foundation formed the Agentic AI Foundation in December 2025 with MCP as a founding project, placing it under neutral governance. Standardization alone, however, does not make metrics trustworthy. The governance leverage lies in the server’s control over every exposed request, which makes it the enforcement point for metric definitions, access rules, and output filtering.

The governed metrics pattern — what to expose, what to withhold, and in what order

A metrics server should expose a curated selection of database capabilities. That distinction determines the order of implementation. The staged pattern begins with limited discovery, advances to named KPI retrieval, and treats exploratory SQL as a separate capability requiring explicit approval. The purpose is to make business questions answerable without making arbitrary database operations available.

Stage 1 provides schema discovery with PII masking through list_tables and a schema snapshot. Agents get enough context to understand the structure they can see, while sensitive column names or values are masked from the start. Discovery remains a bounded form of access. It is not permission to retrieve all the records described by that structure, and it should not reveal sensitive information simply to help an agent formulate its next request.

Stage 2 introduces governed KPI retrieval through get_metric. The tool compiles pre-defined, named metrics from a limited set that has been approved and returns a governed result while keeping raw rows out of the response. The agent asks for a metric by name. Stage 3, exploratory SQL, remains disabled until explicit security and governance sign-off. In this pattern, run_sql is a capability to unlock deliberately because enabling it by default defeats the restrictions of the preceding stages.

The same curation principle applies to the server’s scope. A server built around a product capability knows the domain agents need to work with and offers more than a set of schemas. For example, get_customer_summary can return a customer record, their last five orders, and their current subscription status. The tool answers a coherent business question directly. It does not leave the agent to reconstruct that answer from unrelated table-level operations.

The semantic layer makes this boundary explicit for metrics. Definitions are modeled and named before an agent requests them, so the agent selects its calculation from the governed set. An undefined metric produces no governed result. This is the central correctness guarantee of the pattern and a straightforward boundary to explain to a governance reviewer. The agent can interpret a question, but it does not acquire authority to redefine the business measure that answers it.

Why pre-calculated, modeled datasets are safer and more accurate than query-time SQL for agents

Wrong joins, missing filters, and ambiguous aggregation windows arise when a model constructs a metric from raw tables at query time. A modeled dataset resolves those choices beforehand. The agent still has to request the appropriate metric, but it no longer has to reproduce the underlying business logic correctly for every question. That is a narrower and more controllable task.

Query-time SQL also makes the calculation sensitive to prompt context. Two runs of the same agent can generate different SQL and therefore different results, even when the apparent business question is unchanged. For the same governed dataset and metric, the result does not depend on which SQL formulation the model happens to choose. Correctness shifts from a repeated act of generation to a definition that can be reviewed.

That shift makes the definition explicit and auditable, which is the prerequisite for governing it. A business can check the modeled calculation instead of checking whether each generated query asked for the same thing. A reliable metric requires both a sound definition and faithful reuse of that definition.

Freshness creates a genuine constraint on this approach. An agent needs recent data to make decisions, but it can get that data without a direct production connection. A governed dataset refreshed on a short cadence can narrow the freshness gap without bypassing the modeling layer. The choice is not limited to live raw SQL or a slow batch warehouse schedule. Refresh cadence belongs in the dataset design.

Parquet datasets queryable through DuckDB illustrate the separation. The agent queries a file rather than a live database, so its analytical request does not compete with production transactions. Queries can be fast and cheap. Meanwhile, the dataset’s definition remains a governed artifact that can be audited.

The benefit extends to human consumers of the data. When a dashboard and an AI agent read the same pre-modeled dataset, they use the same meaning of revenue. A founder’s dashboard and an agent’s response can otherwise disagree without either interface making the difference visible. Shared datasets remove that split at the level where the metric is defined.

The security layer that pre-calculated datasets make tractable

With governed datasets, the security perimeter is smaller and easier to define than with live database access. Production credentials stay on the server side, and agents get no production connection strings. Access is to a defined data product. The server can then check permissions for the records and fields that product exposes, while a database login alone cannot set the limits for every business question an agent might ask.

A governed dataset can be filtered so that an agent receives only authorized records and fields. For example, a fraud detection agent can get transaction amounts while payment card numbers are kept out of the response.

Gateway-mediated access reinforces that boundary by routing agent data requests through a centralized layer that enforces permissions and logs access. Where live data is needed, the pattern calls for queries to read replicas using purpose-specific, minimal-permission service accounts. The agent still uses the mediated interface. Because requests pass through declared tools, the audit trail can record which metric was requested, by which agent, and at what time. Raw SQL access does not provide that business-level context by default.

What analytics backend works best with full API control and no opinionated frontend

Headless analytics fits teams that need API control without tying metrics to a prebuilt dashboard. It separates metric definitions from the interface that presents or consumes them. The governed dataset exists independently of any frontend. An authorized dashboard, Slack bot, AI agent, CLI, or downstream API can query it without becoming the place where the business definition lives. This also provides a way to add usage analytics to an agent without adopting a dashboard UI.

The architectural comparison is with headless content management. A headless CMS separates content from presentation so that different channels can consume the same content. The organization keeps a governed definition outside the BI tools and agent integrations that use it, so each one can use the metric without rebuilding it.

MCP gives agents a way to get metrics from that shared layer. Metrics can be pushed or pulled through a governed interface, with access control centralized across tools. AWS describes MCP servers as “consistent interfaces to diverse data sources,” expressing the same separation between consumers and underlying systems. Salesforce Headless 360, announced at TrailblazerDX on April 15 2026, applies a related architectural move to CRM by exposing capabilities through APIs, MCP tools, and CLI commands.

For an API-first team, the selection criteria follow from that separation. Metric definitions must stand independently of the frontend, datasets must be queryable through authorized interfaces, and new consumers must reuse the existing governance. A dashboard should not be mandatory infrastructure. A governed layer built for dashboards can then serve agents without rebuilding its metric logic, while changes to shared definitions propagate across the surfaces that consume them.

What this pattern looks like in practice for a Supabase team without a dedicated data function

Supabase provides small teams with production-grade Postgres, authentication, storage, and realtime without infrastructure overhead. The absence of the governed analytics layer described here becomes consequential when an agent needs to interpret business performance. A working production backend supplies the data, but it does not by itself establish the definitions that make an analytical answer trustworthy.

For a team without a dedicated data function, the target implementation keeps that distinction without introducing a new warehouse to manage. Metrics are pre-modeled and pre-calculated from the Postgres data, with no ETL or schema changes. Governed Parquet datasets become queryable through DuckDB. The important boundary is between preparing the metrics and allowing an agent to consume them.

A single MCP server exposes that governed surface to a dashboard, a Slack report, or an AI agent. All consume the same numbers under the same definitions. Agents never need to touch the production database, because the server provides the interface required for their analytical questions. Human-facing tools can use the same governed foundation without dictating how the agent presents or acts on its answer.

The lesson for an early-stage team is to establish metric governance before agents enter the workflow. Observability and agreed definitions belong in the initial design. Access is easier to grant than meaning. Preparing the governed layer first makes a Supabase project suitable for agent consumption without turning its production database into the agent’s analytical workspace.