The case it is built for is the folder of exports — customers.csv, last month's orders, a regions.json someone emailed over — turned into one queryable source an agent can join across without an ETL step. Everything is materialised into memory and validated read-only, so the worst an agent can do is ask an expensive question.
A Python server that loads a data directory into an in-memory DuckDB, exposes each file as its own table, and runs read-only SQL — joins across files included — against it.
- Each CSV, TSV, Parquet, JSON or NDJSON file in the directory exposed as a SQL table
- Read-only analytical SQL across all of them at once, joins between files included
- The data directory as the only visible path — out-of-sandbox paths and raw file-access functions are rejected
- Queries validated read-only, so an agent cannot write through it
- Server details reported back on request
- Two dependencies, `mcp` and `duckdb`, fully typed and tested
`uvx tablebridge` or `pip install tablebridge`, a recent Python, and TABLEBRIDGE_DATA_DIR pointing at the folder of files. A Dockerfile is in the repository if you would rather run it that way.
One command — uvx tablebridge
