Postgres MCP Server

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, MongoDB, and Redis. 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.

01What this is, and what it is not

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 a dozen narrow tools (list_tables, describe_table, get_row, run_select, count_where, explain_plan, ...) plus a guarded run_write that requires Touch ID on every call.

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.

What it is

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

What it is not

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 $79 Standard license.

02Setting up the MCP server for Postgres

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.

Transport

stdio (local)

Tool count

12 read + 2 write

Latency

sub-50ms per tool call

03Example flows from Claude Code and Cursor

Schema introspection

List tables in the orders schema

You ask

“Show me all the tables in the orders schema, sorted by row count.”

Model calls

list_tables(schema: "orders", sort: "rows_desc")

QueryDeck returns

13 tables: line_items (4.2M), orders (1.8M), shipments (1.1M), refunds (380K), ...

Targeted read

Find the slowest queries on a table

You ask

“What were the 5 slowest queries on the orders table in the last 24h?”

Model calls

run_select(query: "SELECT query, mean_exec_time ... pg_stat_statements WHERE query LIKE '%orders%' ORDER BY mean_exec_time DESC LIMIT 5")

QueryDeck returns

Returns 5 rows with mean_exec_time, calls, and the query text. The model can then call explain_plan on the worst one.

Plan analysis

Why is this query slow?

You ask

“Run EXPLAIN ANALYZE on the orders dashboard query and tell me what to fix.”

Model calls

explain_plan(query: "...")

QueryDeck returns

Returns the JSON plan plus the model's read of it: Seq Scan on line_items (cost=0..43k), suggested index on (order_id, created_at).

Guarded write

Apply a fix (requires Touch ID)

You ask

“Add the index you suggested.”

Model calls

run_write(query: "CREATE INDEX CONCURRENTLY ...") → Touch ID prompt → confirm modal in QueryDeck

QueryDeck returns

Index created. The CREATE statement and the resulting row count are appended to the QueryDeck query history for audit.

04Safety architecture

Read-only default

Reads do not need approval. Writes always do.

The MCP server exposes run_select, count_where, explain_plan, and the introspection tools without confirmation. The model can browse your data freely. Anything that mutates (run_write, run_ddl) is behind a separate tool that requires Touch ID and surfaces a diff modal in the QueryDeck UI before executing.

Per-connection scope

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.

Production tagging

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.

05Concept preview

Concept preview · ships with v1.0 launch on 2026-07-21

QueryDeck's MCP inspector shows every tool call from the model live, with the SQL it ran, the rows it touched, and the latency.

06Same MCP server, four more databases

MCP for

MySQL

Same tool surface, MySQL syntax.

→

MCP for

SQLite

Local file connections welcome.

→