PostgreSQL schema intelligence from a committed snapshot. No connection, no credentials.
MCPpedia last refreshed this data
io.github.boringSQL/dryrun is an MCP server that PostgreSQL schema intelligence from a committed snapshot. No connection, no credentials. Its tool list has not been published yet over stdio, sse and http, requires no API key, and scores 62/100 on MCPpedia's security, maintenance and efficiency rubric.
Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"dryrun": {
"args": [
"-y",
"@boringsql/dryrun",
"mcp-serve"
],
"command": "npx"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
The PostgreSQL MCP server that doesn't need connection to the production.
Run this in your terminal to verify the server starts. Then let us know if it worked — your result helps other developers.
npx -y '@boringsql/dryrun' 2>&1 | head -1 && echo "✓ Server started successfully"
After testing, let us know if it worked:
Five weighted categories — click any category to see the underlying evidence.
No known CVEs.
Checked @boringsql/dryrun against OSV.dev.
Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in data / security
Manage Supabase projects — databases, auth, storage, and edge functions
Zero-dependency, token-efficient database MCP server for Postgres, MySQL, SQL Server, MariaDB, SQLite.
🔥 Official Firecrawl MCP Server - Adds powerful web scraping and search to Cursor, Claude and any other LLM clients.
DataForSEO API modelcontextprotocol server
MCP Security Weekly
Get CVE alerts and security updates for io.github.boringSQL/dryrun and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
The PostgreSQL MCP server that doesn't need connection to the production.
dryrun gives AI agents, IDEs, and CI full schema awareness. From offline snapshot, not live database connection. Lint your schema, validate queries, check migration safety, and explore foreign key graphs. All without credentials leaving the DBA's machine.
dryrun is part of the boringSQL suite alongside RegreSQL and Fixturize.
LLM/AI coding assistants are very good in writing code/SQL queries. But they are blind. They don't know your schema, your indexes or your constraints. They might generate a migration that takes an ACCESS EXCLUSIVE lock on your busiest table and send your app down.
Some PostgreSQL MCP server ask you for the database connection. And to perform the administrative tasks you might need SUPERUSER permission. But that's like asking for problem.
We've already seen where this leads: production databases wiped by AI agents, and SQL injection in MCP servers that were supposed to be read-only.
The model doesn't need to query your database. It needs to understand your schema: the structure, constraints, statistics, and version-specific behavior. That knowledge is structural. It changes when you deploy a migration, not between queries.
dryrun is two things: a CLI tool and an MCP server. The CLI extracts and analyzes your schema. The MCP server exposes that analysis to AI assistants. They're separate on purpose.
The CLI connects to your PostgreSQL database, introspects the full catalog (tables, views, indexes, constraints, partitions, functions, enums, RLS policies, triggers, extensions, GUCs), and writes a snapshot into .dryrun/history.db. That snapshot is the source of truth for everything else.
Once you have the snapshot, the CLI works offline:
pg_stat_statements per node, collapses ORM query variants into shapes, diffs two captures to surface new or slowed queriesThe MCP server reads the same snapshot. It exposes 12 tools over stdio or SSE: schema exploration, query validation, plan analysis, migration checks, linting, vacuum health, and captured pg_stat_statements top queries. Three more (explain_query, check_drift, columnar_report) join when a live database is connected. Your AI assistant understands your database while it writes SQL.
No database connection needed. The assistant never sees credentials.
Schema context belongs in a file, not a live connection. Column types, row estimates, index definitions, FK relationships, and PostgreSQL version can all be exported once and committed to the repo. One person with database access dumps the schema. Everyone else, humans and AI agents alike, gets full schema intelligence without credentials.
Credentials shouldn't leave the DBA's machine.