@yawlabs/postgres-mcp 0.5.3 → 0.5.4

package/CHANGELOG.md

@@ -322,7 +322,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   writes executed by `EXPLAIN ANALYZE`. Previously the write ran inside a
   `BEGIN; ... COMMIT` transaction, so `pg_explain { analyze: true, sql:
   "INSERT ..." }` would actually insert the row. Now writes run inside a
-  `BEGIN; ... ROLLBACK` transaction — the plan (with real row counts and
+  `BEGIN; ... ROLLBACK` transaction - the plan (with real row counts and
   timing) comes back but the mutation is rolled back. This matches the user
   expectation when asking for a plan, and the tool description has been
   updated to reflect it.
@@ -354,7 +354,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - `pg_list_roles` with `includeSystem: false` (the default) now actually
   excludes built-in `pg_*` roles. The previous `LIKE 'pg\_%' ESCAPE '\\'`
   filter ended up as SQL `ESCAPE '\\'` (two backslashes), which Postgres
-  rejects since `ESCAPE` requires a single character — so the whole filter
+  rejects since `ESCAPE` requires a single character - so the whole filter
   was silently being dropped. Replaced with `starts_with(rolname, 'pg_')`.
 - `pg_describe_table` foreign-key `columns` and `foreign_columns` are now
   proper JSON arrays. They were previously returned as the raw postgres
@@ -378,11 +378,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [0.3.0] - 2026-04-22
 
 ### Added
-- `pg_list_views` — list views and materialized views with SQL definitions.
-- `pg_list_functions` — list functions, procedures, and aggregates with signatures.
-- `pg_list_extensions` — list installed extensions (pgvector, postgis, etc.) with versions.
-- `pg_search_columns` — find columns by name pattern across all user schemas.
-- `pg_top_queries` — top N queries by total/mean execution time from
+- `pg_list_views` - list views and materialized views with SQL definitions.
+- `pg_list_functions` - list functions, procedures, and aggregates with signatures.
+- `pg_list_extensions` - list installed extensions (pgvector, postgis, etc.) with versions.
+- `pg_search_columns` - find columns by name pattern across all user schemas.
+- `pg_top_queries` - top N queries by total/mean execution time from
   `pg_stat_statements`. Detects extension version and picks the right column
   names (v1.8+ uses `total_exec_time`, older uses `total_time`). Returns clear
   setup instructions if the extension is not installed.
@@ -404,23 +404,23 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   tool against a real Postgres instance. Gated on `POSTGRES_MCP_INTEGRATION=1`
   so local `npm test` stays fast with no DB required. CI runs it on Linux via
   a `postgres:16` service container with `pg_stat_statements` preloaded.
-- `pg_inspect_locks` — show current blocking locks (blocked PID, blocker PID,
+- `pg_inspect_locks` - show current blocking locks (blocked PID, blocker PID,
   relation, lock type, both queries). First tool to reach for when a session
   hangs or the app feels stuck.
-- `pg_list_roles` — database roles with login/superuser/createdb/createrole
+- `pg_list_roles` - database roles with login/superuser/createdb/createrole
   flags and inherited group memberships.
-- `pg_table_privileges` — who has SELECT/INSERT/UPDATE/DELETE/etc. on a table,
+- `pg_table_privileges` - who has SELECT/INSERT/UPDATE/DELETE/etc. on a table,
   or on all tables in a schema. Useful for pre-migration audits.
-- `pg_seq_scan_tables` — tables with heavy sequential scans relative to index
+- `pg_seq_scan_tables` - tables with heavy sequential scans relative to index
   scans. Missing-index candidates.
-- `pg_unused_indexes` — non-unique, non-primary indexes with low/zero scan
+- `pg_unused_indexes` - non-unique, non-primary indexes with low/zero scan
   counts. Drop candidates (each unused index costs write amplification).
-- `pg_kill` — cancel a running query or terminate a backend by PID. Requires
+- `pg_kill` - cancel a running query or terminate a backend by PID. Requires
   `ALLOW_WRITES=1` since it changes session state. Distinguishes `cancel`
   (SIGINT-equivalent, graceful) from `terminate` (SIGTERM, forceful).
-- `pg_table_bloat` — estimate dead tuples and vacuum-candidate tables from
+- `pg_table_bloat` - estimate dead tuples and vacuum-candidate tables from
   `pg_stat_user_tables`. No extensions required.
-- `pg_replication_status` — replication slots, connected replicas with lag,
+- `pg_replication_status` - replication slots, connected replicas with lag,
   and current WAL position. Returns empty arrays on a standalone DB rather
   than erroring, so it's safe to call unconditionally.
 - New "What can an agent do with this?" README section with concrete example
@@ -452,12 +452,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 Initial release.
 
 ### Added
-- `pg_query` — run SQL with read-only-by-default safety. Writes opt in via `ALLOW_WRITES=1`.
-- `pg_list_schemas` — list non-system schemas.
-- `pg_list_tables` — list tables (and optionally views) with estimated row counts.
-- `pg_describe_table` — columns, PK, FKs, indexes.
-- `pg_explain` — `EXPLAIN` / `EXPLAIN ANALYZE` with text or JSON output.
-- `pg_health` — server version, db size, connections, active queries, table count.
+- `pg_query` - run SQL with read-only-by-default safety. Writes opt in via `ALLOW_WRITES=1`.
+- `pg_list_schemas` - list non-system schemas.
+- `pg_list_tables` - list tables (and optionally views) with estimated row counts.
+- `pg_describe_table` - columns, PK, FKs, indexes.
+- `pg_explain` - `EXPLAIN` / `EXPLAIN ANALYZE` with text or JSON output.
+- `pg_health` - server version, db size, connections, active queries, table count.
 - Single-file bundled distribution (zero runtime deps) for fast `npx` cold starts.
 - Result row truncation at `POSTGRES_MAX_ROWS` (default 1000).
 - Parameterized queries via `params` on `pg_query` and `pg_explain`.

package/README.md

@@ -3,37 +3,37 @@
 [![npm version](https://img.shields.io/npm/v/@yawlabs/postgres-mcp)](https://www.npmjs.com/package/@yawlabs/postgres-mcp)
 [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](https://opensource.org/licenses/MIT)
 
-**Query a PostgreSQL database from Claude Code, Cursor, and any MCP client.** Read-only by default — writes opt in via a single env var — so an agent can't silently drop your tables.
+**Query a PostgreSQL database from Claude Code, Cursor, and any MCP client.** Read-only by default - writes opt in via a single env var - so an agent can't silently drop your tables.
 
 Built and maintained by [Yaw Labs](https://yaw.sh).
 
 ## Backstory
 
-Anthropic's reference Postgres MCP server, `@modelcontextprotocol/server-postgres`, was [archived in May 2025](https://github.com/modelcontextprotocol/servers-archived/tree/main/src/postgres) and [marked deprecated on npm](https://www.npmjs.com/package/@modelcontextprotocol/server-postgres) in July 2025. Anthropic has not shipped a replacement. Despite the deprecation, the last published version (v0.6.2) is still pulled ~20,000 times per week — a lot of agents are pointed at an unmaintained package.
+Anthropic's reference Postgres MCP server, `@modelcontextprotocol/server-postgres`, was [archived in May 2025](https://github.com/modelcontextprotocol/servers-archived/tree/main/src/postgres) and [marked deprecated on npm](https://www.npmjs.com/package/@modelcontextprotocol/server-postgres) in July 2025. Anthropic has not shipped a replacement. Despite the deprecation, the last published version (v0.6.2) is still pulled ~20,000 times per week - a lot of agents are pointed at an unmaintained package.
 
 That unmaintained package also has a known, [publicly documented stacked-query SQL injection](https://securitylabs.datadoghq.com/articles/mcp-vulnerability-case-study-SQL-injection-in-the-postgresql-mcp-server/) (Datadog Security Labs) that bypasses its `BEGIN READ ONLY` wrapper with input like `COMMIT; DROP SCHEMA public CASCADE;`. It has never been patched at npm.
 
 A handful of community forks have appeared, but each fills a narrow slice:
 
-- [`@zeddotdev/postgres-context-server`](https://www.npmjs.com/package/@zeddotdev/postgres-context-server) — Zed's fork, primarily a security patch on the original shape.
-- **Postgres MCP Pro** (Crystal DBA) — focused on index tuning and hypothetical-index / buffer-cache diagnostics.
-- **AWS Labs Postgres MCP** — tied to Aurora / RDS Data API + Secrets Manager.
+- [`@zeddotdev/postgres-context-server`](https://www.npmjs.com/package/@zeddotdev/postgres-context-server) - Zed's fork, primarily a security patch on the original shape.
+- **Postgres MCP Pro** (Crystal DBA) - focused on index tuning and hypothetical-index / buffer-cache diagnostics.
+- **AWS Labs Postgres MCP** - tied to Aurora / RDS Data API + Secrets Manager.
 
 None of them position themselves as a general-purpose daily driver you'd hand to Claude Code or Cursor against an arbitrary Postgres: modern introspection, perf helpers, role/privilege awareness, and a write-safety posture out of the box. That's the gap `@yawlabs/postgres-mcp` fills.
 
 ## Why this one?
 
-- **Read-only by default** — user SQL runs in a `BEGIN READ ONLY` transaction, so postgres itself (not string parsing) blocks writes. Opt in with `ALLOW_WRITES=1`.
-- **Extended query protocol for all user SQL** — `pg_query` sends user input with `queryMode: 'extended'`, which restricts each request to a single statement. This closes the [stacked-query injection class](https://securitylabs.datadoghq.com/articles/mcp-vulnerability-case-study-SQL-injection-in-the-postgresql-mcp-server/) (`COMMIT; DROP SCHEMA x CASCADE;`) that defeated the reference server's `BEGIN READ ONLY` wrapper. Integration test asserts the rejection.
-- **Parameterized queries** — `pg_query` takes a `params` array for `$1`, `$2`, etc. No string-interpolated SQL in our code path.
-- **Written from scratch, actively maintained** — not a fork of the deprecated code. Unit + integration tests (`npm test`, `npm run test:integration`) run against a real Postgres; releases cut via `release.sh`.
-- **Schema introspection built in** — `pg_list_schemas`, `pg_list_tables`, `pg_describe_table` return columns, primary keys, foreign keys, and indexes without the agent having to remember `pg_catalog` joins.
-- **`EXPLAIN` as a first-class tool** — text or JSON format, with optional `ANALYZE`. ANALYZE for non-SELECT statements requires `ALLOW_WRITES=1` and always rolls back, so the plan is real but the write doesn't persist.
-- **Perf diagnostics the deprecated server never had** — `pg_top_queries` (from `pg_stat_statements`), `pg_seq_scan_tables`, `pg_unused_indexes`, `pg_table_bloat`, `pg_inspect_locks`, `pg_replication_status`. Answer "why is this slow?" in one tool call.
-- **Health snapshot** — `pg_health` returns version, db size, connection counts, and the 10 longest-running active queries in one call.
-- **Role and privilege awareness** — `pg_list_roles` and `pg_table_privileges` for the common "who can touch what?" questions.
-- **Instant startup** — ships as a single bundled file with zero runtime dependencies. No multi-minute `node_modules` install on every `npx` cold start.
-- **Result truncation** — large result sets are capped at `POSTGRES_MAX_ROWS` (default 1000) with a `truncated: true` flag, so a stray `SELECT * FROM events` doesn't blow out the model context.
+- **Read-only by default** - user SQL runs in a `BEGIN READ ONLY` transaction, so postgres itself (not string parsing) blocks writes. Opt in with `ALLOW_WRITES=1`.
+- **Extended query protocol for all user SQL** - `pg_query` sends user input with `queryMode: 'extended'`, which restricts each request to a single statement. This closes the [stacked-query injection class](https://securitylabs.datadoghq.com/articles/mcp-vulnerability-case-study-SQL-injection-in-the-postgresql-mcp-server/) (`COMMIT; DROP SCHEMA x CASCADE;`) that defeated the reference server's `BEGIN READ ONLY` wrapper. Integration test asserts the rejection.
+- **Parameterized queries** - `pg_query` takes a `params` array for `$1`, `$2`, etc. No string-interpolated SQL in our code path.
+- **Written from scratch, actively maintained** - not a fork of the deprecated code. Unit + integration tests (`npm test`, `npm run test:integration`) run against a real Postgres; releases cut via `release.sh`.
+- **Schema introspection built in** - `pg_list_schemas`, `pg_list_tables`, `pg_describe_table` return columns, primary keys, foreign keys, and indexes without the agent having to remember `pg_catalog` joins.
+- **`EXPLAIN` as a first-class tool** - text or JSON format, with optional `ANALYZE`. ANALYZE for non-SELECT statements requires `ALLOW_WRITES=1` and always rolls back, so the plan is real but the write doesn't persist.
+- **Perf diagnostics the deprecated server never had** - `pg_top_queries` (from `pg_stat_statements`), `pg_seq_scan_tables`, `pg_unused_indexes`, `pg_table_bloat`, `pg_inspect_locks`, `pg_replication_status`. Answer "why is this slow?" in one tool call.
+- **Health snapshot** - `pg_health` returns version, db size, connection counts, and the 10 longest-running active queries in one call.
+- **Role and privilege awareness** - `pg_list_roles` and `pg_table_privileges` for the common "who can touch what?" questions.
+- **Instant startup** - ships as a single bundled file with zero runtime dependencies. No multi-minute `node_modules` install on every `npx` cold start.
+- **Result truncation** - large result sets are capped at `POSTGRES_MAX_ROWS` (default 1000) with a `truncated: true` flag, so a stray `SELECT * FROM events` doesn't blow out the model context.
 
 ## Quick start
 
@@ -88,7 +88,7 @@ Read-only is the default. If you want the agent to be able to `INSERT`, `UPDATE`
 }
 ```
 
-Prefer scoping this to dev/test databases — for production, leave writes off and use migration tools out-of-band.
+Prefer scoping this to dev/test databases - for production, leave writes off and use migration tools out-of-band.
 
 ## What can an agent do with this?
 
@@ -103,7 +103,7 @@ Once connected, the agent picks tools automatically based on what you ask. A few
 
 The bigger leverage is multi-tool reasoning. A few real workflows:
 
-- **Unstick a hung app.** `pg_inspect_locks` returns blocked PID + blocking PID + the offending query, then `pg_kill` (`ALLOW_WRITES=1` required) cancels the blocker. The agent can run both in one turn — it's the fastest path from "the app is frozen" to "back up."
+- **Unstick a hung app.** `pg_inspect_locks` returns blocked PID + blocking PID + the offending query, then `pg_kill` (`ALLOW_WRITES=1` required) cancels the blocker. The agent can run both in one turn - it's the fastest path from "the app is frozen" to "back up."
 - **Chase a slow page.** `pg_top_queries` ranks the worst queries, `pg_explain` with `analyze: true` shows the plan for the top hit, `pg_seq_scan_tables` and `pg_unused_indexes` say whether the answer is "add an index here" or "drop a dead one there."
 - **Oncall triage.** `pg_health` checks connectivity + active-query count + database size; `pg_inspect_locks` and `pg_replication_status` confirm whether contention or replication lag is in play before paging the on-call DBA.
 
@@ -122,12 +122,12 @@ The bigger leverage is multi-tool reasoning. A few real workflows:
 | `pg_explain` | `EXPLAIN` or `EXPLAIN ANALYZE` for a SQL statement. Text or JSON output. Optional `hypothetical_indexes` (requires the [HypoPG](https://github.com/HypoPG/hypopg) extension) lets you ask "what would the plan be with these indexes?" without creating them on disk. |
 | `pg_health` | Server version, database size, connection count, active queries, table count. |
 | `pg_top_queries` | Top N queries by total/mean execution time. Requires the `pg_stat_statements` extension. |
-| `pg_seq_scan_tables` | Tables with heavy sequential scans — missing-index candidates. |
-| `pg_unused_indexes` | Non-unique, non-primary indexes with low scan counts — drop candidates. |
+| `pg_seq_scan_tables` | Tables with heavy sequential scans - missing-index candidates. |
+| `pg_unused_indexes` | Non-unique, non-primary indexes with low scan counts - drop candidates. |
 | `pg_inspect_locks` | Who is blocking whom right now (blocked PID, blocker PID, lock type, queries). |
 | `pg_list_roles` | Database roles with login/superuser/createdb flags and group memberships. |
 | `pg_table_privileges` | Who has SELECT/INSERT/UPDATE/DELETE/etc. on a table or whole schema. |
-| `pg_table_bloat` | Tables with high dead-tuple ratios — VACUUM candidates. |
+| `pg_table_bloat` | Tables with high dead-tuple ratios - VACUUM candidates. |
 | `pg_replication_status` | Replication slots, connected replicas, and current WAL position. |
 | `pg_advisor` | Rolled-up DBA lints in one call: sequence-exhaustion candidates, tables without a primary key, and (configurable) public tables with RLS disabled. The "what should I be looking at?" starting point. |
 | `pg_kill` | Cancel a running query or terminate a backend connection. Requires `ALLOW_WRITES=1`. |
@@ -171,19 +171,19 @@ This disables certificate chain verification only -- the TCP connection is still
 
 ## Troubleshooting
 
-**`DATABASE_URL is not set`** — Your MCP client is launching the server without the env var. On Windows especially, env vars set in bash / PowerShell profiles are not inherited by MCP servers launched via `cmd`. Put `DATABASE_URL` directly in the `env` block of `.mcp.json`.
+**`DATABASE_URL is not set`** - Your MCP client is launching the server without the env var. On Windows especially, env vars set in bash / PowerShell profiles are not inherited by MCP servers launched via `cmd`. Put `DATABASE_URL` directly in the `env` block of `.mcp.json`.
 
-**`password authentication failed`** — Check the username, password, and that the user has `CONNECT` privilege on the database. URL-encode special characters in the password (`@` → `%40`, `#` → `%23`, `/` → `%2F`).
+**`password authentication failed`** - Check the username, password, and that the user has `CONNECT` privilege on the database. URL-encode special characters in the password (`@` → `%40`, `#` → `%23`, `/` → `%2F`).
 
-**`SASL: SCRAM-SERVER-FIRST-MESSAGE: client password must be a string`** — The password in your connection string is empty or became `null` after URL decoding. Re-check your connection string.
+**`SASL: SCRAM-SERVER-FIRST-MESSAGE: client password must be a string`** - The password in your connection string is empty or became `null` after URL decoding. Re-check your connection string.
 
-**`canceling statement due to statement timeout`** — A single query exceeded `POSTGRES_STATEMENT_TIMEOUT_MS` (default 30s). Increase it, narrow the query with `WHERE`, or add an index. This is working as designed -- the timeout exists so a runaway query cannot hang the agent.
+**`canceling statement due to statement timeout`** - A single query exceeded `POSTGRES_STATEMENT_TIMEOUT_MS` (default 30s). Increase it, narrow the query with `WHERE`, or add an index. This is working as designed -- the timeout exists so a runaway query cannot hang the agent.
 
-**`Write blocked: this server is in read-only mode`** — You asked the agent to write but `ALLOW_WRITES` is not set. Add `ALLOW_WRITES=1` to the `env` block of `.mcp.json` and restart your MCP client. Only do this for dev/test DBs.
+**`Write blocked: this server is in read-only mode`** - You asked the agent to write but `ALLOW_WRITES` is not set. Add `ALLOW_WRITES=1` to the `env` block of `.mcp.json` and restart your MCP client. Only do this for dev/test DBs.
 
-**Connection pool exhaustion with PgBouncer transaction mode or pglite-socket** — These backends don't support concurrent queries on a single connection. Set `POSTGRES_POOL_MAX=1` in the env block.
+**Connection pool exhaustion with PgBouncer transaction mode or pglite-socket** - These backends don't support concurrent queries on a single connection. Set `POSTGRES_POOL_MAX=1` in the env block.
 
-**First query is slow, subsequent queries are fast** — Expected. The pg driver lazily establishes the first connection; subsequent queries reuse the pool.
+**First query is slow, subsequent queries are fast** - Expected. The pg driver lazily establishes the first connection; subsequent queries reuse the pool.
 
 ## Development
 

package/dist/index.js

@@ -36350,7 +36350,7 @@ async function shutdown() {
 var adminTools = [
   {
     name: "pg_inspect_locks",
-    description: "Show current lock contention: which sessions are blocked and who is blocking them. Returns blocked PID, blocking PID, lock types, relation being contested, and the queries involved. Use this first when a tool call hangs or the app feels stuck \u2014 it's the fastest way to identify a long-held transaction holding a lock.",
+    description: "Show current lock contention: which sessions are blocked and who is blocking them. Returns blocked PID, blocking PID, lock types, relation being contested, and the queries involved. Use this first when a tool call hangs or the app feels stuck - it's the fastest way to identify a long-held transaction holding a lock.",
     annotations: {
       title: "Inspect blocking locks",
       readOnlyHint: true,
@@ -36469,7 +36469,7 @@ var adminTools = [
   },
   {
     name: "pg_kill",
-    description: "Cancel a running query (SIGINT-equivalent) or terminate a backend connection (SIGTERM-equivalent) by PID. Find the PID via `pg_health` active_queries or `pg_inspect_locks`. Requires ALLOW_WRITES=1 since this changes database session state. The role in DATABASE_URL must have permission \u2014 cancelling another user's query needs the `pg_signal_backend` role or superuser. Cancel is graceful; terminate is forceful.",
+    description: "Cancel a running query (SIGINT-equivalent) or terminate a backend connection (SIGTERM-equivalent) by PID. Find the PID via `pg_health` active_queries or `pg_inspect_locks`. Requires ALLOW_WRITES=1 since this changes database session state. The role in DATABASE_URL must have permission - cancelling another user's query needs the `pg_signal_backend` role or superuser. Cancel is graceful; terminate is forceful.",
     annotations: {
       title: "Cancel or terminate a backend",
       readOnlyHint: false,
@@ -36499,7 +36499,7 @@ var adminTools = [
           pid,
           mode,
           signaled,
-          note: signaled ? `Sent ${mode === "terminate" ? "SIGTERM" : "SIGINT"} to backend ${pid}.` : `Signal returned false \u2014 PID ${pid} may not exist, may already be gone, or the current role lacks permission.`
+          note: signaled ? `Sent ${mode === "terminate" ? "SIGTERM" : "SIGINT"} to backend ${pid}.` : `Signal returned false - PID ${pid} may not exist, may already be gone, or the current role lacks permission.`
         }
       };
     }
@@ -36654,7 +36654,7 @@ var adminTools = [
   },
   {
     name: "pg_table_bloat",
-    description: "Estimate table bloat (dead tuples + free space) for tables in a schema. Returns live tuples, dead tuples, dead-tuple ratio, last_vacuum / last_autovacuum timestamps, and total relation size. A high dead_ratio with a stale last_autovacuum is a sign a table needs VACUUM. Cheap \u2014 uses `pg_stat_user_tables`, no extensions required.",
+    description: "Estimate table bloat (dead tuples + free space) for tables in a schema. Returns live tuples, dead tuples, dead-tuple ratio, last_vacuum / last_autovacuum timestamps, and total relation size. A high dead_ratio with a stale last_autovacuum is a sign a table needs VACUUM. Cheap - uses `pg_stat_user_tables`, no extensions required.",
     annotations: {
       title: "Estimate table bloat",
       readOnlyHint: true,
@@ -36664,7 +36664,7 @@ var adminTools = [
     },
     inputSchema: external_exports.object({
       schema: external_exports.string().min(1).max(63).optional().describe("Limit to one schema. If omitted, all user schemas are included."),
-      minDeadRatio: external_exports.number().min(0).max(1).default(0.1).describe("Minimum dead-tuple fraction to include \u2014 dead / (live + dead). Default 0.1 = 10%."),
+      minDeadRatio: external_exports.number().min(0).max(1).default(0.1).describe("Minimum dead-tuple fraction to include - dead / (live + dead). Default 0.1 = 10%."),
       limit: external_exports.number().int().min(1).max(200).default(50).describe("Max rows to return (default 50).")
     }),
     handler: async (input) => {
@@ -36755,7 +36755,7 @@ function buildHypopgHooks(indexes) {
 var explainTools = [
   {
     name: "pg_explain",
-    description: "Get the query plan for a SQL statement. By default, this uses plain EXPLAIN (no execution). Set `analyze: true` to run the query with EXPLAIN ANALYZE \u2014 for non-SELECT statements, ALLOW_WRITES=1 is required (since ANALYZE actually executes the statement). Writes executed during EXPLAIN ANALYZE are always rolled back, so you can inspect a plan for an INSERT/UPDATE/DELETE without persisting the mutation. Format is `text` (default) or `json`. Pass the raw SQL (not an EXPLAIN-prefixed statement). Set `hypothetical_indexes` to a list of `{table, columns, using?}` to ask the planner 'what would the plan be if these indexes existed?' -- requires the HypoPG extension (`CREATE EXTENSION hypopg`). The hypothetical indexes are torn down at the end of the call, never touching real disk.",
+    description: "Get the query plan for a SQL statement. By default, this uses plain EXPLAIN (no execution). Set `analyze: true` to run the query with EXPLAIN ANALYZE - for non-SELECT statements, ALLOW_WRITES=1 is required (since ANALYZE actually executes the statement). Writes executed during EXPLAIN ANALYZE are always rolled back, so you can inspect a plan for an INSERT/UPDATE/DELETE without persisting the mutation. Format is `text` (default) or `json`. Pass the raw SQL (not an EXPLAIN-prefixed statement). Set `hypothetical_indexes` to a list of `{table, columns, using?}` to ask the planner 'what would the plan be if these indexes existed?' -- requires the HypoPG extension (`CREATE EXTENSION hypopg`). The hypothetical indexes are torn down at the end of the call, never touching real disk.",
     annotations: {
       title: "Explain query plan",
       readOnlyHint: false,
@@ -36800,7 +36800,7 @@ var explainTools = [
         if (!check2.data?.[0]?.installed) {
           return {
             ok: false,
-            error: "hypothetical_indexes requires the HypoPG extension. Install with `CREATE EXTENSION hypopg;` (a superuser-equivalent role usually). HypoPG is read-only at the disk level \u2014 it lives entirely in shared memory."
+            error: "hypothetical_indexes requires the HypoPG extension. Install with `CREATE EXTENSION hypopg;` (a superuser-equivalent role usually). HypoPG is read-only at the disk level - it lives entirely in shared memory."
           };
         }
       }
@@ -36958,7 +36958,7 @@ var schemaTools = [
   },
   {
     name: "pg_list_tables",
-    description: "List tables (and optionally views) in a schema. Returns name, type (table/view/materialized view/foreign), and estimated row count (from `reltuples`; approximate \u2014 0 until ANALYZE runs). Paginate via `limit`/`offset` on very large schemas.",
+    description: "List tables (and optionally views) in a schema. Returns name, type (table/view/materialized view/foreign), and estimated row count (from `reltuples`; approximate - 0 until ANALYZE runs). Paginate via `limit`/`offset` on very large schemas.",
     annotations: {
       title: "List tables in a schema",
       readOnlyHint: true,
@@ -37413,7 +37413,7 @@ var statsTools = [
   },
   {
     name: "pg_seq_scan_tables",
-    description: "Tables with high sequential-scan counts relative to index scans \u2014 the first place to look for missing-index candidates. Returns seq_scans, idx_scans, live tuples, and the ratio. A high ratio on a large table usually means a query is reading the whole table where an index would suffice. Pair with `pg_top_queries` to find which query is doing it.",
+    description: "Tables with high sequential-scan counts relative to index scans - the first place to look for missing-index candidates. Returns seq_scans, idx_scans, live tuples, and the ratio. A high ratio on a large table usually means a query is reading the whole table where an index would suffice. Pair with `pg_top_queries` to find which query is doing it.",
     annotations: {
       title: "Find tables with heavy sequential scans",
       readOnlyHint: true,
@@ -37454,7 +37454,7 @@ var statsTools = [
   },
   {
     name: "pg_unused_indexes",
-    description: "Indexes that have never been scanned or have very low usage. Each unused index costs write amplification (every INSERT/UPDATE maintains it) and disk space. Excludes primary keys and unique constraints (which are load-bearing even with zero scans). Use this before adding new indexes \u2014 sometimes the fix is to drop a dead one.",
+    description: "Indexes that have never been scanned or have very low usage. Each unused index costs write amplification (every INSERT/UPDATE maintains it) and disk space. Excludes primary keys and unique constraints (which are load-bearing even with zero scans). Use this before adding new indexes - sometimes the fix is to drop a dead one.",
     annotations: {
       title: "Find unused indexes",
       readOnlyHint: true,
@@ -37510,7 +37510,7 @@ function compareVersions(a, b) {
 }
 
 // src/index.ts
-var version2 = true ? "0.5.3" : (await null).createRequire(import.meta.url)("../package.json").version;
+var version2 = true ? "0.5.4" : (await null).createRequire(import.meta.url)("../package.json").version;
 var subcommand = process.argv[2];
 if (subcommand === "version" || subcommand === "--version") {
   console.log(version2);

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@yawlabs/postgres-mcp",
-  "version": "0.5.3",
-  "description": "PostgreSQL MCP server — query, schema introspection, explain, and health checks for AI assistants",
+  "version": "0.5.4",
+  "description": "PostgreSQL MCP server - query, schema introspection, explain, and health checks for AI assistants",
   "license": "MIT",
   "author": "YawLabs <contact@yaw.sh>",
   "repository": {