MCP Server Architecture for Structured Business Data

MCP server architecture for structured business data should expose governed metrics. For API-first and agent-first teams, the right headless analytics backend separates metric definitions from any opinionated frontend and serves them through MCP or API. The governing principle is simple. An MCP server is only as trustworthy as the data layer it exposes.

Why MCP connectivity alone does not make business data trustworthy

A sales lead asks an AI agent for revenue figures, and the agent returns a number from the orders table. The connection worked, the query ran, and the answer looks right. Yet the unresolved question is whether that number includes refunds, excludes cancelled orders, and filters out test transactions. Successful retrieval proves none of those things. For business analytics, the test is not whether an agent can reach a number but whether it can return the number the business has agreed to use.

Anthropic released the Model Context Protocol in November 2024 as an open standard that connects three layers: the AI client, the MCP server, and the resource. This separation removes the N×M integration problem of building a connector for every model-to-source combination. Each system exposes a server, and each model maintains a client, replacing bespoke connections with a shared protocol. MCP handles transport rather than meaning, so a column such as rev_net_adj_v2 remains opaque unless another layer supplies the business logic behind it.

What the protocol layer actually exposes when it connects to a Postgres or Supabase database

A direct connection to a production Postgres database gives an agent the capabilities exposed by the MCP server's tools. The Supabase MCP server supports creating tables, running queries, managing schemas, and managing projects and configurations. Those operations are useful for development and administration, but their breadth also defines the risk surface. The agent can inspect schema metadata, column names, and data types without learning which fields are authoritative or deprecated. That access also leaves the agent unsure which aggregation rules to use for board-level reporting and which to use for operational monitoring.

Supabase's guidance distinguishes development use from access to production. It describes development use with read_only=true and project_ref scoping, while its production position is to connect only when the task requires it and then use read-only mode, project scoping, and restricted feature groups. Prompt injection against live production data is the main risk that the guidance names. For analytics, the recommended read-replica pattern separates AI-driven queries from traffic on the primary database. That separation reduces resource contention, but it does not tell the agent how to calculate revenue.

Supabase also released Agent Skills for Postgres Best Practices, covering query performance, connection management, Row Level Security, schema design, and concurrency. Its support team, database advisors, and documentation surface recurring mistakes, including missing foreign-key indexes, queries that bypass RLS, table-locking migrations, and connection pool exhaustion. Agents can make the same mistakes as developers, only faster and at scale. These concerns make operational safeguards necessary, but they remain distinct from semantic safeguards. A query can be read-only and operationally safe while still returning the wrong business metric.

The metadata gap: why schema access and semantic understanding are not the same thing

The metadata gap lies between knowing how a database is built and knowing what its fields mean when a business makes a decision. An agent may find total_price, subtotal_price, and rev_net_adj_v2 without knowing which one the business uses to report revenue. All three names offer clues, but none establishes authority. If the agent selects one by inference, the reporting definition has moved out of the data layer and into the model's interpretation. The resulting answer can be internally coherent while disagreeing with the business's approved calculation.

Cross-source reporting compounds that ambiguity. Revenue can have different definitions across Shopify, Meta, Google Ads, and a CRM, with different attribution windows, refund logic, and channel filters. MCP can make all of those sources reachable without reconciling them. When an agent performs the joins and arithmetic inside its context window, rounding and inference errors can accumulate without surfacing as execution errors.

A similar governance gap opens when teams disagree on what active customer, churn, or MRR means. An agent does not resolve that disagreement simply by processing it faster, and it can distribute the wrong definition across a dozen downstream outputs before anyone notices. A system prompt describing business logic is therefore a brittle substitute for governed definitions. The prompt itself does not version-control those definitions or enforce access, and a schema change can leave its instructions out of date. The remedy belongs in the data architecture because that is where meaning, permissions, and changes can be enforced together.

What a governed data layer does that raw database access cannot

A governed semantic layer turns a metric from an ambiguous reference into a defined entity. Its definition specifies the exact formula, data sources, and calculation rules that every consumer uses. The architecture should also encode relationships, such as orders belonging to customers and campaigns generating sessions that generate orders. Those relationships tell the agent things about the business that a raw schema alone cannot. With definition-level access, an agent can then get monthly recurring revenue without being allowed to read the subscription rows behind it.

This changes what the MCP server serves. Instead of exposing raw tables as the primary interface, it exposes governed metrics and dimensions through defined operations. MCP supplies the transport, while the semantic layer supplies the knowledge needed to calculate a repeatable result. Determinism belongs to the metric calculation rather than to an assumption that the model will reason correctly every time. For trustworthy agent analytics, the combination is the minimum viable architecture.

