locksmith

Locksmith 🔒

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.

🛑 BLOCK — do not ship as written

## 🛑 CREATE INDEX without CONCURRENTLY  `create-index-non-concurrent` (line 5)
> `CREATE INDEX idx_users_email ON users (email)`
Problem: This index build will block all writes to the table until it completes.
Lock taken: SHARE (blocks writes)
Fix: Build the index with CREATE INDEX CONCURRENTLY, which does not block writes.
Suggested rewrite:
  CREATE INDEX CONCURRENTLY idx_users_email ON users (email)

Why an MCP server?

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.

Capabilities

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 catalog

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

Suppressing a rule

Acknowledge a deliberate risk inline, eslint-style:

-- locksmith:disable create-index-non-concurrent
CREATE INDEX idx_users_email ON users (email);

A bare -- locksmith:disable suppresses all rules for the next statement.

Install & run

No clone or build required — run it straight from npm:

npx locksmith-mcp

Use with Claude Code

claude mcp add locksmith -- npx -y locksmith-mcp

Or add to any MCP client config (Claude Desktop, etc.):

{
  "mcpServers": {
    "locksmith": { "command": "npx", "args": ["-y", "locksmith-mcp"] }
  }
}

Run from source instead

git clone https://github.com/cxk280/locksmith.git && cd locksmith
npm install && npm run build
# then point your client at:  node /absolute/path/to/locksmith/dist/index.js

Try it with the MCP Inspector

npx @modelcontextprotocol/inspector npx -y locksmith-mcp

Then call analyze_migration with the contents of examples/dangerous.sql.

Development

npm run dev    # run from source with tsx
npm test       # vitest: per-rule + golden tests on examples/

Design notes

• Deterministic. No clock, randomness, or network — same SQL in, same verdict out. That's what makes it testable and safe to drop into CI.
• Hybrid parsing. Statements are parsed to an AST (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.
• Composable rules. Each rule is a pure function with its own metadata in its own file; adding one is a one-file change plus a line in the registry.
• Advisory, not a prover. Locksmith complements review; assumeLargeTables defaults to true so it errs toward flagging.

Roadmap

• Remote (Streamable HTTP) transport for hosted deployments.
• Additional dialects (MySQL, SQLite).
• Optional live DB introspection to suppress findings on known-small tables.
• A GitHub Action wrapping the same engine to gate PRs.

License

MIT