Postgres MCP Pro
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_API_KEY | No | Optional API key for streamable HTTP authentication | |
| DATABASE_URI | No | Postgres connection URI (legacy, alternative to individual POSTGRES_* variables). Example: postgresql://user:password@host:5432/dbname | |
| POSTGRES_HOST | No | Postgres host | |
| POSTGRES_PORT | No | Postgres port (default 5432) | 5432 |
| OPENAI_API_KEY | No | Optional OpenAI API key for experimental index tuning by LLM | |
| MCP_ALLOWED_HOSTS | No | Comma-separated list of allowed hosts for DNS rebinding protection (streamable HTTP) | |
| POSTGRES_DATABASE | No | Postgres database name | |
| POSTGRES_PASSWORD | No | Postgres password | |
| POSTGRES_SSL_MODE | No | Postgres SSL mode (e.g., disable, require, verify-full). Default is disable. | disable |
| POSTGRES_USERNAME | No | Postgres username | |
| MCP_ALLOWED_ORIGINS | No | Comma-separated list of allowed origins for DNS rebinding protection (streamable HTTP) | |
| MCP_DISABLE_DNS_REBINDING | No | Set to 'true' to disable DNS rebinding protection (not recommended for production) | false |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_schemasA | List all schemas in the database |
| list_objectsC | List objects in a schema |
| get_object_detailsB | Show detailed information about a database object |
| explain_queryA | Explains the execution plan for a SQL query, showing how the database will execute it and provides detailed cost estimates. |
| analyze_workload_indexesB | Analyze frequently executed queries in the database and recommend optimal indexes |
| analyze_query_indexesA | Analyze a list of (up to 10) SQL queries and recommend optimal indexes |
| analyze_db_healthA | Analyzes database health. Here are the available health checks:
|
| get_top_queriesA | Reports the slowest or most resource-intensive queries using data from the 'pg_stat_statements' extension. |
| execute_sqlB | Execute any SQL query |
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 9 tools
Tools are mostly distinct with clear purposes. The main potential confusion is between analyze_workload_indexes and analyze_query_indexes, which both recommend indexes but differ by input source (workload vs. explicit query list). Other tools like list_schemas, list_objects, and get_object_details build a clear hierarchy.
All tool names follow a consistent verb_noun pattern in lowercase snake_case (e.g., explain_query, list_schemas, analyze_db_health). The verbs (explain, list, get, analyze) are appropriate for their actions and the naming is uniform throughout the set.
With 9 tools, the server is well-scoped for PostgreSQL database analysis and optimization. Each tool covers a distinct aspect (schemas, objects, query plans, indexes, health, top queries, execution) without unnecessary bloat, fitting the typical ideal range.
The tool set provides strong coverage for common PostgreSQL diagnostic workflows: exploring schemas/objects, explaining queries, analyzing indexes, identifying top queries, and running health checks. Minor gaps include lack of direct table bloat analysis and no management tools (e.g., vacuum or reindex), but these are not core to the server's apparent read/analysis focus.