The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Locksmith listing page.
An MCP server that catches dangerous SQL migrations before they lock your database.
Most migrations look harmless and then take down production: a plain CREATE INDEX
blocks every write for the length of the build; ALTER COLUMN ... TYPE rewrites the
whole table under ACCESS EXCLUSIVE; SET NOT NULL scans every row. Which operations
are safe — and the rewrite that makes the dangerous ones safe — is knowledge that
lives in senior engineers' heads.
Locksmith encodes that knowledge as a tool an LLM agent (or a human) can call. Give it a PostgreSQL migration; it returns a PASS / REVIEW / BLOCK verdict, a finding for each risky statement (which lock it takes, why that's dangerous), and a concrete safe rewrite.
An agent can often reason about lock semantics — but not reproducibly, and not in a
way you can test, audit, or trust to gate a deploy unsupervised. The same prompt may
approve a table-rewriting ALTER one run and flag it the next, or miss it entirely in a
long migration. Locksmith turns that probabilistic capability into a deterministic,
tested tool: the lock semantics were verified once (against the PostgreSQL docs and the
parser's real behavior, with a test suite pinning each rule) and now run identically every
time, returning the same verdict plus a paste-ready fix — so "review this migration" stops
being a guess.
Tools
analyze_migration(sql, assumeLargeTables?) → verdict + findings + safe rewrites
(both human-readable Markdown and validated structured output).explain_lock(query) → what a given Postgres lock mode blocks and what takes it.Resources
locksmith://lock-matrix — the PostgreSQL table-level lock compatibility matrix.locksmith://rules — the full rule catalog (id, severity, rationale) as JSON.Prompts
review-migration — analyze a migration and summarize the risk as a PR comment.| Rule | Severity | What it catches |
|---|---|---|
create-index-non-concurrent | critical | CREATE INDEX without CONCURRENTLY (blocks writes) |
index-concurrently-in-transaction | critical | CONCURRENTLY inside BEGIN/COMMIT (Postgres rejects it) |
add-column-not-null-no-default | critical | ADD COLUMN NOT NULL with no default (fails / rewrites) |
alter-column-type | critical | ALTER COLUMN ... TYPE (full table rewrite) |
add-column-volatile-default | warning | ADD COLUMN ... DEFAULT now() etc. (rewrites table) |
set-not-null | warning | SET NOT NULL (full scan under exclusive lock) |
add-foreign-key-validating | warning | ADD FOREIGN KEY without NOT VALID (locks both tables) |
add-check-constraint-no-not-valid | warning | ADD CHECK without NOT VALID (full scan) |
drop-column-or-table | warning | destructive + breaks deployed code |
rename-column-or-table | warning | breaks running app code |
Acknowledge a deliberate risk inline, eslint-style:
A bare -- locksmith:disable suppresses all rules for the next statement.
No clone or build required — run it straight from npm:
Or add to any MCP client config (Claude Desktop, etc.):
Then call analyze_migration with the contents of examples/dangerous.sql.
pgsql-ast-parser) when the
parser supports them; rules fall back to normalized text for Postgres clauses the
parser doesn't model (NOT VALID, CONCURRENTLY). An unparseable statement degrades
to a "review manually" note — the linter never fails closed on input it doesn't
understand.assumeLargeTables defaults
to true so it errs toward flagging.MIT