dbprint MCP server

dbprint

Write down once what your database means, next to your code, and every agent session reads it.

Your coding agent reads your migrations and your models, so it gets the shape of your database right. What it gets wrong is everything the shape does not say: that revenuecents is gross and every report uses the net column, that status is spelled two ways, that orders joins shipments one-to-many more often than anyone expects, that legacyuid has been dead since the migration. A colleague would tell it in thirty seconds. Without a database connection the agent cannot find out. With one, it rediscovers the same facts live, every session — queries that cost your warehouse time and budget and cost the agent tokens — and can still read them wrong: a count does not say that a code is dead or that a column is gross.

dbprint turns that knowledge into plain text committed in your repository:

• It measures the database once. Each table's DDL, its joins — declared, and inferred where the schema declares none — and per-column statistics: null shares, complete value lists with every spelling, ranges, distributions, value shapes and more. On any of eight engines.
• An agent writes down what the numbers mean. dbprint annotate hands an agent one table's measurements and the questions they leave open — what a code means, what a sentinel date stands for, which rows a report leaves out — and the agent answers them from your code and read-only queries, into files dbprint never overwrites. dbprint annotate --check flags a note the data contradicts.
• Every later session reads it offline. Through an MCP server, a packaged skill or dbprint context, with no database connection and no credentials at the agent. Because it is text in git, a schema or data change shows up in review, and dbprint check gates it in CI.

With dbprint, agents get more answers right, for less. In our tests across multiple codebases, coding agents reading an annotated print got 80% fewer answers wrong than without one, at 17% lower cost per correct answer — and 90% fewer on questions whose catch only the print stated.

What your agent reads

An excerpt of dbprint context --purpose query on a table from the reference print in this repo — the fragment an agent gets before it writes SQL:

# Table: arboretum.seedbank.germination_trial  (900 rows, 8 columns)

## Joins
- accession_id -> arboretum.seedbank.accession.accession_id (declared)
- collector_id -> arboretum.seedbank.collector.collector_id (inferred)

## Data dictionary

One row per germination attempt run against a batch drawn from an accession.

## Column values

| Column | Values (count) | Coverage | Nulls |
|---|---|---|---|
| medium | 'moist filter paper' (176), 'sterile grit' (176), 'vermiculite mix' (176), 'agar medium' (175), 'sand tray' (176) {'sand tray' (151), 'Sand Tray' (25)}, 'control' (21) = 'No growth medium: a no-treatment control group, its germinated_count compared against ambient conditions rather than a physical medium.' | 100% - the list is the whole domain |  |

Shortened. The full README is on GitHub.