PostgreSQL MCP Server
Enables querying PostgreSQL databases with read-only access, allowing execution of SELECT statements, table inspection, and database connection testing with built-in security validation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@PostgreSQL MCP Servershow me the last 5 orders from the orders table"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
PostgreSQL MCP Server
An MCP (Model Context Protocol) server for querying a PostgreSQL database. Execute SQL queries, view table details, and manage database connections through MCP-compatible clients.
Key Features
Database Connection: Connect to PostgreSQL databases with authentication
SQL Execution: Execute SELECT queries with security validation
Connection Testing: Test database connection status
Related MCP server: PostgreSQL MCP Server
Installation
Claude Desktop
Follow these steps for installation:
Step 1: Download the MCP Server
Download the postgres-connector.mcpb file from this repository (located in the root directory).
Step 2: Install the MCP Server
Open Claude Desktop
Navigate to Settings > Features
Click "Install Extension" and select the
postgres-connector.mcpbfile
Screenshot placeholder: Installing the .mcpb file
Step 3: Configure Database Connection
After installation, the PostgreSQL Connector will appear in your Claude Desktop with default environment variables that you can configure with your database details.
Screenshot placeholder: Database configuration interface showing environment variables
Step 4: Test the database connection
Send a query "test the database connection"

Configuration
Required Database Settings
You'll need to provide the following information for your PostgreSQL database:
Environment Variable | Description | Required | Default |
POSTGRES_HOST | The hostname or IP address of your PostgreSQL server | ✅ Yes | - |
POSTGRES_PORT | The port number for your PostgreSQL server | ❌ No | 5432 |
POSTGRES_DB | The name of the specific database to connect to | ✅ Yes | - |
POSTGRES_USER | Your PostgreSQL username | ✅ Yes | - |
POSTGRES_PASSWORD | Your PostgreSQL password | ✅ Yes | - |
These environment variables will be automatically available for configuration in the extension settings panel after installing the extension in Claude Desktop.
Available Tools
1. Test PostgreSQL Connection
Tool: test-postgres-connection
Tests your database connection and displays the current configuration (password hidden for security).
Example Output:
✅ Database connection successful!
Configuration:
{
"host": "localhost",
"port": "5432",
"database": "myapp_production",
"username": "postgres",
"password": "***hidden***"
}
Connection test result: [
{
"test": 1
}
]2. Get All Tables
Tool: get-all-tables
Retrieves a list of all tables in the public schema of your database.
Example Output:
[
{
"table_name": "users"
},
{
"table_name": "orders"
},
{
"table_name": "products"
},
{
"table_name": "categories"
}
]3. Execute SQL Query
Tool: execute-sql-query
Executes SELECT queries on your database with security validation.
Input:
sql: The SQL query to execute (SELECT statements only)
Example Usage:
SELECT id, name, email FROM users LIMIT 5;Example Output:
[
{
"id": 1,
"name": "John Doe",
"email": "john@example.com"
},
{
"id": 2,
"name": "Jane Smith",
"email": "jane@example.com"
}
]Security & Safety
SQL Query Validation
The PostgreSQL MCP server includes security measures:
READ-ONLY Operations: Only SELECT statements are permitted
Dangerous Keywords Blocked: DROP, DELETE, TRUNCATE, ALTER, CREATE, INSERT, UPDATE operations are automatically blocked
Statement-Level Validation: Each SQL statement is validated individually
Safe Error Handling: Database errors are caught and displayed safely
Best practice is to create a read-only database user for the postgres connector to use.
Blocked Operations
The following SQL operations are NOT ALLOWED for security:
DROP(deleting tables/databases)DELETE(removing data)TRUNCATE(clearing tables)ALTER(modifying structure)CREATE(creating new objects)INSERT(adding data)UPDATE(modifying data)
Usage Examples
Get Database Tables
Use the get-all-tables tool to retrieve all tables in your database schema.
Execute Queries
Use the execute-sql-query tool with SELECT statements:
SELECT * FROM users LIMIT 10;Troubleshooting
Connection Issues
Problem: "Database connection failed"
Check: Verify your host, port, database name, username, and password
Check: Ensure your PostgreSQL server is running and accessible
Check: Verify that your database user has the necessary permissions
Problem: "Connection timeout"
Check: Your database server might be behind a firewall
Check: The host address and port number are correct
Check: Network connectivity to the database server
Query Issues
Problem: "Dangerous operation detected"
Cause: You're trying to execute a non-SELECT statement
Solution: Only SELECT queries are allowed for security reasons
Problem: "Query execution failed"
Check: Your SQL syntax is correct
Check: The tables and columns you're referencing exist
Check: Your database user has SELECT permissions on the tables
Configuration Issues
Problem: MCP server not appearing in Claude Desktop client
Solution: Restart Claude Desktop
Check: Verify the .mcpb file was installed correctly
Check: Look for any error messages in Claude Desktop's console
Problem: Environment variables not showing up
Solution: Restart Claude Desktop after installation
Check: Ensure the extension is enabled in Settings > Features
Problem: Cannot configure database settings
Solution: Make sure all required environment variables are filled out
Check: Verify your database credentials are correct
Technical Details
System Requirements
PostgreSQL database (version 9.0 or higher)
Network access to your PostgreSQL server
Dependencies
Node.js runtime
PostgreSQL client libraries
MCP (Model Context Protocol) framework
Project Structure
postgres-connector/
├── src/
│ └── server.ts # Main MCP server implementation
├── package.json # Node.js dependencies
├── manifest.json # MCP extension manifest
├── icon.png # Extension icon
└── postgres-connector.mcpb # Compiled extension bundleLicense
MIT License - see the LICENSE file for details.
Author
Marty Markenson
Email: martyamark@gmail.com
LinkedIn: Marty Markenson
Need help? Open an issue in this repository or reach out to martymarkenson
Available Tools
3 toolsexecute-sql-queryExecute SQL QueryA
Execute a SQL query on the database. Only SELECT statements are allowed for security.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | The SQL query to execute |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the SELECT-only constraint but omits behaviors like result format, error handling, or execution limits. This is minimal for a read-only query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It front-loads the purpose and constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers purpose and constraint well. However, it lacks details on output format or error behavior, which would enhance completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning to the 'sql' parameter beyond what the schema provides. Baseline 3 is appropriate as the schema already documents it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'execute', the resource 'SQL query on the database', and a critical constraint 'Only SELECT statements are allowed'. This distinguishes it from siblings like get-all-tables and test-postgres-connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage constraint ('Only SELECT statements') and a reason (security). It implicitly tells when to use (read queries) but doesn't explicitly state when not to or suggest alternatives, though siblings are limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-all-tablesGet All Tables QueryA
Execute SQL queries to get all tables in the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It does not explicitly state the tool is read-only or mention any side effects, and the phrasing 'Execute SQL queries' could mislead about parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple, parameterless tool, but it does not describe the return value format, which is missing since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), so baseline is 3. The description does not add parameter meaning beyond the schema, but it clarifies the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets all tables in the database, with a specific verb and resource. It is distinct from siblings 'execute-sql-query' and 'test-postgres-connection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool lists all tables, but does not explicitly mention when to avoid using it or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test-postgres-connectionTest Postgres ConnectionA
Test the Postgres connection and return connection status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the basic behavior: testing connection and returning status. No annotations are provided, so the description carries the full burden. It lacks details on whether the test modifies state, requires authentication, or has side effects, but for a test tool the behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), and the description adequately communicates its purpose and result. It could elaborate on what 'connection status' entails (e.g., boolean, string), but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), so schema description coverage is 100%. The description does not need to add parameter details, and baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (test) and resource (Postgres connection) and indicates the output (connection status). It effectively distinguishes from siblings: execute-sql-query runs queries and get-all-tables retrieves schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. However, the purpose is self-explanatory as a diagnostic check, so usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v1.0.0- Changed
execute-sql-query2 fields changed- added
Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false
3 tool updates
- First observed
execute-sql-query - First observed
get-all-tables - First observed
test-postgres-connection
TDQS
Each tool has a clearly distinct purpose: executing SELECT queries, listing all tables, and testing connection. There is no overlap.
All tool names follow a consistent verb_noun pattern with snake_case: execute-sql-query, get-all-tables, test-postgres-connection.
Only 3 tools for a PostgreSQL server is extremely limited. Typical servers require many more operations (CRUD, schema management, etc.), making this count too low for the domain.
The server only supports SELECT queries, listing tables, and connection testing. Missing essential operations like INSERT, UPDATE, DELETE, schema inspection, and index management, severely limiting usefulness.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- dataOAuthco.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables interaction with PostgreSQL databases through MCP, allowing users to explore database structures, inspect table schemas, and execute read-only SQL queries.-
- -licenseNot gradedqualityNot gradedmaintenanceEnables users to perform SQL query execution, schema exploration, and performance analysis on PostgreSQL databases through any MCP-compatible client. It prioritizes security with read-only protection by default and provides guided workflows for database documentation and optimization.-
- FlicenseNot gradedqualityBmaintenanceEnables querying PostgreSQL databases via MCP, with multi-database routing, credential isolation, and truncated results plus full CSV export.-
- AlicenseNot gradedqualityCmaintenanceRead-only PostgreSQL MCP server that enables running SELECT queries, listing tables and schemas, and describing columns, with built-in protection against writes and malicious SQL attacks.751MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/martymarkenson/Postgres-Connector-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server