guarded-postgres-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PG_HOST | Yes | PostgreSQL host for connection settings. | |
| PG_PORT | No | PostgreSQL port for connection settings. | 5432 |
| PG_USER | Yes | PostgreSQL user for connection settings. | |
| PG_DATABASE | Yes | PostgreSQL database name for connection settings. | |
| PG_PASSWORD | Yes | PostgreSQL password for connection settings. | |
| GUARD_ENV_FILE | No | Loads another env file (for example a staging database) without touching the production one. The server refuses to start if the file does not exist, rather than falling back to whatever PG_* the client has. | .env |
| GUARD_MAX_ROWS | No | Rows a single write statement may change without i_understand: true. | 1000 |
| GUARD_BLOCK_DROP | No | Only the literal false disables it. | true |
| PG_LOCK_TIMEOUT_MS | No | An ALTER TABLE waiting on a lock would queue every ERP session behind it. | 5000 |
| PG_APPLICATION_NAME | No | How the agent's sessions show up in pg_stat_activity. | guarded-postgres-mcp |
| GUARD_AUDIT_LOG_PATH | No | Absolute path of the JSONL audit log. Parent directories are created. Default: unset, no audit. | |
| GUARD_QUERY_MAX_ROWS | No | Rows query returns. | 1000 |
| GUARD_BLOCK_MANUAL_PK | No | Only the literal false disables it. | true |
| PG_CONNECT_TIMEOUT_MS | No | Gives up connecting instead of hanging when the database is down. | 10000 |
| PG_STATEMENT_TIMEOUT_MS | No | Server-side statement timeout (0 disables it). | 120000 |
| GUARD_LEGACY_TABLE_PREFIX | No | Legacy sequence convention: table prefix. With either one empty, only serial / identity defaults are detected. | |
| GUARD_LEGACY_SEQUENCE_PREFIX | No | Legacy sequence convention: sequence prefix. With either one empty, only serial / identity defaults are detected. | |
| GUARD_BLOCK_DML_WITHOUT_WHERE | No | Only the literal false disables it. | true |
| PG_IDLE_IN_TRANSACTION_TIMEOUT_MS | No | PostgreSQL 9.6+. Set 0 on older servers, which reject the parameter at connection time. | 60000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| queryA | Runs ONE SELECT/WITH/EXPLAIN inside a READ ONLY transaction that is always rolled back. Statements that modify data are rejected. Returns at most GUARD_QUERY_MAX_ROWS rows (default 1000) and says when the result was cut. Use it for investigation and analysis. |
| executeA | Runs ONE DML/DDL statement (UPDATE, INSERT, DELETE, ALTER, CREATE) in its own transaction, behind guardrails. Blocked: DELETE/UPDATE without their own WHERE (anywhere in the statement), TRUNCATE, DROP (except snapshot tables), ALTER ... DROP COLUMN, DO/CALL, BEGIN/COMMIT, SET and EXPLAIN. Requires i_understand=true when the statement changes more than GUARD_MAX_ROWS rows (default 1000), has a WHERE made only of constants (e.g. WHERE 1=1), or hides DML inside a WITH. Rolled back if it leaves a sequence behind MAX of its key. Commits only when every check passes, and writes an audit log entry. |
| execute_transactionA | Runs several statements inside ONE transaction: all of them commit, or none. Every statement goes through the same checks as execute. The sequence check runs after the last statement, so an INSERT with explicit keys can be followed by its setval. Use it for operations that must be atomic (e.g. backup + delete + insert). |
| snapshot_tableA | Runs CREATE TABLE tmp_[_]_backup_YYYYMMDD AS SELECT * FROM [WHERE ...]. Use it BEFORE a destructive operation so a manual rollback is possible afterwards. The name must fit in 63 bytes. Returns the snapshot table name and the number of rows copied. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a distinct primary role: snapshot_table creates backups, query is read-only, execute runs a single write, and execute_transaction runs multiple atomic writes. The main overlap is between execute and execute_transaction, but the 'ONE statement' vs 'several statements' distinction is clearly stated.
Names are all snake_case, which helps, but the structural pattern is mixed: snapshot_table and execute_transaction are verb_noun, while query and execute are bare verbs. It remains readable but not a fully predictable convention.
Four tools is well-scoped for a guarded Postgres server. Each tool covers a distinct operational need (read, single write, atomic multi-write, pre-destructive snapshot) without redundancy.
Core lifecycle coverage is strong: read, write, atomic write, and backup via snapshot. Minor gaps exist around schema introspection (e.g., listing tables/columns) and an explicit restore-from-snapshot tool, though agents can work around these using query and execute.