dryrun

Install

Works with Claude Code, Codex, VS Code, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.

npx agentmarket install connector/boringsql-dryrun

About

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list, install config and code. Checked Oct 25, 2026.

Tools

9 read · 0 write · 0 delete · 3 not yet classified

Secrets

None asked for

Install scripts

None found

Runs as

Node.js package

Tools (12)

Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].

• advise
• check_drift

  When a migration may have run since the snapshot, or before acting on an offline answer that is expensive to get wrong: compares the live database against the newest snapshot in the local history and reports ahead, behind, or diverged with the objects that differ, naming the baseline it used. Requires a connection, so it is absent in offline mode. Read-only: it refreshes nothing (`dryrun snapshot capture` does) and changes nothing.

• check_migration

  Before any ALTER TABLE, CREATE INDEX, DROP, or other DDL reaches a database: the lock level each statement takes, whether it rewrites the table, and rollback_ddl where one applies. Tables created earlier in the same input are recognized as empty, so statements against them are not flagged for scans or rewrites they cannot cause. Where the safe form is mechanical it returns safer_sql -- the rewrite as statements to run in order, each on its own rather than wrapped in one transaction. When at least one statement is unsafe and every unsafe statement has one, migration_sql bundles the whole input …

• columnar_report

  AlloyDB only, when a scan should be served by the columnar engine and is not: resident columns, empty column store, stale blocks, with findings. Needs a live AlloyDB connection: it errors on stock PostgreSQL and is absent in offline mode. Read-only; it populates and configures nothing.

• describe_table

  Before writing SQL against a table you have not read in this session, before a JOIN, or before a DELETE that might cascade: one table in full -- its columns and types, constraints, indexes, and planner stats. Needs no database connection; answers from the snapshot, and points at detect when the table has findings. detail=relations gives the incoming and outgoing foreign keys, each with a JOIN clause you can paste and the ON DELETE / ON UPDATE action it carries (declared constraints only, one hop, so a table reached by a cascade may cascade further). detail=stats adds vacuum: dead tuples, trigg…

• detect

  When a query got slow, before a tuning change, when autovacuum or dead tuples come up, or when asked what is wrong with this database: stale statistics, unused indexes, bloated indexes and tables, per-table scan anomalies, and vacuum health. kind=vacuum_health reports autovacuum_disabled, default_knobs_large_table, high_dead_tuple_ratio, vacuum_threshold_too_high, freeze_age_high and mxid_age_high, each with the dead-tuple counts and last (auto)vacuum and analyze times behind it. Every kind reports offenders only: a table with nothing wrong does not appear, here or in kind=all. For a table wit…

• explain_query

  When you need the real plan for one query: runs EXPLAIN against the connected database. analyze=true runs EXPLAIN ANALYZE, which EXECUTES the query inside a transaction that is always rolled back -- writes do not persist, but their work and any triggers still run. Planner GUCs are replayed via SET LOCAL for plan parity where the snapshot captured them, so the query runs under them (e.g. prod work_mem); older snapshots carry none and get the server's own settings. Requires a connection, so it is absent in offline mode. It returns the plan; pass it to advise as plan_json to have it interpreted.

• find_objects

  First call against an unfamiliar database, and the way to find where a name lives. With no query it inventories what exists and how big it is in production -- row estimates and table size (the heap: indexes and TOAST are not counted), partition children folded into their parent -- which the repo cannot tell you; kind= inventories views, functions or enums instead. With a query it searches names, table and column comments, index and view definitions, and enum labels, so a value like 'cancelled' finds the enum that carries it, not just an object named after it. Every hit is tagged with the field…

• lint_schema

  When reviewing a schema as a whole -- a design review, an inherited database, or the state a migration left behind: naming and convention violations plus an audit of missing keys, unindexed foreign keys, and unsafe defaults. Needs no database connection. Defaults to verbosity='summary', which returns per-rule counts only: pass verbosity='full' for the findings and their ddl_fix (not every finding has one). Whole-schema, not per-query (validate_query, advise); it applies nothing.

• list_top_queries

  When asked what this database spends its time on: captured pg_stat_statements query shapes ranked by exec time, calls, or mean. Needs no database connection; reads the local history (dryrun snapshot capture --streams query, or init's best-effort capture) and is empty when no capture carries query stats. Each entry is tagged with its reporting node and never averaged across nodes: a primary and a replica are different workloads. A node label that rotates between servers reports only the server that answered its newest capture; _meta.hint says so when the captures show it. SQL is qshape-normaliz…

• snapshot_diff

  When something changed and you need to know what: the schema DDL delta between two snapshots, plus planner sizing, activity, and query-shape drift correlated to the same capture window. Query deltas are per shape over that window, so their mean is comparable across captures -- unlike pg_stat_statements' own since-reset mean. Needs no database connection, but does need two snapshots in the local history. Snapshot-to-snapshot only, never against the live database (check_drift); it reports what moved, not why. Totals are a delta over the interval between the two anchors, not a rate: capture caden…

• validate_query

  Before proposing or running any SQL: checks it against the snapshot and reports unknown tables, unknown columns on qualified references (t.col), and anti-patterns. When every unknown name has exactly one candidate it also returns corrected_sql -- the same query with those names replaced, re-validated -- so a misspelling comes back as a patch rather than prose. Needs no database connection and never executes the query. Names and shape only: not cost, not plan, not whether any rows match (advise, explain_query).

Signals

Stars

36

Forks

4

Open issues

11

Weekly downloads

60

Last commit

Oct 11, 2026 (19 days ago)

Last release

Oct 25, 2026 (5 days ago)

Last package publish

Oct 5, 2026 (25 days ago)

From GitHub (fetched Oct 24, 2026) and the package registry.

Details

Registry name

io.github.boringSQL/dryrun

Version

0.20.0

Auth

No auth

Packages

npm @boringsql/dryrun

License

BSD-2-Clause

Repository

github.com/boringSQL/dryrun

Website

boringsql.com/products/dryrun/

First seen

Oct 24, 2026

Last checked

Oct 26, 2026

Source

Official MCP Registrygithub-graphql