Designing an MCP Server for Analytics Datasets
How to build an MCP server that won't mislead AI agents on business metrics.
An analytics MCP server is not a general-purpose connector with a few extra permissions bolted on. It is a distinct engineering problem, because the failure modes differ categorically: a CRUD tool that returns a wrong record annoys one developer, while an analytics tool that returns a wrong number informs someone's business decision. The design choices that follow from this distinction shape everything beneath and around the server itself.
Why an analytics MCP server is a different engineering problem than a general-purpose one
The Model Context Protocol separates three components: the AI client, the MCP server acting as connector logic, and the resource behind it. The server's job is to connect those components safely. It is not meant to become the hidden owner of state or business logic. For a general-purpose tool connector, that boundary is manageable. The consequences of getting a field name slightly wrong are recoverable, and the state involved tends to be simple request-response traffic.
Analytics imposes different requirements before a single tool call is made. An agent answering a revenue question must resolve what "revenue" means in that organization, which fields are approved for that calculation, and whether the underlying data is current. A general-purpose server that exposes tables and lets the agent figure out the semantics will produce answers, but they will be guesses dressed as analysis. Anthropic introduced MCP in November 2024 to replace the patchwork of one-off connectors, and by early 2026 the ecosystem had grown past 10,000 servers. That scale makes each server's design consequential, because agents will exercise it far more aggressively than any human ever did.
The core insight that frames everything that follows is straightforward: MCP does not remove the need for a governed data layer. It makes governance more important. AI agents expose every naming gap, permission gap, and metric-definition conflict faster than human analysts because they issue far more queries and cannot fall back on institutional knowledge. Dreambase treats this as foundational: it pre-models datasets and governs metric definitions at the data layer itself, then exposes them through MCP so agents access only what is safe and semantically clear. The protocol is the wiring. The trust lives beneath it.
What the current MCP specification means for analytics server design
The specification released on July 28, 2026 introduced a stateless protocol core, an Extensions framework, Tasks, MCP Apps, authorization hardening, and a formal deprecation policy. Of these, the stateless core is the change that weighs most heavily on analytics architecture. It removes transport-level session management entirely, so the server can run on ordinary HTTP load-balanced infrastructure. Horizontal scaling becomes straightforward. It also means the server cannot own session state between tool calls.
For analytics workloads, this constraint matters more than it does elsewhere. An analytics agent generates many short-lived calls across metadata lookups, semantic definitions, query engines, catalogs, and workflow systems. Each call must carry its own context, because the server will not remember anything from the previous one. The practical implication is that state must be distributed to its correct owner. Identity state belongs with identity providers and tokens. Task state lives in the agent host or workflow engine. Semantic state sits in metric catalogs and semantic layers. Table and schema state belongs to data catalogs, query state to query engines, and audit state to external logs and observability systems.
The structural error to avoid is building an analytics MCP server that tries to hold any of this state internally. Doing so collapses the stateless guarantee, turning the server into a single point of failure and a governance blind spot. Dreambase operates on this principle: it decouples the analytics data infrastructure, where metrics are defined and governed, from the transport layer, whether that is MCP or an API. The server's only job is to wire safe access to pre-modeled datasets, not to own or enforce business logic. That division of responsibility is what makes the stateless spec workable in production.
Why pre-modeled datasets must sit beneath the MCP server, not raw tables
The data an analytics MCP server exposes must be pre-modeled and governed before the server is involved. A server sitting on top of raw, ambiguously named tables cannot compensate for the absence of a semantic layer, because the agent has nothing to resolve against. Without semantic governance, LLMs select the most statistically likely field rather than the approved one. For founders and small teams running Postgres databases full of ambiguous column names, this is especially dangerous: the agent produces an answer that looks authoritative and informs a real decision.
Adding a semantic document to a database schema, one that defines metric contracts, approved field meanings, and business logic, raises text-to-SQL accuracy by 17 to 23 percentage points, according to arXiv research. The mechanism is that the agent stops guessing and starts resolving against governed definitions. Pre-modeled data means metrics are calculated ahead of time and stored as governed datasets, not computed on demand against raw tables. Each metric has a named owner, a versioned definition, and a contract the agent can retrieve before running any query. The datasets run against a fast, read-oriented engine such as DuckDB over Parquet, rather than against the production OLTP database.
The headless pattern that follows is that a single governed data layer serves agents, BI tools, and applications simultaneously. One definition of a metric is shared across every stakeholder, rather than each surface computing its own version. Dreambase applies this directly: modeled datasets stored as governed Parquet, queryable via DuckDB, exposed through a single MCP server so agents never touch the production Postgres database while still getting fast, accurate analytical context. Teams without a formal data function can begin by identifying the most-contested metrics, governing those first, and building credibility before scaling to a full inventory.
Read-only, scoped surfaces and why write access is the wrong default for analytics agents
An analytics MCP server should be read-only by design, not by configuration. Write access to analytical surfaces creates failure modes that are difficult to detect and nearly impossible to reverse at agent speed, because the agent can issue a destructive operation in the time it takes a human to notice something is wrong. The contrast with general-purpose servers is concrete. The Supabase MCP server, as documented, is not read-only by default: it can write, migrate, and deploy. That is appropriate for a developer tool. It is the wrong default for an analytics agent operating on business metrics.
The security argument reinforces the design one. In July 2025, security researchers demonstrated a "lethal trifecta" attack affecting database MCP servers, where malicious text inside a database row, such as a support ticket or a comment, tricks an agent into running unintended queries. The risk drops substantially when the server surface is read-only and scoped. Supabase's own documented mitigations include read-only mode, project scoping, manual tool-call approval, and the firm guidance to use a development project rather than production. For analytics, these should be enforced structurally rather than left to configuration.
Scoping matters as much as the read-only constraint. Agents should see only the metrics and datasets their role allows, not the full schema. Row-level security enforced at the data layer, not the MCP layer, ensures tenant isolation holds even if the server layer is compromised. The server should expose only the minimum required tools for the analytical task, never entire databases. The governing principle is that agents inherit the permissions of the identity that invokes them, which means the authorization decision must live in the identity and data layers, not in the MCP server's own logic.
How to design the tool surface an analytics agent actually needs
The tool surface of an analytics MCP server should map to analytical intent, not to database operations. That difference determines whether an agent answers a business question in one or two calls or must make many sequential guesses. A naive server that maps every API endpoint or table to a tool forces the LLM to manage state and orchestrate across a long chain of calls. For a complex query, that can mean many individual round trips, with each step compounding the error rate.
An analytically-intentioned tool surface looks like a set of actions an analyst would recognize. A tool to describe an approved dataset surfaces the metric contract, field definitions, and ownership metadata before any query runs. Another retrieves the versioned definition of a named metric, including its calculation logic and approved filters. The query tool executes against the pre-modeled dataset, not the raw table, with validation enforced by the platform. Supplementary tools let the agent check dataset freshness before presenting a result, inspect lineage to establish provenance, and compare against a baseline rather than constructing a bespoke comparison against raw data. The design principle behind this list is that the platform retains control over validation and policy, while the agent's job is to compose analytical intent rather than construct governance logic on the fly.
What to avoid is a catch-all run-sql tool that grants unrestricted query access. That single shortcut collapses the governed layer back into raw table access and eliminates the semantic and access controls the architecture was built to enforce. A developer reading this should leave knowing that the tool names matter less than the mapping: each exposed tool represents an analytical action with defined inputs, defined outputs, and defined governance, not a pass-through to the database.
Connection management and stateless transport in production
Stateless transport solves the scaling problem but surfaces a different failure mode. Without explicit connection management, a single misbehaving agent can exhaust the database connection pool and take down the analytical layer for every other consumer. For Supabase-hosted Postgres, the risk is acute because the free and lower tiers have hard connection limits. An analytics MCP server that does not enforce per-agent connection limits can exhaust the pool across all tenants, and the failure will not announce itself politely.
The correct pattern under the stateless spec treats each tool call as a discrete HTTP request with its own authentication context, with no persistent session state between calls. The query engine, whether DuckDB against Parquet or a read replica, absorbs analytical load and keeps the production database connection pool free for transactional work. Rate limiting and per-agent quotas are enforced at the MCP server layer, not left to the database to reject. Connection pool configuration is pinned and tested explicitly, never inherited from library defaults.
For self-hosted Postgres, restricting the MCP server to a read replica or a governed analytical copy is the correct architecture. The production write path should not be reachable from the MCP surface at all. Audit logging belongs in this same layer. Under the stateless spec, the server does not own audit state, so every tool call should emit a structured log to an external observability system. That is how cost, usage, and access anomalies become visible across the agent fleet, rather than surfacing as a surprise bill or a mysteriously exhausted pool.
Governance as the layer that makes the whole architecture trustworthy
Every architectural decision this guide has covered is a governance decision in a different form. Pre-modeled datasets, read-only surfaces, intent-mapped tools, stateless transport, and connection limits all exist to keep an agent's answer within the bounds of what the organization has already decided is true. A system that gets them right produces answers that humans and agents can trust equally. The failure mode it guards against is that AI agents expose every naming gap, permission gap, and metric-definition conflict faster than human analysts, not because agents are careless, but because they generate far more queries and cannot rely on institutional knowledge to resolve ambiguity.
Governed access at the semantic layer means tests and contracts must pass before any agent can read a dataset. The data is not available through the MCP server until it has cleared validation. Agents see only the metrics and rows their role allows, which keeps spend predictable when query volume is agent-driven rather than human-driven. Every metric has a named owner, so when the definition of something like net revenue changes, there is one place to change it and one person accountable for it. The headless analytics principle follows naturally: a governed data layer decoupled from any single front end, accessible via MCP, API, or direct query, lets the same trusted numbers reach a board dashboard, a Slack alert, and an AI agent's context window without any of them diverging.
Dreambase is built to deliver this pattern for Supabase teams without requiring a data team. Pre-calculated metrics sit in governed Parquet datasets queryable via DuckDB, a single MCP server lets agents call without touching production, and metrics are pushed to where operators work rather than pulled from a dashboard. The governed layer is the product, not a configuration step. The closing argument is that the MCP server is the interface, but trust is built in the layers beneath it. Get the data layer governed and scope the surface correctly, and the protocol does exactly what it promises. Skip those steps, and the protocol becomes a fast path to incorrect answers at agent scale.
