Skip to main content

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.

ci python mcp license

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 table t;
  • 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:

  1. 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.
  2. A single huge row skipped the result cap. The fix halves the longest text cells until the row fits.
  3. 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:

  1. 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.
  2. 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 as comment AS c loses 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)

Source distribution for warehouse-mcp 0.1.0
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)

Table of built distributions (wheels) for warehouse-mcp 0.1.0
File Interpreter ABI Platform Actions
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 log

Release 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 log

Security 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.

Select from 2 files

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 log

A 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.

Release history Release notifications | RSS feed

This release

0.1.0 This release

2 release files Full provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page