OrmAI vs. MCP database servers

MCP database servers expose your DB to any MCP-aware client. OrmAI is policy-first, in-process, and shipped inside your application. Here's when each is the right choice.

The Model Context Protocol (MCP) is rapidly becoming the standard way for AI clients (Claude Desktop, Cursor, Zed, custom agents) to talk to external tools. There are now several “MCP database servers” — small servers that expose a Postgres or MySQL database to any MCP client. This page compares those servers to OrmAI, including OrmAI’s own MCP integration.

What an MCP database server is

An MCP database server is a process that:

Speaks the MCP protocol (over stdio or HTTP).
Accepts a database connection string.
Exposes tools like list_tables, describe_table, and query (where query is usually a SQL string).
Returns results to the MCP client.

Most MCP database servers in the wild today are essentially thin wrappers around a database driver. The most prominent ones are read-only by default, with options to allow writes.

Where MCP database servers shine

Personal-developer use cases. A developer connects Claude Desktop to their own dev database. There’s no tenant isolation problem because there’s only one user. This is a great fit.
One-off analytical exploration on a database that already has properly scoped credentials.
Quick demos of “look, the LLM can query our data.”

In other words, the same use cases where raw SQL access is fine. MCP database servers are mostly raw SQL access wrapped in a protocol.

Where they break

The same places raw SQL breaks, plus a couple of new ones.

1. There is no policy

The MCP server has no concept of “this user can see these fields, that user can see those fields.” Some servers let you scope by schema or table, but field-level redaction, masking, and conditional visibility are absent.

2. The MCP client trust boundary is murky

When you point an MCP server at a database, you are giving the LLM client (and anything riding on its tool calls — like prompt-injected attackers) the credentials of whatever user the connection string belongs to. You’d better be sure that user is heavily restricted at the database, because nothing else is restricting it.

3. No tenant scoping

In a multi-tenant SaaS, you need every query to be filtered by the right tenant. An MCP server doesn’t know who the request is from. You can construct a per-tenant database role and a per-tenant connection string and spin up a per-tenant MCP server, but this is a deployment nightmare.

4. Audit is server-side, not request-side

An MCP server can log every query it ran. It cannot, generally, log “agent X, on behalf of user Y, ran this query because it was answering question Z.” That context lives in the MCP client.

5. The agent gets a SQL surface, not a typed surface

The MCP server’s query tool takes a SQL string. Same critique as the text-to-SQL and raw-SQL comparisons.

OrmAI’s relationship with MCP

OrmAI ships an MCP server adapter that exposes the OrmAI toolset as MCP tools. From the perspective of an MCP client (Claude Desktop, Cursor, etc.), it looks like an MCP database server — but the surface is db.query, db.get, db.aggregate, etc., not raw SQL, and the policy is enforced.

from ormai.mcp import serve

serve(toolset, principal_resolver=lambda req: extract_principal(req))

This gives you the convenience of MCP — drop the server into Claude Desktop’s config, point your agent at it — with the safety of OrmAI’s policy engine. The MCP client doesn’t know it’s running through a policy. It just sees a small set of typed tools.

A direct comparison

Concern	MCP database server	OrmAI (with or without MCP adapter)
Surface to the model	SQL string	Typed operations
Tenant scoping	Out of scope (DB role only)	First-class, per-call
Field redaction	None	Per-model, per-field
Write gating	Read-only flag, or write open	Per-model with reason / approval / cap
Audit log	Server-side query log	Structured per-call with policy decision
Multi-tenant deploy	One server per tenant	One process, per-call principal
In-process or separate	Separate process	Either — MCP server adapter optional
Trust boundary	DB credentials	Application policy

When MCP database server is the right call

Use it directly when:

You are a single developer with full access to the database you’re connecting to.
You are running it locally against your own dev environment.
The data is non-sensitive and the operations are read-only.
You are prototyping; you don’t intend to ship this.

If any of those don’t hold, you want OrmAI — possibly served over MCP, but with the policy in front.

”I want both”

This is the most common production setup. The pattern:

Build your application with OrmAI as the data layer for your agent.
For internal tools (engineering team using Claude Desktop to query staging), expose a separate, read-only OrmAI policy via the MCP adapter.
The same audit infrastructure covers both.

You end up with one policy file per environment, one audit log, and two consumption surfaces (your application’s agent + your team’s MCP clients). Both are policy-checked.

A note on protocol vs. policy

A subtle point: MCP is a protocol. It’s about how tools are described and invoked. OrmAI is a policy runtime — it’s about what tools do and whether they are allowed to.

These are complementary, not competing, concerns. Saying “we have an MCP database server” is like saying “we have a REST API” — it tells you about the wire format, not the safety properties. Anything you put behind that protocol still needs policy if it’s going to be safe.

OrmAI fills the policy slot. MCP, for the cases where you want it, is just one of the wire formats OrmAI can speak.