execute_queryLABSCO SUMMARY
Write access with a stop before anything lands.
The difference from a read-only Postgres server is that changes can actually be made; the difference from a psql session is that they sit in an isolated transaction until a separate commit call. Query classification and transaction timeouts mean an abandoned session rolls back rather than leaving work half applied.
What it is
A PostgreSQL MCP server with full read-write access, in contrast to the read-only official one. Queries are classified as DQL, DML, DDL, DCL or TCL, safe reads run with read-only enforced, and everything else runs inside an isolated transaction that has to be committed explicitly — with a timeout and automatic rollback if it is not.
What you get
- Read queries executed with read-only semantics enforced (execute_query)
- INSERT, UPDATE, DELETE and DDL run inside an isolated transaction (execute_dml_ddl_dcl_tcl)
- A two-step commit: nothing lands until it is committed (execute_commit), and it can be abandoned instead (execute_rollback)
- Maintenance operations that cannot run inside a transaction (execute_maintenance)
- Rich schema information: column types and descriptions, max length, nullability, primary keys, foreign key relationships, index type and uniqueness, and row count estimates
- Transaction timeout monitoring with automatic rollback, and configurable safety limits
Requirements
A PostgreSQL connection and a database user whose grants match what you intend to allow — the server's controls sit on top of the database's own permissions, not in place of them. A Docker image is published. Choosing Allow Once rather than Allow Always in Claude Desktop keeps a person in the loop on every write.
Setup effort
One command — npx -y mcp-postgres-full-access postgresql://<YOUR_DB_USER>:<YOUR_DB_PASSWORD>@localhost:5432/<YOUR_DB_NAME>
USE CASES
Answering a question against live data
Read queries run with read-only enforced, so an exploratory question cannot change anything by accident.
Making a data fix with a checkpoint before it is permanent
The change runs in an isolated transaction and stays there until you commit, so you can look at what it did before agreeing to it.
Backing out of a change you did not like
An explicit rollback discards the open transaction, and an abandoned one is rolled back on timeout anyway.
Running maintenance a transaction will not hold
Operations that cannot run inside a transaction have their own path, so they do not fail against the safety wrapper.
Understanding a table you did not design
Column types and descriptions, nullability, primary and foreign keys, indexes and row estimates come back as structured schema information rather than raw DDL.
7 tools
Listed in project docs. Your client may show a different list.
execute_dml_ddl_dcl_tclexecute_maintenanceexecute_commitexecute_rollbacklist_tablesdescribe_tableBEFORE YOU INSTALL
What to know first
Tools you get
7 tools named in the project's documentation.
Requires
npx on PATH
Where it runs
The documented client runs the server on your machine.
INSTALLATION
Connect your client
Server setup
npx -y mcp-postgres-full-access postgresql://<YOUR_DB_USER>:<YOUR_DB_PASSWORD>@localhost:5432/<YOUR_DB_NAME>MCP Clients
Claude Desktop
{
"mcpServers": {
"postgres-full": {
"command": "npx",
"args": [
"-y",
"mcp-postgres-full-access",
"postgresql://<YOUR_DB_USER>:<YOUR_DB_PASSWORD>@localhost:5432/<YOUR_DB_NAME>"
],
"env": {
"TRANSACTION_TIMEOUT_MS": "60000",
"MAX_CONCURRENT_TRANSACTIONS": "5",
"PG_STATEMENT_TIMEOUT_MS": "30000"
}
}
}
}