LABSCO SUMMARY

The catalog queries a DBA keeps in a snippets file, already written and already filterable.

All 38 tools read a statistics or catalog view, so aiming this at production costs a query rather than a change. The maintenance group is the strongest part: one vague symptom splits into per-table bloat ratios, distance from the autovacuum threshold, vacuums in flight, and a comparison of manual against automatic vacuum effectiveness. Start with the server-info call — it reports the version and which of the two monitoring extensions are actually installed, which decides how much of the query analysis you get.

What it is

A read-only operations console over a live PostgreSQL server, wrapping the pg_stat_* catalogs, lock and replication views and the pg_stat_statements and pg_stat_monitor extensions in 38 tools. It covers PostgreSQL 12 through 18 and adapts its queries to the version it finds.

What you get

Lock contention read as blocked-and-blocking pairs, filterable by granted status, lock type, mode, session state or username
Bloat broken into the four questions it actually splits into: per-table ratios, a schema-wide overview, distance from each table's autovacuum trigger, and which vacuums are running right now
Query cost rankings by total execution time, and per-execution detail with client IP and time buckets where pg_stat_monitor is installed
Buffer-cache behaviour at three levels — database, table and index hit ratios — with the source view chosen to match the server version
Replication and WAL state together: sender and receiver processes, standby lag, replication slots, WAL generation rate and archiving lag
Schema reads that go past column types — foreign keys in both directions, inheritance and partition relationships, and index usage with unused indexes called out
Sizing from either end: databases ranked by disk usage, and tables in a schema ranked by heap plus index size
Newer server features where they exist — the wait-event catalogue and WAL summarizer on 17, async I/O and per-backend statistics on 18 — with a version notice instead of an error below that

Requirements

Python 3.12, uv, and a reachable server: POSTGRES_HOST, POSTGRES_PORT, POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB. Every tool reads a statistics or catalog view, so an ordinary role with read access to them is enough — granting pg_read_all_stats is the clean way to give it that. RDS and Aurora work; pg_stat_monitor is not available on managed engines, and pg_stat_statements has to be preloaded and created before the query-analysis tools answer. Function statistics need track_functions set, and I/O timing is more accurate with track_io_timing on. Point it at several servers by registering it once per server. MIT.

Setup effort

One command plus credentials — pip install mcp-postgresql-ops, then supply credentials

See installation options

USE CASES

Finding out what is blocking a write

Read the locks as blocked-and-blocking pairs rather than a flat list, check which sessions are actually doing something, and rule out a maintenance operation holding the table.

get_lock_monitoringget_active_connectionsget_running_vacuum_operations

Deciding whether a table needs a manual VACUUM

Compare the table's dead tuple ratio against its own autovacuum trigger point, read when it was last vacuumed and analysed, and check the same question across the whole database before scheduling anything.

get_table_bloat_analysisget_autovacuum_statusget_vacuum_analyze_statsget_database_bloat_overview

Ranking queries before an optimisation sprint

Take the queries that consume the most total time, look at recent executions in detail where the monitoring extension is present, and check whether the indexes meant to serve them are being scanned at all.

get_pg_stat_statements_top_queriesget_pg_stat_monitor_recent_queriesget_index_usage_stats

Working out where the disk went

Rank databases by disk usage first, then narrow to the schema and see heap against index size per table, with access statistics to say whether the biggest tables are the busy ones.

get_database_size_infoget_table_size_infoget_all_tables_stats

Checking a standby is keeping up

Read replication connections and standby lag, confirm WAL is being generated and archived at the rate you expect, and look for query conflicts if the replica is dropping queries.

get_replication_statusget_wal_statusget_database_conflicts_stats

Arriving on a server nobody documented

Establish the version and which monitoring extensions are installed, list the databases, read the configuration that differs from what you assume, and pull the schema of the tables you are about to be asked about.

get_server_infoget_database_listget_postgresql_configget_table_schema_info

38 tools

Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.

`get_active_connections`

[Tool Purpose]: Retrieve all active connections and session information on current PostgreSQL server

[Exact Functionality]:

Retrieve list of all currently active connected sessions
Display user, database, and client address for each connection
Include session status and currently executing query information

[Required Use Cases]:

When user requests "active connections", "current sessions", "connection status", etc.
When server load or performance problem diagnosis is needed
When checking connection status of specific users or applications

[Strictly Prohibited Use Cases]:

Requests for forceful connection termination or session management
Requests for detailed query history of specific sessions
Requests for connection security or authentication-related changes

Returns: Information including PID, username, database name, client address, status, and current query

INSTALLATION

Connect your client

Server setup

TERMINAL

pip install mcp-postgresql-ops

MCP Clients

Claude Desktop — uvx

CLAUDE DESKTOP — UVX · JSON

{
  "mcpServers": {
    "mcp-postgresql-ops": {
      "command": "uvx",
      "args": [
        "--python",
        "3.12",
        "mcp-postgresql-ops"
      ],
      "env": {
        "POSTGRES_HOST": "127.0.0.1",
        "POSTGRES_PORT": "15432",
        "POSTGRES_USER": "postgres",
        "POSTGRES_PASSWORD": "changeme!@34",
        "POSTGRES_DB": "ecommerce"
      }
    }
  }
}

