Sayonora

← Back to home — MCP is one more protocol Warp speaks, not a separate, unguarded door into your database. An AI agent connecting over MCP goes through the exact same SQL firewall, connection ACL, QoS admission control, and audit path as a plain psql client — against Postgres by default, or a real Oracle, MySQL, or SQL Server backend of your own in native-backend mode.

01 Part of Warp

MCP for databases

The Model Context Protocol (MCP) is how an AI agent calls tools — and Warp's MCP frontend is a real wire protocol Warp terminates, the same way it terminates Postgres, MySQL, or Oracle wire protocol. An agent doesn't get a side channel around policy; it gets the same gateway everything else goes through.

Postgres by default, or your own Oracle/MySQL/SQL Server#

By default, every MCP tool call runs through Warp's shared pipeline against the configured Postgres backend — dialect translation, the SQL firewall, ACL, QoS, and caching all apply. Setting WARP_MCP_BACKEND=oracle, =mysql, or =sqlserver (default postgres) instead points execute_sql and the whole data-investigation tool set below at a real Oracle/MySQL/SQL Server connection of your own, with nothing about the SQL rewritten in transit — the same "keep the database you have" tradeoff native-backend mode makes for orawire/mywire/mssqlwire. Native mode bypasses the shared pipeline entirely for every statement, so the SQL firewall, QoS admission control, and caching don't apply to it — connection ACL and pooling still do. Three tools stay Postgres-only regardless of the toggle (see below); tools/list doesn't even advertise them in native mode, and calling one anyway returns a clear error instead of silently running SQL that's wrong for the configured backend. Full native-backend-mode detail →

Generic SQL tools#

Available in every backend mode.

execute_sql / run_sqlRuns a real SQL statement and returns the results — the two names are identical. In Postgres mode this goes through Warp's own pipeline (dialect translation, the SQL firewall, ACL, QoS, and caching, exactly as pgwire/mywire/orawire traffic gets); in native mode it runs straight against the real configured backend.
list_tablesLists tables in the configured backend, excluding system schemas — a real per-dialect catalog query (Postgres's pg_catalog.pg_tables, MySQL/SQL Server's ANSI information_schema.tables, Oracle's user_tables, since Oracle has no information_schema at all).
describe_tableA table's columns — name, type, nullability — schema-qualified or defaulted per dialect (public on Postgres, the configured database on MySQL, dbo on SQL Server, the connected user's own schema on Oracle).

Data-investigation tool set#

Nine tools, real per-dialect SQL, available in every backend mode — built for training and evaluating a small model (SLM) against a real database.

See data-investigation detail →

Structured, JSON-shaped database operations an agent calls step by step to build up evidence about a database, rather than generating raw SQL as the only interface — the approach this post describes for training an SLM to investigate a database, treating it as external working memory the model learns which evidence to seek from, not something to embed into its own weights.

inspect_schemaEvery table and column in the backend, in one call — the starting point for exploring an unfamiliar database.
column_statsRow count, null count, mean, standard deviation, min, max, and distinct-value count for one column. SQL Server's own population-stddev function is spelled STDEVP, not STDDEV_POP — a real per-dialect difference, not just cosmetic.
compare_groupsAggregates a metric column grouped by another column, sorted by the aggregate value — e.g. average order value by region.
correlationPearson correlation coefficient between two numeric columns. Postgres and Oracle have a real CORR() aggregate; MySQL and SQL Server don't, so their SQL derives it by hand from AVG/STDDEV_POP — SQL Server's own AVG does integer division on integer columns, so its formula also needs an explicit FLOAT cast the others don't.
sample_rowsA representative sample of rows from a table.
find_outliersRows where a column's value deviates from the column's own mean by more than a configurable number of standard deviations (z-score outlier detection), most extreme first.
find_join_pathA real breadth-first search over the schema's own foreign-key graph — the shortest real JOIN chain between two tables, as a hop list plus ready-to-use JOIN SQL. Postgres/MySQL/SQL Server share one ANSI query (information_schema.referential_constraints joined to key_column_usage twice); Oracle uses user_constraints/user_cons_columns, since it has no information_schema at all.
explain_sqlA real EXPLAIN plan, no LLM narration — available in every backend mode, unlike the Postgres-only explain_query below. Postgres/MySQL run one EXPLAIN ... FORMAT JSON statement without executing the query; Oracle runs a real two-statement EXPLAIN PLAN FOR + DBMS_XPLAN.DISPLAY() flow; SQL Server puts the session into plan-only mode via SET SHOWPLAN_ALL ON for its next statement, then turns it back off.

Table/column/group-by identifiers arrive as free-form tool arguments and get interpolated directly into SQL text (bind parameters can't stand in for identifiers) — every tool validates each one against a plain-identifier pattern first, the one guard against a caller closing a string and injecting arbitrary SQL through what's supposed to be a bare name.

AI-assisted tools (Postgres only)#

All three hardcode Postgres-specific SQL or an LLM prompt written assuming Postgres — refused with a clear error (and not advertised by tools/list) in native mode, rather than silently running SQL that's wrong for the configured backend.

query_natural_languageDrafts a read-only SQL SELECT from a plain-English question, with a second, independent LLM pass judging (and correcting) the drafted SQL before a deterministic read-only check runs it — the LLM drafts and judges, it never gets to execute unchecked.
explain_queryRuns a real Postgres EXPLAIN (optionally ANALYZE) and has an LLM narrate the plan in plain English — the same read-only gate query_natural_language uses gates this tool too.
document_schemaLists every real table/column and foreign-key relationship and has an LLM generate plain-English schema documentation from it — read from the live catalog, not a stale cache.

Every one of these keeps the same split every Warp AI feature does: a deterministic decision stays deterministic (the read-only check, the firewall rule, the ACL match), the LLM only drafts, phrases, or judges — see all ten AI features Warp has, beyond MCP →.

Registered stored-procedure tools (Postgres only)#

WARP_MCP_TOOLS names specific real Postgres functions/procedures to expose as individually-named MCP tools — only what's explicitly registered is callable, not arbitrary SQL. Each tool's input schema is generated automatically by introspecting the real function's own parameter types, with OUT parameters correctly excluded from what a caller needs to supply. Postgres-only (it introspects pg_proc directly) — skipped, with a clear log message, in native mode.

Same policy, same audit trail#

SQL firewall + ACLAn MCP-issued statement is checked against the exact same firewall rules and connection ACL as any other protocol's traffic in Postgres mode — no MCP-specific bypass. In native mode, connection ACL still applies; the SQL firewall is a pipeline stage native mode bypasses, same as it does for orawire/mywire/mssqlwire's own native modes. Security detail →
QoS admission controlAn agent making many calls in a burst is rate-limited and shed under load the same way any workload class is — in Postgres mode. Another pipeline stage native mode bypasses. QoS detail →
Audit + summarizationEvery MCP tool call lands a real audit event — tool, arguments, success/failure — with an LLM able to summarize recent activity for a human reviewer on request, in every backend mode.
OIDC/JWT bearer authThe MCP endpoint supports OIDC/JWT bearer tokens with live JWKS rotation, off by default until an issuer is configured — the same auth model the admin API uses, in every backend mode.

Explore Warp in depth — detailed architecture, comparison →