An MCP server for Postgres that does not hand the LLM a blank check.
A Postgres MCP server for Claude Code and Cursor that is read-only by default, scoped to one connection, and project-aware via your ORM schema.
QueryDeck ships a built-in MCP server for PostgreSQL, MySQL, SQLite, and MongoDB. One config block exposes your database as typed tools for Claude Code, Cursor, and any MCP client. Read-only by default, scoped to one connection, project-aware via your ORM schema.
Native macOS. Local stdio. No telemetry. $79 once.
An MCP (Model Context Protocol) server lets LLM clients like Claude Code and Cursor call typed tools instead of guessing at your data. The QueryDeck Postgres MCP server is the same MCP server you would expect from a database tool, with one design choice that I made deliberately: it is not a single run_sql(query) escape hatch.
Most database MCP servers expose one giant tool that takes arbitrary SQL. That puts the entire safety story on the model. If Claude misreads your intent or hallucinates a DELETE, you have no defense in depth. The QueryDeck server splits the surface into typed introspection tools (get_schema, check_drift, search_schema, explain_query, plus four Mongo-specific tools) that cover the common reads without writing SQL, alongside a single execute_query for arbitrary SQL that is read-only by default and requires explicit opt-in for writes.
The result: reads feel frictionless (you ask Cursor a question about your data, it answers), and writes feel like writes (you actually approve them). That is the trade I want as someone who runs this thing against my own production databases.
- A local process, spawned by QueryDeck, talking stdio to your MCP client
- A set of typed tools the model can call (introspection, reads, guarded writes)
- Scoped to one connection per server instance
- Aware of your ORM schema if QueryDeck found one in the project
- A hosted service. Your credentials and queries never leave the Mac.
- A single run_sql tool with no constraints
- A way to bypass the QueryDeck connection guards (Touch ID, prod tagging)
- Locked behind a separate price. It is in the Lifetime license ($79 for the first 10 customers, then $149).
In QueryDeck, open the connection you want to expose, open the Connection menu, and pick Enable MCP server. QueryDeck writes a config snippet to your clipboard for your client of choice. The snippet for Claude Code looks like this:
{
"mcpServers": {
"querydeck-orders-prod": {
"command": "qdeck",
"args": ["mcp", "--connection", "orders-prod"],
"env": {
"QDECK_READONLY": "true"
}
}
}
}For Cursor, the format is similar but lives in ~/.cursor/mcp.json. The connection name (orders-prod) matches what you named the connection in QueryDeck. The command is the qdeck CLI that ships with the app. QDECK_READONLY locks the server to read tools only, even if the underlying connection has write permissions.
That is it. Restart your MCP client. Claude Code or Cursor will discover the new tools automatically and start using them when you ask questions about the database.
stdio (local)
8 read + 1 execute
sub-50ms per tool call
Browse the schema without writing SQL
“Show me the tables in this database and their key columns.”
get_schema()
Returns table names, columns, types, and constraints for the active connection. If an ORM was detected (Prisma, Drizzle, TypeORM, Django, Rails), also returns model-to-table mappings so the model uses your code's names, not raw Postgres names.
Spot drift between your ORM and the database
“Is my Prisma schema still in sync with the live database?”
check_drift()
Compares the parsed ORM schema against the live database and reports missing tables, extra columns, type mismatches, and missing indexes. Works for Prisma, Drizzle, TypeORM, Django, and Rails projects.
Why is this query slow?
“Run EXPLAIN ANALYZE on the orders dashboard query and tell me what to fix.”
explain_query(sql: "...", analyze: true)
Returns the execution plan plus the model's read of it: Seq Scan on line_items, suggested composite index. No data leaves the Mac.
Run arbitrary SQL with write protection
“Add the index you suggested.”
execute_query(sql: "CREATE INDEX CONCURRENTLY ...") → write opt-in required
Reads run straight through. Writes are blocked unless write access is explicitly enabled in QueryDeck settings; when enabled, destructive operations surface a confirmation step in the QueryDeck UI. Every executed statement is appended to QueryDeck query history.
Reads do not need approval. Writes always do.
The MCP server exposes get_schema, check_drift, search_schema, and explain_query without confirmation. The model can browse your data freely. The execute_query tool defaults to read-only; allowing writes is an explicit opt-in in QueryDeck settings, and destructive operations surface a confirmation step in the QueryDeck UI before executing.
One MCP server, one database connection.
Each connection in QueryDeck spawns its own MCP server instance, with its own tool surface scoped to that connection's schema. The model literally cannot see tables in another database. If you have a staging Postgres and a prod Postgres, they are two distinct MCP servers and two distinct Cursor configs.
Prod connections light up red and require extra steps.
When a connection is tagged production, even read queries surface a banner in the response (so the model knows it is reading from prod). Writes require Touch ID plus a confirm click. The connection itself stays color-coded red across the QueryDeck UI so you cannot fat-finger it.
QueryDeck's MCP inspector shows every tool call from the model live, with the SQL it ran, the rows it touched, and the latency.
Why most database MCP servers are wrong
An opinionated take on why one-tool run_sql servers are a footgun, and what a project-aware MCP server should look like.
Read the essay →Drift Mode: catch schema drift before prod
QueryDeck compares your Prisma or Drizzle schema against the live database and surfaces every divergence. The MCP server can call into the same parser.
See Drift Mode →What is the Model Context Protocol (MCP)?
MCP is an open protocol from Anthropic that lets LLM clients call structured tools instead of asking the model to imagine API responses. An MCP server exposes a set of tools (functions with typed inputs and outputs). When you wire Claude Code, Cursor, or Claude Desktop to an MCP server, the model can call those tools directly. For a database, MCP turns the LLM from a text generator into something that can introspect schemas and run queries against your actual data.
How is QueryDeck's Postgres MCP server different from running raw SQL through an MCP wrapper?
Most MCP database servers expose one tool: run_sql(query). That puts the entire safety story on the model. QueryDeck splits the surface into typed introspection tools (get_schema, check_drift, search_schema, explain_query) that cover the common read paths without writing SQL, plus a single execute_query for arbitrary SQL that is read-only by default and requires explicit opt-in for writes. The model rarely needs to invent a SQL string to answer a question, and never gets a blank check on writes. Read the longer write-up on why this matters.
Does the QueryDeck MCP server require an internet connection?
No. The MCP server runs as a local process on your Mac. Claude Code, Cursor, and Claude Desktop talk to it over stdio, the same way they talk to filesystem or git MCP servers. Your database credentials never leave your machine, and the queries never transit a third party.
Can I use the MCP server with Cursor and Claude Code at the same time?
Yes. The QueryDeck MCP server is just a process. Both Cursor and Claude Code can spawn their own instance pointed at the same connection. They will not conflict because each reads from its own stdio channel. The QueryDeck app itself can stay running with its UI open while the MCP server is in use.
What about MySQL, SQLite, and MongoDB?
The same MCP server backend speaks all four engines. For Postgres, MySQL, and SQLite the tool surface is identical: get_schema, check_drift, explain_query, search_schema, and execute_query — the underlying queries adapt to the SQL dialect. MongoDB gets four dedicated tools (mongo_list_databases, mongo_list_collections, mongo_find, mongo_aggregate) because the semantics don't map onto SQL.
Is the MCP server read-only by default?
Yes. The default tool surface is read-only. Writes require a Touch ID gate per session, plus an explicit confirm prompt in the QueryDeck UI for any production-tagged connection. The goal is to make destructive operations conscious choices, not a thing that happens because the model misread your intent.
Do I need a paid Claude or Cursor plan for this to work?
MCP works on any plan that supports it. As of 2026, Claude Code, Cursor, Claude Desktop, and several IDE plugins ship MCP client support out of the box. QueryDeck does not gate its MCP server behind a separate price; it is included in the Lifetime license ($79 for the first 10 customers, then $149).
Wire your Postgres into Claude Code in 2 minutes.
Launch offer: Lifetime at $79 for the first 10 customers, then $149. Try it free for 14 days, no card required.