Locksmith

io.github.cxk280Published by GitHub account cxk280v0.1.1Updated Oct 24, 2026

Lints PostgreSQL migrations for dangerous locking operations and suggests safe rewrites.

VerifiedSTDIODesktop onlyDatabasesDeveloper Tools

Overview

AI-generated overview

Locksmith lints PostgreSQL migrations for dangerous locking operations, returning a PASS/REVIEW/BLOCK verdict with findings and safe rewrites.

What you can do
Analyze a PostgreSQL migration and get a verdict, per-statement findings and suggested safe rewrites, with an option to assume large tables. Explain what a given Postgres lock mode blocks and what takes it. Read reference resources for the table-level lock compatibility matrix and the full rule catalog. Use a review-migration prompt to summarize migration risk as a PR comment.
When to use it
Useful when an assistant reviews or drafts PostgreSQL schema migrations and you want a deterministic, repeatable check for locking hazards before a deploy, rather than relying on the model's own reasoning about lock semantics.
Requirements
Runs locally over stdio via npx from the npm package locksmith-mcp; Node.js is needed. No accounts, API keys, environment variables or network access are required.
Before you install
Advisory only, not a proof of safety; it errs toward flagging and unparseable statements degrade to a manual-review note. Inline disable comments can suppress rules, including all rules for the next statement. It only reads the SQL you give it and does not modify your database.

Installation

In SourceWeft

  1. Open Locksmith in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

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

RuleSeverityWhat it catches
create-index-non-concurrentcriticalCREATE INDEX without CONCURRENTLY (blocks writes)
index-concurrently-in-transactioncriticalCONCURRENTLY inside BEGIN/COMMIT (Postgres rejects it)
add-column-not-null-no-defaultcriticalADD COLUMN NOT NULL with no default (fails / rewrites)
alter-column-typecriticalALTER COLUMN ... TYPE (full table rewrite)
add-column-volatile-defaultwarningADD COLUMN ... DEFAULT now() etc. (rewrites table)
set-not-nullwarningSET NOT NULL (full scan under exclusive lock)
add-foreign-key-validatingwarningADD FOREIGN KEY without NOT VALID (locks both tables)
add-check-constraint-no-not-validwarningADD CHECK without NOT VALID (full scan)
drop-column-or-tablewarningdestructive + breaks deployed code
rename-column-or-tablewarningbreaks running app code

Suppressing a rule

Acknowledge a deliberate risk inline, eslint-style:

sql
-- locksmith:disable create-index-non-concurrentCREATE 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:

bash
npx locksmith-mcp

Use with Claude Code

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

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

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

Run from source instead

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

Try it with the MCP Inspector

bash
npx @modelcontextprotocol/inspector npx -y locksmith-mcp

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

Development

bash
npm run dev    # run from source with tsxnpm 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

Source: README.md at commit 8707022

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.1.1LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts