✨ What it doesMost LLMs interact with databases by guessing - assuming table names, inventing column names, and writing queries that may fail or expose sensitive data. Postgres MCP solves this by giving the LLM a structured, safe interface to actually understand the database before touching it. Built with
📋 Requirements
🚀 InstallationThere are two ways to use this package. Choose the one that best fits your workflow. Option 1 - No installation (via
|
Key in env |
Points to .env variable |
Example value |
|---|---|---|
MCP_KEY_URL |
DATABASE_URL |
postgresql://user:pass@host:5432/db?sslmode=require |
MCP_KEY_HOST |
DB_HOST |
db.example.supabase.co |
MCP_KEY_PORT |
DB_PORT |
5432 |
MCP_KEY_NAME |
DB_NAME |
postgres |
MCP_KEY_SSLMODE |
DB_SSLMODE |
require |
MCP_KEY_USER |
DB_USER |
readonly_user |
MCP_KEY_PASS |
DB_PASS |
secret |
Priority: when
MCP_KEY_URL(orDATABASE_URL) is present, the server uses the URL directly and ignores the individual credential keys.
This indirection lets you use any variable name in your .env - useful when sharing a .env across multiple services with different naming conventions.
🔧 args - tool selection via tool= prefix
Each enabled MCP tool is declared as a separate argument in the format tool=<name>:
"args": [
"-y",
"@edelciomolina/postgres-mcp",
"tool=pg_manage_schema",
"tool=pg_manage_indexes"
]
This makes the tool list explicit and auditable directly in mcp.json - no hidden configuration files. 🔍
🔗 Connection via URL (DATABASE_URL)
In addition to individual credentials, you can provide a full connection string - the standard format on platforms like Supabase, Neon, and Railway.
.env:
DATABASE_URL=postgresql://user:password@host:5432/database?sslmode=require
mcp.json:
{
"servers": {
"Postgres Tools": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@edelciomolina/postgres-mcp"],
"env": {
"MCP_KEY_URL": "DATABASE_URL"
}
}
}
}
The variable mapped by MCP_KEY_URL has priority over the other keys (MCP_KEY_HOST, MCP_KEY_PORT, etc.). If the URL is present, the other variables are ignored.
If the platform uses a different name (e.g. DB_URL), just adjust the mapping:
"MCP_KEY_URL": "DB_URL"
🛡️ Why read-only is the default
If you omit all tool= arguments, the server starts with a curated read-only set - all tools that can retrieve, analyze, or explain data, but nothing that can modify it.
✅ Included in defaults (read-only):
pg_execute_query pg_manage_query pg_inspect_schema
pg_get_setup_instructions pg_analyze_database
pg_monitor_database pg_debug_database
pg_inspect_database_graph pg_describe_table_semantics
pg_find_related_tables pg_classify_query_risk
💡
pg_execute_queryrejectsINSERT,UPDATE,DELETE, DDL,ANALYZE,VACUUM,EXPLAIN ANALYZEand other write/maintenance commands before the database is queried.
💡
pg_inspect_schemaprovides read-only schema introspection (get_info,get_enums). For DDL operations, usepg_manage_schemawith explicit opt-in.
⚠️ Excluded from defaults - require tool= argument AND POSTGRES_MCP_ALLOW_WRITE=true:
| Tool | Operations |
|---|---|
pg_manage_schema |
CREATE TABLE, ALTER TABLE, CREATE TYPE |
pg_manage_indexes |
CREATE INDEX, DROP INDEX, REINDEX |
pg_manage_constraints |
ADD CONSTRAINT, DROP CONSTRAINT |
pg_manage_functions |
CREATE FUNCTION, DROP FUNCTION |
pg_manage_triggers |
CREATE TRIGGER, DROP TRIGGER, enable/disable |
pg_manage_rls |
ENABLE/DISABLE RLS, CREATE/ALTER/DROP POLICY |
pg_manage_users |
CREATE/DROP/ALTER USER, GRANT, REVOKE |
pg_execute_mutation |
INSERT / UPDATE / DELETE / UPSERT |
pg_execute_sql |
Arbitrary SQL with transaction support |
📍 .env file discovery
The server resolves the .env file in this order:
env-file=<path>argument - explicit path relative tocwd; takes priority over everything- Upward search - starting from
cwd, searches each parent directory until a.envis found or the filesystem root is reached
If no .env is found, the server exits with a clear error message.
Monorepos and subfolders
When VS Code starts the MCP process, cwd is typically the workspace root. If your .env is in a subfolder (e.g. functions/.env), use env-file= to point to it explicitly:
{
"servers": {
"Postgres Tools": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@edelciomolina/postgres-mcp",
"env-file=functions/.env"
],
"env": {
"MCP_KEY_HOST": "DB_HOST",
"MCP_KEY_PORT": "DB_PORT",
"MCP_KEY_NAME": "DB_NAME",
"MCP_KEY_SSLMODE": "DB_SSLMODE",
"MCP_KEY_USER": "DB_USER",
"MCP_KEY_PASS": "DB_PASS"
}
}
}
}
💡 The upward search behavior handles the common case automatically. Use
env-file=when you need explicit control (CI, monorepos, Docker bind-mounts).
🧰 Available tools
Read-only (enabled by default)
| Tool | Description |
|---|---|
pg_execute_query |
SELECT / COUNT / EXISTS with write and multi-statement guards |
pg_manage_query |
EXPLAIN plans, slow query analysis, pg_stat_statements |
pg_inspect_schema |
Schema info and ENUM types (read-only introspection) |
pg_get_setup_instructions |
Setup instructions per platform |
pg_analyze_database |
Performance, configuration, and storage analysis |
pg_monitor_database |
Real-time monitoring of connections, queries, locks, and replication |
pg_debug_database |
Diagnose connections, locks, performance, and replication |
pg_inspect_database_graph |
Build a full knowledge graph of the database: schemas, tables, columns, FKs, indexes, inferred relations, and business domains |
pg_describe_table_semantics |
Describe a table with semantic context: risk level, column roles, sensitive columns, and related tables |
pg_find_related_tables |
Find tables related to a given table via explicit FKs and inferred naming patterns, with path explanation |
pg_classify_query_risk |
Classify query risk (safe / warning / review / blocked) without executing it |
Write-capable (opt-in via tool= argument + POSTGRES_MCP_ALLOW_WRITE=true)
| Tool | Description |
|---|---|
pg_manage_schema |
Schema info, create/alter tables, manage ENUMs |
pg_manage_indexes |
List, create, drop, reindex, analyze index usage |
pg_manage_constraints |
List, create, and drop constraints and foreign keys |
pg_manage_functions |
List, create, and drop functions and procedures |
pg_manage_triggers |
List, create, drop, enable/disable triggers |
pg_manage_rls |
Row-Level Security policies |
pg_manage_users |
User permissions, create/drop/alter users, grant/revoke |
pg_execute_mutation |
INSERT / UPDATE / DELETE / UPSERT with parameterized queries |
pg_execute_sql |
Arbitrary SQL execution with optional transaction support |
🧠 Semantic Layer
The four pg_*_graph / pg_*_semantics / pg_*_risk tools build an in-memory knowledge graph of your database at runtime. This gives the LLM a structured map - schemas, tables, columns, foreign keys, inferred relations, risk levels, and business domains - without executing any query against your data.
All inferred fields (column semantic roles, table probable types, inferred relations) are clearly tagged so the LLM knows to treat them as hints, not schema facts.
Optional configuration (mcp-config.json)
Place a mcp-config.json file beside your .env to tune the semantic layer and security limits. All fields are optional - omitting the file applies safe defaults.
{
"security": {
"defaultLimit": 100,
"maxLimit": 1000,
"blockedSchemas": ["pg_catalog", "information_schema"],
"blockedTables": [],
"requireLimit": true
},
"semanticLayer": {
"enabled": true,
"inferRelationsWithoutForeignKeys": true,
"inferBusinessEntities": true,
"sensitiveKeywords": ["password", "secret", "token", "api_key", "ssn", "hash"]
}
}
🏗️ Architecture
For a detailed view of the communication flow between the MCP client, the proxy, and PostgreSQL - including the full sequence diagram - see ARCHITECT.md.
📄 License
MIT © Edelcio Molina