Exposing Data to an Agent: MCP vs API

Fri, 15 May 2026 00:00:00 +0000

TL;DR

MCP is a wire protocol; what sits behind it decides the blast radius. In non-prod, pointing it at the database tends to be fine, because unbounded exploration is worth more than the occasional mistake. In prod, the shape that holds up is having the MCP server’s tools call an agent-specific API that enforces allowlisted operations, row caps, column masking, and per-prompt audit, rather than the database directly. The version that points at the database tends to surface later as a privacy incident.

Note

This is about the third-party database MCP servers from public registries (Postgres, MySQL, MongoDB, Redis, Elasticsearch), whose load-bearing tool is query(sql_string) against whatever connection they were configured with. A custom MCP server you wrote to wrap your own API is a different shape and isn’t the argument here.

A revenue dashboard agent runs against production through the MCP server the analytics team stood up last quarter. Marketing asks for enterprise signups in Q1 with their account contacts. The agent generates SELECT id, email, phone, last_login_at, plan, mrr FROM users JOIN subscriptions ... WHERE created_at >= '2026-01-01' AND plan = 'enterprise', and 2.3M rows come back. The agent truncates the chat-side display to the first fifty. The full result set leaves the database, crosses the MCP server, and lands in the conversation history the model provider keeps for thirty days. The connection that ran the SELECT held a slot on the read replica for fourteen minutes before the proxy reaped it, and p99 read latency for the customer-facing dashboard tripled over that window. The audit log records one MCP call from mcp-readonly@analytics. No prompt, no agent identity, no user attribution. The post-mortem has six unanswered questions.

Read-only doesn’t bound any of this

The patch the post-mortem will land on in fifteen minutes is “make the MCP connection read-only.” The connection already was. Read-only restricts the verb set, and every failure above happened on SELECT.

A read-only SELECT against a 50M-row table is still a SELECT, with the same cost on the replica. Read access on users is read access on users.password_hash and users.api_token. The corruption floor that If Your Guardrail Is a Prompt describes eventually emits a query against a table the agent had no business touching, and read-only lets it through. And every row the agent reads becomes part of the context window the model provider keeps for thirty days, regardless of what your privacy policy says.

The verb was never the surface. The catalog is.

MCP is the wire, the endpoint is the policy

MCP is a tool-surface protocol. The standard database MCP server exposes query(sql_string): the model writes SQL, the server forwards it to whatever connection it was configured with. That makes the MCP server a conduit between the model and the catalog. The agent’s effective permissions are the connection’s, the agent’s query surface is every SQL statement the connection can run, and the audit trail is one row per call from one identity with the SQL as the only payload, which a pre-AI audit log treated as sufficient and an AI-era audit log doesn’t.

Note

The protocol isn’t the problem. MCP solves a real coordination problem: how a model discovers and calls tools across hosts, harnesses, and vendors. What you put on the other end is the part that decides whether you’ve exposed a database or an API.

A SQL conduit also makes the silent-failure shapes from What AI Gets Wrong About Your Database reachable from a chat window: JOIN paths against tables the model inferred from names, status = 1 filters where 1 means “pending” not “active”, unconstrained bridge tables that multiply rows. None of it requires write access, and all of it lands in the model provider’s trace.

The thing you want on the other end of MCP is an API. Not your customer-facing API. An API written for the agent: a list of operations it can call, with parameters, shaped responses, per-operation entitlements, row caps, timeouts, column masking, and an audit trail that records the agent identity and the prompt that produced the call. The agent never composes SQL. It calls get_enterprise_signups(quarter, plan) and gets back an aggregated result.

What the agent API looks like

Named operations, not raw SQL. get_revenue_by_segment(quarter, segment), list_active_enterprise_accounts(limit, cursor), get_customer_summary(customer_id). The agent picks from a menu the platform team curated. Operations get added when an analysis pattern proves useful enough to commit to a stable interface.

Responses shaped for the agent, not for the application. A revenue-by-segment call returns aggregated totals, not the 2.3M rows behind them. The shape is token-budget aware: a top-N list with totals beats a paged row dump.

Column-level masking inside the API. Email becomes a domain plus a hash. Account IDs are opaque tokens the API resolves on the next call, not database primary keys. Sensitive columns are gated by per-operation entitlements granted explicitly to the agent identity.

Row caps and statement timeouts the API enforces. Every operation has a hard cap on rows and database time. Caps live in code the API team owns, not in the prompt. If an operation needs higher caps, the cap is raised for that operation, not the connection.

Per-call audit with prompt provenance. Every call records the agent identity, upstream user, operation, parameters, response shape, row counts, latency, and the prompt that produced the call. Six months later, “who ran the query that leaked the enterprise customer list” is two SELECTs away.

