postgres-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DB_SSL | No | Enable SSL connection (default database) | true |
| DB_HOST | No | PostgreSQL host (default database) | 127.0.0.1 |
| DB_NAME | No | Database name (default database) | postgres |
| DB_PORT | No | PostgreSQL port (default database) | 5432 |
| DB_USER | No | Database user (default database) | postgres |
| READ_ONLY | No | Restrict to SELECT/WITH/EXPLAIN queries | true |
| DB_PASSWORD | No | Database password (default database) | |
| MAX_PAGE_SIZE | No | Maximum rows per page | 500 |
| QUERY_TIMEOUT | No | Query timeout in milliseconds | 30000 |
| DB_CONFIG_PATH | No | Path to JSON config file (alternative) | |
| DEFAULT_PAGE_SIZE | No | Default page size when not specified | 100 |
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 |
|---|---|
| queryC | Execute SQL with pagination and parameterization |
| describe_tableB | Get table structure including columns, constraints, and size statistics |
| list_objectsB | List tables, views, or functions in a schema |
| list_schemasB | List all schemas in the database |
| list_indexesB | List indexes for a table or schema |
| explain_queryC | Get query execution plan (EXPLAIN) |
| search_objectsB | Find tables, columns, functions, views by name pattern across schemas |
| get_connectionsB | Show active database connections, utilization, and idle-in-transaction warnings |
| diagnose_databaseB | Composite database health check: cache, connections, vacuum, indexes, sequences |
| get_slow_queriesC | Analyze slow queries via pg_stat_statements with filtering and sorting |
| list_partitionsC | List partitioned tables and monitor partition pruning efficiency (PostgreSQL 12+) |
| replication_statusA | Monitor logical replication: publications, subscriptions, and lag (PostgreSQL 13+) |
| progress_reportB | Monitor progress of VACUUM, ANALYZE, CLUSTER, and CREATE INDEX operations |
| wal_monitorC | Monitor WAL size, growth, archive status, and replication slots |
| extended_statsB | List extended statistics and provide recommendations for multi-column correlations |
| index_dedupB | Identify B-tree indexes that can benefit from deduplication (PostgreSQL 13+) |
| generated_columnsB | List generated columns and monitor their dependencies (PostgreSQL 12+) |
| jsonb_analysisB | Analyze JSONB columns and recommend GIN indexes for better performance |
| parallel_queryC | Monitor parallel query worker usage and performance |
| autovacuum_advisorA | Analyze autovacuum effectiveness and recommend tuning settings |
| huge_pagesB | Monitor huge pages usage and provide configuration recommendations |
| statements_enhancedC | Enhanced pg_stat_statements analysis with parallel workers and WAL tracking |
| foreign_keyB | Monitor foreign key performance and identify missing indexes |
| backup_monitorB | Monitor pg_basebackup progress and PITR recovery timeline |
| extensionsB | List installed extensions, check compatibility, and view dependencies |
| connection_poolB | Monitor HikariCP connection pool metrics, detect connection leaks, and track wait times |
| jpa_mappingC | Validate database schema against JPA/Hibernate entity mappings |
| orm_performanceB | Analyze ORM query performance, detect N+1 problems, and identify lazy loading issues |
| transaction_monitorB | Monitor active transactions, isolation levels, and detect long-running transactions |
| prepared_statementC | Analyze prepared statement cache hit ratio and query patterns |
| migration_trackingB | Track Flyway/Liquibase migrations, detect schema drift, and validate checksums |
| orm_index_coverageB | Analyze index coverage for ORM @Query annotations and recommend missing indexes |
| jsonb_entityB | Analyze JSONB columns for @Convert entity attributes and recommend GIN indexes |
| batch_operationC | Monitor JDBC batch operation performance and efficiency |
| sequence_monitorB | Monitor sequences for JPA @GeneratedValue and detect exhaustion risks |
| timeseries_partitionC | Recommend partitioning strategies for time-series entity tables |
| connection_leakC | Detect connection leaks and analyze connection acquisition patterns |
| deadlock_analysisC | Analyze deadlock patterns and lock wait information |
| jpa_schema_validationB | Validate Spring Data JPA annotations against database schema |
| orm_performance_baselineC | Establish and monitor performance baselines for ORM CRUD operations |
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 40 tools
Several tools have overlapping purposes, such as query, explain_query, get_slow_queries, and statements_enhanced all dealing with query execution and analysis. Similarly, connection_pool, connection_leak, and get_connections all monitor connections, and multiple ORM performance tools blur boundaries despite detailed descriptions.
Naming conventions are mixed: some follow verb_noun (list_objects, describe_table), others are noun_phrases (replication_status, extends_stats), and some use compound adjectives (autovacuum_advisor, statements_enhanced). Long, inconsistent ORM-related names further reduce predictability.
40 tools is excessive for a PostgreSQL monitoring server. Many niche tools (huge_pages, extended_stats, generated_columns) are very specific and could be consolidated into broader diagnostic tools, making the set feel overweighted and harder to navigate.
The tool set covers a wide range of database monitoring and health checks, including queries, schema inspection, index analysis, and replication. However, it lacks administrative actions like vacuum, index creation/dropping, or even EXPLAIN ANALYZE, leaving operational gaps for a server that purports to manage PostgreSQL.