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.
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.
- 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
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.
One command plus a key — pip install mcp-postgresql-ops, then supply credentials