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 | tests/test_red_team.py, run in CI |
| Same 15 queries on three engines | Identical results on DuckDB, Postgres and BigQuery | parity tests, BigQuery run |
| Writes with the SQL guard bypassed | Refused by the engine itself: read-only transaction, then grants | test_postgres_parity.py |
| A careless agent query on a multi-terabyte table | Refused before billing: "would scan 4.65 GB, above the 1.00 GB cap" | BigQuery run |
| A Claude Haiku 5.5 agent answering over MCP, graded against SQL ground truth (26 cases, 3 trials each) | 78/78 correct, including 6 governance cases, at $0.0016 per question, p95 6.3 s. Gated by regressgate | evals/cases.jsonl |
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 (...)
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 --> A
Pseudonymize 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 |
|---|---|
warehouse_list_datasets |
What the caller's role may query, with each dataset's grain and metrics |
warehouse_describe_dataset |
Columns, which are pseudonymized, row policy, and 3 sample rows |
warehouse_query_metrics |
Preferred path. Named metrics by dimensions and time buckets. The SQL is built as a syntax tree, so filter values are never SQL |
warehouse_run_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 pytest
Architecture 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.
Metadata
Release files for warehouse-mcp 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| warehouse_mcp-0.1.0.tar.gz | 4.6 MB | With provenance | Details for warehouse_mcp-0.1.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| warehouse_mcp-0.1.0-py3-none-any.whl | Python 3 | none | any | Details for warehouse_mcp-0.1.0-py3-none-any.whl |
Total release size: 9.2 MB
Release files / warehouse_mcp-0.1.0.tar.gz
| Download URL | warehouse_mcp-0.1.0.tar.gz |
|---|---|
| Size | 4.6 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
5570c0f3a96e7f53eaaebf2e9e0931083f91ac2dc6e5e7e0fd97a914061d75e5
|
|
BLAKE2b-256 checksum How to use checksums |
6dc736fc50b2286403da17e1e0838f4fe069207fb745cb608c6515e86f02e705
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 1, 2026.
Transparency logRelease files / warehouse_mcp-0.1.0-py3-none-any.whl
| Download URL | warehouse_mcp-0.1.0-py3-none-any.whl |
|---|---|
| Size | 4.6 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
c357fa5ec1a8fda5425e5915b3cf4e20a516e1a805fb7b2b1eefdb11c74eebfb
|
|
BLAKE2b-256 checksum How to use checksums |
01ebc47f34c7e2f5017b046c255e599ad9035feb62b972e6ea80891885e43b19
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 1, 2026.
Transparency logSecurity for warehouse-mcp 0.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for warehouse_mcp-0.1.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 1, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.