Per-agent rate limits. Agents loop. Agents retry. The API budgets calls per identity, per operation, and per database time. The budget is a backstop on cost, on the replica, and on the model provider’s trace volume.

Warning

Don’t reuse your customer-facing API for this. Your customer API is shaped for an authenticated user reading their own data. The agent API is shaped for a service account reading across users, returning aggregates rather than rows, masking PII by default, and logging every call against a prompt. Two consumers, two contracts. One API that tries to serve both ends up either too permissive for customers or too restrictive for agents.

The MCP server’s tools then become thin wrappers over the API. Each MCP tool corresponds to one API operation. The agent sees get_revenue_by_segment as a tool; under the hood it’s an HTTP call to a service that talks to the database with its own pool, its own identity, and its own rules. The model never speaks SQL to anything.

What you get for the work

Control over what’s exposed, including the catalog. The API is the curated surface; what isn’t on the surface isn’t reachable. PII is masked or omitted by default, sensitive tables don’t have an operation, and the system catalog (information_schema, pg_catalog, MongoDB’s listCollections) never reaches the agent. Hide the catalog and you hide the menu of mistakes the model can make. The same surface-narrowing pays a partial dividend on prompt injection: an instruction smuggled into a document the agent reads has no query(sql) tool to hijack, only the operations on the menu.

Observability. Who called, when, with what parameters, against what prompt, returning what row counts. You can see which agents are over-fetching, which operations are getting hammered, which prompts produce weird call patterns. Patterns drive the next iteration: the operation called twenty times an hour gets cached, the one that always returns a million rows gets a tighter cap.

Throttling in a layer the database doesn’t reach. Per-agent, per-operation, per-minute, with hard backpressure during a customer-facing incident. This matters most when the agent is pointed at a primary: it shares a connection pool and CPU budget with the customer-facing write path, and a runaway loop or deep aggregation can move primary CPU enough to slow checkout. Statement timeouts on the database alone don’t help, because most of the damage lands in the first ten seconds. The API can apply the throttle at the call boundary, before the SQL reaches the connection: per-agent QPS caps, per-operation concurrency limits, a circuit breaker on customer-facing latency.

Where MCP-direct still earns its keep

Local development against a seeded test database. Nightly-refreshed sanitized snapshots of production with PII stripped. CI integration tests against ephemeral databases built from fixtures. Single-operator setups where the agent’s permissions are explicitly the operator’s. In all four, the cost of a mistake is bounded, and the loop of asking any question and throwing the answer away is the point of the environment. Patterns that prove useful in dev or snapshots get promoted to operations on the prod API; the rest stay in dev.

The dividing line is who pays the cost of a mistake. If it’s the same person running the agent, MCP-direct is fine. If it’s a customer whose contact list just got absorbed into a model provider’s training-eligible context buffer, MCP through the API. A two-engineer team with one agent and one use case can defer the API, but they’ll feel the cost the first time a second agent shows up or the first time a privacy review asks where customer data has been read from.

If MCP-direct, harden the database side

When the team picks MCP-direct in prod anyway, the database layer has knobs worth turning on. None substitute for an API. All are cheap.

A dedicated database user for the MCP connection. Not the analytics role, not an existing service account, not anything with grants accumulated over years. The agent’s user gets its own grants and an audit-log identity that names a single purpose.

Per-schema and per-table grants. PostgreSQL’s REVOKE ALL ON SCHEMA ... FROM PUBLIC is the underused default. The agent’s role gets read on a small set of schemas (often a dedicated analytics schema of shaped views), with explicit denies on schemas holding credentials, secrets, audit logs, and the system catalog.

Column-level masking via views or row-level security. A view over users that hashes email and omits password_hash, api_token, and phone closes most PII exfiltration in five minutes. RLS policies on tenant-scoped tables enforce a single-tenant read by default.

Aggressive statement timeouts and connection caps. statement_timeout and idle_in_transaction_session_timeout set per role at five or ten seconds kill runaway aggregations before they touch replica CPU. Connection caps via PgBouncer prevent the agent from monopolizing the pool during a retry storm.

The bigger picture

The pattern is the one every public-facing system already settled into a decade ago: you don’t expose the database to the internet, you put an API in front. The agent is a new principal that deserves the same treatment. MCP is the transport, the way HTTP is the transport for your frontend. Transports don’t make policy. Pointing MCP at a database makes the database the endpoint, and the database has no concept of an agent identity, a prompt, or a column-level mask for a non-human caller.

Building the agent API is the ideal case of an internal tool an AI agent can write quickly: greenfield code, one team owning the contract, low blast radius, replaceable v1, sandbox available for the first cut. A day or two with a coding agent rather than the quarter-long platform initiative it would have been in 2022. It’s testable, observable, and the thing that lets you point MCP at production without filing a privacy incident the following Tuesday.