These env values are the project's built-in test database (the docker-compose container on port 15432 with password changeme!@34 and the ecommerce sample database). To read your own PostgreSQL, POSTGRES_HOST, POSTGRES_PORT, POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB take its host, port, login and database.

Open WebUI — mcpo proxy

OPEN WEBUI — MCPO PROXY · TERMINAL

git clone https://github.com/call518/MCP-PostgreSQL-Ops.git
cd MCP-PostgreSQL-Ops
cp .env.example .env

Edit .env only if you connect your own PostgreSQL instead of the built-in test container: POSTGRES_HOST, POSTGRES_PORT, POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB

OPEN WEBUI — MCPO PROXY · TERMINAL

docker-compose up -d

Wait 2-3 minutes, open http://localhost:3003/ and log in with an admin account

Go to Settings → Tools and enter the postgresql-ops Tool address, e.g. http://localhost:8003/postgresql-ops

Any MCP client — HTTP

ANY MCP CLIENT — HTTP · TERMINAL

pip install mcp-postgresql-ops

Set POSTGRES_HOST, POSTGRES_PORT, POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB for the database it should read

ANY MCP CLIENT — HTTP · TERMINAL

mcp-postgresql-ops --type streamable-http --auth-enable --secret-key my-test-secret-key-12345

my-test-secret-key-12345, in the command and after Bearer in the block, is a sample; yours is a secret key of your own. The server listens on 127.0.0.1:8000 unless you pass --host and --port; <YOUR_SERVER> is that host

ANY MCP CLIENT — HTTP · JSON

{
  "mcpServers": {
    "mcp-postgresql-ops": {
      "type": "streamable-http",
      "url": "http://<YOUR_SERVER>:8000/mcp",
      "headers": {
        "Authorization": "Bearer my-test-secret-key-12345"
      }
    }
  }
}

Clients spell the "type" value differently: Claude Code and VS Code use "http", Cline uses "streamableHttp", and Roo Code uses "streamable-http". Claude Desktop does not accept a URL entry in its config file; remote servers go under Settings → Connectors.

PostgreSQL-Ops MCP

The catalog queries a DBA keeps in a snippets file, already written and already filterable.

What it is

What you get

Requirements

Setup effort

Finding out what is blocking a write

Deciding whether a table needs a manual VACUUM

Ranking queries before an optimisation sprint

Working out where the disk went

Checking a standby is keeping up

Arriving on a server nobody documented

38 tools

get_active_connections

get_all_tables_stats

get_async_io_status

get_autovacuum_activity

get_autovacuum_status

get_bgwriter_stats

get_current_database_info

get_database_bloat_overview

get_database_conflicts_stats

get_database_list

get_database_schema_info

get_database_size_info

get_database_stats

get_index_io_stats

get_index_usage_stats

get_io_stats

get_lock_monitoring

get_per_backend_io_stats

get_pg_stat_monitor_recent_queries

get_pg_stat_statements_top_queries

get_postgresql_config

get_prompt_template

get_replication_status

get_running_vacuum_operations

get_server_info

get_table_bloat_analysis

get_table_io_stats

get_table_list

get_table_relationships

get_table_schema_info

get_table_size_info

get_user_functions_stats

get_user_list

get_vacuum_analyze_stats

get_vacuum_effectiveness_analysis

get_wait_events

get_wal_status

get_wal_summarizer_status

What to know first

Tools you get

Requires

Moderate Standing cost

Connect your client

Server setup

MCP Clients

Claude Desktop — uvx

Open WebUI — mcpo proxy

Any MCP client — HTTP

Same category

MySQL Multi-Database MCP Server

Rails PG Extras MCP

Quanti: connectors MCP

Data Pilot (Snowflake)

`get_active_connections`

`get_all_tables_stats`

`get_async_io_status`

`get_autovacuum_activity`

`get_autovacuum_status`

`get_bgwriter_stats`

`get_current_database_info`

`get_database_bloat_overview`

`get_database_conflicts_stats`

`get_database_list`

`get_database_schema_info`

`get_database_size_info`

`get_database_stats`

`get_index_io_stats`

`get_index_usage_stats`

`get_io_stats`

`get_lock_monitoring`

`get_per_backend_io_stats`

`get_pg_stat_monitor_recent_queries`

`get_pg_stat_statements_top_queries`

`get_postgresql_config`

`get_prompt_template`

`get_replication_status`

`get_running_vacuum_operations`

`get_server_info`

`get_table_bloat_analysis`

`get_table_io_stats`

`get_table_list`

`get_table_relationships`

`get_table_schema_info`

`get_table_size_info`

`get_user_functions_stats`

`get_user_list`

`get_vacuum_analyze_stats`

`get_vacuum_effectiveness_analysis`

`get_wait_events`

`get_wal_status`

`get_wal_summarizer_status`