warehouse-mcp
Enables governed, read-only querying of DuckDB databases through MCP tools. Supports semantic metric queries and guarded SQL SELECTs, with role-based dataset access, row filters, pseudonymized personal data, result caps, audit logging, and DuckDB read-only/no-file-access safeguards.
Enables governed, read-only querying of PostgreSQL databases through MCP tools. Supports semantic metric queries and guarded SQL SELECTs, with role-based dataset access, row filters, pseudonymized personal data, result caps, audit logging, and PostgreSQL read-only transaction and grant-based safeguards.
This server does not currently have a deployable release on Glama. Follow the repository's setup instructions to install and configure it for your MCP client, including any required credentials and local dependencies.
# warehouse-mcp
Give AI agents your warehouse without giving them your warehouse.
An MCP server that lets Claude, Cursor or any MCP client query DuckDB, Postgres or BigQuery through a governed, read-only layer:
a semantic model, so agents ask in business terms;
a SQL guard that an agent cannot talk into writing, reading files or leaving its lane;
per-role row policies;
pseudonymized personal data;
an audit log;
a cost cap.
Every claim below is backed by a test or a measured run.
What was checked | Result | Evidence |
104 bypass attempts (exfiltration, row-filter escapes, PII probes, file and system access, statement smuggling, resource abuse) | 0 leaks on DuckDB and on Postgres |
|
Same 15 queries on three engines | Identical results on DuckDB, Postgres and BigQuery | |
Writes with the SQL guard bypassed | Refused by the engine itself: read-only transaction, then grants | |
A careless agent query on a multi-terabyte table | Refused before billing: "would scan 4.65 GB, above the 1.00 GB cap" | |
Agent answers over MCP, graded against SQL ground truth | 26 cases, gated by regressgate |
Try it in one line
The bundled demo serves about 100k live Wikipedia edits, captured by realtime-lakehouse, from a local DuckDB file. No keys are needed.
{
"mcpServers": {
"warehouse": { "command": "uvx", "args": ["warehouse-mcp", "--demo"] }
}
}Put that in Claude Desktop's config, or run claude mcp add warehouse -- uvx warehouse-mcp --demo.
Then ask "Which wikis had the most bot activity, and how many distinct editors did each have?"
What the agent sees, taken from real tool calls on the demo:
warehouse_query_metrics(dataset="edits", metrics=["edits","editors","bot_share"], dimensions=["wiki"])
wiki edits editors bot_share
enwiktionary 41594 46 0.994
commonswiki 16053 224 0.849
enwiki 9576 1401 0.489
warehouse_run_sql("SELECT editor, count(*) AS edits FROM edits GROUP BY editor ORDER BY edits DESC")
pii_6b19c4a15ccf 41335 <- a pseudonym: counts and joins are exact, the name never leaves
pii_6a8d5fd6c44b 9638
warehouse_run_sql("SELECT * FROM edits; DROP TABLE edits")
Error: Send exactly one statement; multiple statements are not allowed.
warehouse_run_sql("SELECT pg_read_file('/etc/passwd') FROM edits")
Error: Function pg_read_file() is not allowed. Use standard SQL functions (...)Related MCP server: sql-steward
How it works
flowchart LR
A[Agent] -->|MCP: stdio, or HTTP + bearer key| T[4 read-only tools]
T --> R[Role<br/>from the key]
R --> G[SQL guard<br/>sqlglot, backend dialect]
G -->|rewrite each dataset into| P[Policy subquery<br/>declared columns only<br/>salted pseudonyms<br/>role row filter]
P --> B[(Backend safeguards<br/>DuckDB: read-only, no file access<br/>Postgres: read-only txn + grants<br/>BigQuery: dry run + byte cap)]
B --> X[Cell cap + email/phone redaction]
X --> L[Audit log<br/>no values, no salt]
L --> APseudonymize at the source, not in the output. The guard rewrites every dataset reference into a subquery that replaces personal columns with a salted hash, inside the warehouse. As a result:
count(DISTINCT editor)stays exact;joins on pseudonyms work across datasets;
a probe like
WHERE editor = 'Alice'matches nothing, because the comparison runs against the hash;names never cross the wire.
Masking the output after lineage analysis can be bypassed with aliases, expressions or functions. Here the raw column is simply not reachable.
Each layer is designed to hold if the layer before it fails. The guard is the first layer:
single statements only;
SELECT only;
declared datasets only;
function allowlist;
CTE references resolved by scope, so
WITH t AS (SELECT * FROM t)cannot reach the real tablet;capped LIMIT.
Behind it, each engine is locked down on its own, and the tests prove it with the guard bypassed.
The tools:
Tool | Use |
| What the caller's role may query, with each dataset's grain and metrics |
| Columns, which are pseudonymized, row policy, and 3 sample rows |
| Preferred path. Named metrics by dimensions and time buckets. The SQL is built as a syntax tree, so filter values are never SQL |
| One guarded SELECT, for questions metrics cannot express |
What the red team found
The adversarial suite found three real gaps outside the SQL guard. All three are fixed and kept as regression tests:
ReDoS after the timeout. The email-redaction regex backtracked quadratically, and a 1 MB string from
repeat('x', 1000000)would have held the server for about 12 minutes. It ran after the warehouse timeout, so nothing stopped it. The fix bounds the regex repeats and cuts cells before redaction.A single huge row skipped the result cap. The fix halves the longest text cells until the row fits.
Pseudonyms could be linked back to names. An edit to one's own
User:page pairs a pseudonym with a title that contains the name. That re-identified 5.7% of editors in the snapshot where it was found. The fix adds conditional PII (pii_when: "namespace IN (2, 3)") for user-page titles and pseudonymizes edit summaries.
An independent review by a second model then found a gap the suite had missed, this time in the guard:
An alias could disguise a real table as a CTE. In
WITH x AS (...) SELECT * FROM edits_raw x, x, the guard matched CTE references by alias, so the physical table skipped the policy rewrite. CTE references are now resolved by table name within each scope, and aliasing a real table to a visible CTE name is refused.Engine errors quoted data. A message such as
Could not convert string '<value>'bypassed result redaction and reached both the agent and the audit log. Error messages now lose their quoted values and are redacted and capped.
Running the parity cases on BigQuery found one more problem, a correctness bug rather than a
leak: time literals were cast to DATETIME against TIMESTAMP columns. It is fixed.
Configure your own warehouse
extends: demo:wikipedia # or write datasets/roles from scratch
connection: {kind: postgres, dsn_env: WAREHOUSE_MCP_POSTGRES_DSN}
roles:
- {name: analyst, datasets: "*", api_key_env: KEY_ANALYST}
- name: enwiki_partner # an external partner sees one wiki only
datasets: [edits, edits_per_minute]
row_filters: {edits: "wiki = 'enwiki'", edits_per_minute: "wiki = 'enwiki'"}
api_key_env: KEY_PARTNER
- {name: trust_and_safety, datasets: "*", pii_clearance: true, api_key_env: KEY_TS}Datasets declare their columns, which ones are pii or pii_when, which are free_text, and
named metrics. Undeclared columns do not exist for the agent. Over HTTP
(warehouse-mcp --config my.yaml --transport http) each bearer key selects a role. Keys come
from environment variables; the config holds no secrets.
Setup for each backend, Claude Desktop snippets and the eval workflow are in docs/deployment-guide.md. For rolling this out at a company (discovery, access model, staged rollout, success metrics, incident runbook), see docs/deployment-playbook.md.
Development
pip install -e ".[dev]"
pytest # DuckDB; Postgres/BigQuery suites skip without a DSN
docker compose up -d && python scripts/load_snapshot.py --target postgres
WAREHOUSE_MCP_POSTGRES_DSN=postgresql://mcp_reader:local-only-reader-password@127.0.0.1:55432/warehouse pytestArchitecture and threat model · codebase map · roadmap
Limits
Phone-number redaction applies to columns tagged
free_text. An alias such ascomment AS closes the phone pass; it keeps email redaction, which applies everywhere.HTTP uses static bearer keys and plain HTTP. Put TLS in front of it. OAuth resource-server mode is on the roadmap.
Snowflake is on the roadmap.
Data
The demo data comes from Wikimedia's public recent-changes stream, licensed CC BY-SA 4.0. Code is MIT.
This server cannot be deployed
Maintenance
Related MCP Connectors
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
The grounded data layer for any LLM: governed SQL, metrics, lineage and catalog over your data.
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to understand and query your database safely by providing a semantic layer of metadata, with tools to search, explain, validate, and generate safe SQL.2MIT
- AlicenseAqualityFmaintenanceA governed SQL gateway that exposes typed tools to AI agents, compiling safe read-only queries from a semantic layer while blocking PII before execution, supporting SQL Server, Postgres, and SQLite.9MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to query governed data warehouses through plain language, returning grounded answers with SQL, confidence grades, and signed receipts while enforcing access, testing, and audit controls.279 PyPI17Apache 2.0
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to query a Postgres data warehouse through a governed, read-only SQL interface with policy enforcement, row limits, schema-level PII isolation, and a full audit trail.1-