MCP

PostgreSQL MCP: Inspect the table schema first, then run a read-only query

For people who need to inspect a PostgreSQL schema or run read-only SQL; you must supply a connection string. A read-only transaction still reads the database and may carry a password—it is not zero risk.

Official source · modelcontextprotocol/server-postgres

Install

npx -y @modelcontextprotocol/server-postgres postgresql://localhost/mydb

Who it's for

For people who need a model to inspect a PostgreSQL database's table structure and run read-only SQL. The evidence states: this MCP provides read-only access to PostgreSQL, for inspecting the schema and executing read-only queries.

You must be able to supply a connectable postgresql:// URL, and accept that the model will see table structures and query results. A read-only transaction is not "zero risk": it still connects to the database and still reads data, and the URL can also carry a username and password.

The evidence does not list clients. The official page is in the servers-archived tree; the evidence does not separately state maintenance status, so do not assume it is still the current recommended implementation.

First try in 3 minutes

Take the NPX main path; do not treat Docker as the primary install. In the client's MCP config use:

"command": "npx",
"args": [
  "-y",
  "@modelcontextprotocol/server-postgres",
  "postgresql://localhost/mydb"
]

Replace the last URL with a database you have read-only rights to. Username and password can be written as the evidence shows: postgresql://user:password@host:port/db-name. Do not paste a production write account or a full password into the conversation.

Prerequisites: the machine has npx; the database allows connections from that process; the first time, only inspect the schema or run a query that will not change data.

Where to configure: the client MCP server's command / args. The third argument is the connection string.

Low-risk first call: first read the resource postgres://<host>/<table>/schema to see one table's column names and types; or call the query tool with a sql string—the evidence guarantees it runs in a READ ONLY transaction. Do not try INSERT/UPDATE/DELETE to "verify read-only".

Success signal: after the client connects, it can list table schema resources, or query returns a read-only result. If the connection fails, change the URL first (local database, port, database name); do not switch to Docker and guess. On Docker the evidence only adds: on macOS, if the service is on the host, use host.docker.internal.

Use cases

Case 1: Find out which columns a table has. Read postgres://<host>/<table>/schema. The evidence states this is a JSON schema auto-discovered from database metadata, including column names and data types. There is no table-name enumeration API; replace <host> and <table> with your actual connection. Do not invent tables you cannot see.

Case 2: Run a read-only query on a table you have already confirmed exists. Call query; the only parameter is sql. The evidence guarantees execution in a READ ONLY transaction; it does not document result pagination, timeouts, or the executable SQL dialect range. So what you can confirm is: this SQL is sent as a read-only query into the connected database; do not assume you can write temp tables or call functions that change state.

Limits

This is read-only access, not a recoverable write: the evidence gives no undo. The connection string can contain a password, which is credential and data-plane exposure. The only tool is query. Docker and NPX are different paths; keep NPX as the main path. The evidence does not document connection pooling, SSL, or enforcing a read-only role, and it does not say a READ ONLY transaction blocks every side effect (some SQL functions may still have external effects, but the page does not expand on that). The page lives in an archived repository tree; the evidence does not provide an alternative package or a migration note.