Dreambase implements this pattern for Supabase and Postgres teams by placing a governed data layer between the database and the MCP server. It pre-models metrics into Parquet datasets queryable via DuckDB and exposes separate metric snapshots through a single MCP server without agents touching production. Pre-calculated datasets are fast to retrieve, cheap to serve, and version-controlled. Their refresh schedule also makes freshness an explicit choice while separating agent consumption from production database resources.

How the MCP server's tool surface should be shaped for business data specifically

The server's tool surface controls whether those guarantees hold when an agent starts asking questions. The starting point should be metadata plus one KPI tool. A metadata tool lets the agent discover which metrics exist and what they mean, while a KPI tool returns a pre-calculated governed value. This is the minimum surface that answers a real business question rather than the maximum surface the database supports. Any exposed open SQL should be the last and most restricted capability.

The next decision is where the work of constructing the answer happens. A low-level interface that requires many sequential calls leaves the agent to assemble intermediate results and accumulate inference errors. A higher-level operation gives the agent a governed metric value without making it go through those steps. When a query needs to be built, the server should do the schema mapping, query generation, and aggregation itself. This agentic orchestration keeps the calculation inside the governed system rather than asking the language model to act as the calculation engine.

Typed parameters and structured errors enforce tool limits by defining which requests the tools accept and letting an agent replan within those limits. Invocation logs that are easy to audit should link to tool call IDs and show which metric definition produced a value and at what refresh timestamp. Every returned metric should also carry the timestamp of its last calculation. That contract makes an answer reproducible and attributable while allowing its consumer to judge whether the data is fresh enough for the decision.

Metric definitions as shared infrastructure for humans and agents operating from the same numbers

A governed metric definition coordinates humans and agents by giving them access to the data and a shared basis for a decision when they use the same definition for the same metric name. The distinction between a metric and a KPI matters here. A KPI is a metric with a target and an accountable owner, while most metrics provide context. That distinction helps teams decide what needs a governed definition and what can be handled with an ad-hoc query.

The definition should record the exact formula, source data, filters, aggregation window, and owner. Rules about test orders and refunds belong in that record rather than in the memory of whoever built the report. Change control makes a revision an explicit decision. Without it, an agent can continue reporting against a meaning that a human changed last Tuesday. With it, the definition becomes shared infrastructure whose changes can be traced.

That shared infrastructure also changes what teams need to measure as agents enter their workflows. Work completed with AI assistance must be distinguishable from work completed without it, because aggregate productivity can hide quality regressions. Data freshness in the reporting system becomes a tracked KPI. Agent decision trails also become necessary to explain the provenance of a board-ready chart. These categories connect the quality of the data to the quality of the decisions made from it.

In a shared data layer such as Dreambase's, pre-calculated metrics give agents pre-verified numbers to assemble into reports rather than raw columns from which to infer correctness. The same governed definitions can serve human stakeholders, BI consumers, and new agents without a separate interpretation for each. Centralization therefore saves teams from repeatedly agreeing on what a number means as well as from repeating query work. Its organizational payoff is concrete. A founder or operator can hand an investor an agent-explainable trail behind every chart because every chart resolves to a governed definition.

What analytics backend works for API-first and agent-first teams end to end

The reference architecture starts with Postgres or a Supabase project as the data home and extends it with a governed layer. That layer pre-models metrics into versioned, auditable datasets, with Parquet queryable via DuckDB providing a production-proven pattern. A single MCP server then exposes the metrics, entity definitions, and metadata rather than making raw tables or open SQL its primary surface. Agents query the datasets that the layer has prepared without touching the primary database. Each answer should carry a definition ID and a freshness timestamp so its meaning and age remain attached to the value.

Governance must hold across that whole path. Central MCP servers should enforce IAM, row filters, and query budgets as properties of the tool contract rather than as controls added after access is available. Explicit definitions close the metadata gap, while separation from the primary database addresses production risk. Shared definitions align human and agent reporting, and the record attached to each answer establishes provenance. These are distinct guarantees, and a working connection alone provides none of them.

This architecture does not require a separate data warehouse, an ETL pipeline, schema changes to the existing Postgres project, or a dedicated data team. Dreambase is one concrete path to extending Supabase and Postgres with this governed serving layer. The relevant selection criteria are modeled datasets, shared definitions, MCP and API access, and separation from production. Those criteria describe the backend needed when the team wants control over the application experience, regardless of whether a product supplies a particular dashboard.

Headless analytics makes that backend independent of any single frontend. A team adding usage analytics to an AI agent can use governed metrics through MCP or API without having to adopt a prebuilt dashboard UI. The same definitions can also feed dashboards, Slack alerts, and investor reports without teams having to rebuild the metric layer for each one. This is why API-first access and semantic governance belong in the same architectural decision.