Postgres MCP Server
Provides comprehensive PostgreSQL database management capabilities including query execution, schema management, transaction handling, user administration, permissions management, performance monitoring, and database maintenance operations.
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., "@Postgres MCP Servershow me the top 10 customers by total purchase amount"
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.
Postgres MCP Server
MCP server for PostgreSQL database management and operations, built with a sophisticated enterprise-grade architecture.
Quick Setup
1. Installation
npm install
npm run build2. Claude Desktop Configuration
Add this to your Claude Desktop claude_desktop_config.json:
Windows:
{
"mcpServers": {
"postgres": {
"command": "node",
"args": ["C:\\path\\to\\postgres-mcp\\dist\\index.js"],
"env": {
"DATABASE_URL": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}macOS/Linux:
{
"mcpServers": {
"postgres": {
"command": "node",
"args": ["/path/to/postgres-mcp/dist/index.js"],
"env": {
"DATABASE_URL": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}3. Environment Configuration
Option A: Via Claude Desktop config (recommended)
{
"mcpServers": {
"postgres": {
"command": "node",
"args": ["/Users/itsalfredakku/McpServers/postgres-mcp/dist/index.js"],
"env": {
"DATABASE_URL": "postgresql://postgres:password@localhost:5432/mydb",
"POOL_MAX": "20",
"LOG_LEVEL": "info"
}
}
}
}Option B: Using .env file
Create .env in the project root:
DATABASE_URL=postgresql://username:password@localhost:5432/dbname
POOL_MAX=10
LOG_LEVEL=infoFeatures
Database Operations: Query, insert, update, delete operations
Schema Management: Create, alter, drop tables and indexes
Transaction Management: Begin, commit, rollback transactions
Connection Management: Advanced connection pooling
Data Management: Import/export, backup/restore operations
Monitoring: Performance metrics and query analysis
Admin Operations: User management, permissions, database administration
Installation
npm installConfiguration Options
Database Connection
# Required - Primary connection string
DATABASE_URL=postgresql://username:password@localhost:5432/dbname
# Alternative - Individual connection parameters
POSTGRES_HOST=localhost
POSTGRES_PORT=5432
POSTGRES_USER=postgres
POSTGRES_PASSWORD=your_password
POSTGRES_DATABASE=your_database
POSTGRES_SSL=falseConnection Pool Settings
POOL_MIN=2 # Minimum connections
POOL_MAX=10 # Maximum connections
POOL_IDLE_TIMEOUT=30000 # Idle timeout (ms)
POOL_ACQUIRE_TIMEOUT=60000 # Acquire timeout (ms)Performance & Caching
CACHE_ENABLED=true # Enable query result caching
CACHE_TTL=300000 # Cache TTL (ms)
LOG_LEVEL=info # Logging level (error|warn|info|debug)
SQL_LOGGING=false # Log SQL queriesUsage
Development
npm run devProduction
npm run build
npm startTesting
npm run test
npm run test:queriesTools
Database Operations
query- Execute SQL queries with transaction support, explain plans, analysistables- List, create, alter, drop tables with detailed metadataschemas- FULLY IMPLEMENTED Create, drop, list schemas and manage permissionsindexes- FULLY IMPLEMENTED Create, drop, analyze, reindex with usage statistics
Data Management
data- Insert, update, delete operations with bulk supporttransactions- Begin, commit, rollback with savepoint support
Administration & Security
admin- FULLY IMPLEMENTED Complete database administration and maintenancepermissions- Complete user/role/privilege managementsecurity- SSL, authentication, encryption, auditingmonitoring- Performance metrics and analysisconnections- Connection pool management
Schema Management Features ✅
Schema Operations: Create, drop, list all schemas
Permission Management: View and manage schema-level permissions
Owner Management: Set schema ownership during creation
Conditional Operations: IF EXISTS, IF NOT EXISTS support
System Schema Filtering: Distinguish between user and system schemas
Index Management Features ✅
Index Operations: Create, drop, list, reindex indexes
Performance Analysis: Analyze index usage statistics
Unused Index Detection: Find indexes that are never used
Multiple Index Types: Support for btree, hash, gist, gin, brin
Concurrent Operations: Create and reindex with CONCURRENTLY
Size Monitoring: Index size tracking and reporting
Database Administration Features ✅
Database Information: Complete database stats and configuration
User Management: Create, drop, list users with detailed privileges
Permission Control: Grant/revoke permissions on tables and schemas
Maintenance Operations: VACUUM, ANALYZE, REINDEX with options
System Monitoring: Connection counts, database size, uptime tracking
Configuration Access: View database settings and parameters
Architecture
The server follows a modular architecture with:
Configuration Management - Environment and file-based configuration
Connection Pooling - Advanced PostgreSQL connection management
Domain APIs - Separated concerns for different database operations
Validation - Comprehensive parameter validation
Error Handling - Robust error handling with retries
Caching - Intelligent caching for performance
Logging - Structured logging with Winston
Troubleshooting
Common Issues
Connection Refused
# Check if PostgreSQL is running
brew services list | grep postgresql
# or
sudo systemctl status postgresql
# Test connection manually
psql -h localhost -p 5432 -U postgres -d your_databasePermission Denied
-- Grant necessary permissions
GRANT CONNECT ON DATABASE your_database TO your_user;
GRANT USAGE ON SCHEMA public TO your_user;
GRANT CREATE ON SCHEMA public TO your_user;MCP Server Not Found
Ensure the path in
claude_desktop_config.jsonis absoluteVerify
npm run buildcompleted successfullyCheck that
dist/index.jsexists
Debug Mode
Set environment variables for detailed logging:
{
"mcpServers": {
"postgres": {
"command": "node",
"args": ["/path/to/postgres-mcp/dist/index.js"],
"env": {
"DATABASE_URL": "postgresql://user:pass@localhost:5432/db",
"LOG_LEVEL": "debug",
"SQL_LOGGING": "true"
}
}
}
}Database Permissions Setup
Full Admin Access
For complete database management capabilities, ensure your PostgreSQL user has appropriate privileges:
-- Connect as superuser (postgres)
psql -U postgres
-- Create a dedicated MCP user with admin privileges
CREATE USER mcp_admin WITH PASSWORD 'secure_password';
ALTER USER mcp_admin SUPERUSER;
ALTER USER mcp_admin CREATEDB;
ALTER USER mcp_admin CREATEROLE;
ALTER USER mcp_admin REPLICATION;
-- Or grant specific privileges without superuser
CREATE USER mcp_user WITH PASSWORD 'secure_password';
GRANT ALL PRIVILEGES ON DATABASE your_database TO mcp_user;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO mcp_user;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO mcp_user;
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public TO mcp_user;
-- Grant schema usage and creation
GRANT USAGE, CREATE ON SCHEMA public TO mcp_user;
-- Allow user management (requires elevated privileges)
ALTER USER mcp_user CREATEROLE;Using MCP Permission Tools
Once connected, you can use the MCP server to manage permissions:
// List all users and their privileges
await mcpServer.callTool('permissions', { operation: 'list_users' });
// Create a new user
await mcpServer.callTool('permissions', {
operation: 'create_user',
username: 'newuser',
password: 'password123',
attributes: { createdb: true, login: true }
});
// Grant all privileges to a user
await mcpServer.callTool('permissions', {
operation: 'grant_all_privileges',
username: 'newuser',
database: 'mydatabase'
});
// Check user permissions
await mcpServer.callTool('permissions', {
operation: 'check_permissions',
username: 'newuser'
});License
MIT
Available Tools
11 toolsadminC
Database administration: users, permissions, database info, maintenance operations
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Admin operation to perform | |
| username | No | Username (required for user operations) | |
| password | No | Password (required for create_user) | |
| permissions | No | Permissions to grant/revoke | |
| tableName | No | Table name (for permission operations) | |
| options | No | Operation options |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'administration' implies mutation capabilities (e.g., create_user, drop_user), the description doesn't specify required permissions, whether operations are reversible, potential side effects, or error handling. For a tool with multiple destructive operations and no annotation coverage, this is a significant gap in transparency.
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 that lists key domains without unnecessary elaboration. It's appropriately sized for the tool's complexity and front-loads the core purpose. However, it could be slightly more structured by separating domains with clearer formatting or bullet points for better readability.
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?
Given the tool's high complexity (6 parameters, multiple destructive operations, no output schema, and no annotations), the description is insufficient. It doesn't address behavioral aspects like authentication needs, side effects, or return formats. For an administration tool with potentially irreversible operations, more context about safety and usage is required to be complete.
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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no parameter-specific information beyond the high-level domains listed. It doesn't explain parameter relationships or provide additional context beyond what's in the schema, resulting in the baseline score of 3 for adequate but non-compensatory coverage.
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 performs 'Database administration' and lists the specific domains (users, permissions, database info, maintenance operations). It uses the verb 'administration' with the resource 'database' and provides scope through the listed domains. However, it doesn't explicitly differentiate from sibling tools like 'permissions', 'security', or 'monitoring' that might overlap in functionality.
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 no guidance on when to use this tool versus alternatives. It lists functional domains but doesn't indicate prerequisites, appropriate contexts, or exclusions. With sibling tools like 'permissions', 'security', and 'monitoring' that might handle similar operations, the lack of differentiation leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connectionsC
Connection pool management: status, statistics, configuration
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: status (pool status), stats (detailed statistics), test (test connection), reset (reset pool) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'management' implies mutation capabilities, the description doesn't specify which actions require special permissions, whether operations are destructive, what side effects might occur (especially for 'reset'), or what the response format looks like. For a tool with potentially destructive operations like 'reset', this is a significant gap.
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 extremely concise - a single phrase with three key areas separated by commas. Every word earns its place, and the structure is front-loaded with the core purpose immediately apparent. No wasted words or unnecessary elaboration.
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 potentially destructive operations (like 'reset') and no annotations or output schema, the description is incomplete. It doesn't explain what 'configuration' means in relation to the available actions, doesn't warn about the implications of 'reset', and provides no information about return values or error conditions. Given the complexity of connection pool management, more context is needed.
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 description coverage is 100%, with the single parameter 'action' having a clear enum description. The description mentions 'status, statistics, configuration' which aligns with the enum values, but doesn't add meaningful semantic context beyond what the schema already provides. The baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose as 'Connection pool management: status, statistics, configuration' - it specifies the resource (connection pool) and the operations (management, status, statistics, configuration). However, it doesn't distinguish this tool from its siblings like 'admin', 'monitoring', or 'security', which might also involve system management functions.
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 no guidance on when to use this tool versus alternatives. With siblings like 'admin', 'monitoring', and 'security' that might overlap with system management functions, there's no indication of when this specific connection pool management tool is appropriate versus those other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dataC
Data operations: insert, update, delete, bulk operations with validation
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: insert (single row), update (modify rows), delete (remove rows), bulk_insert (multiple rows), bulk_update (batch update), truncate (empty table) | |
| tableName | Yes | Table name (required for all actions) | |
| schemaName | No | Schema name (default: public) | public |
| data | No | Data object for insert/update (key-value pairs) | |
| rows | No | Array of data objects for bulk operations | |
| where | No | WHERE conditions for update/delete operations | |
| options | No | Operation options |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions validation but doesn't specify what validation entails, error handling, or performance implications. It lists operations but doesn't describe side effects, atomicity, or rollback behavior. For a tool with multiple mutation actions, this leaves significant gaps in understanding how it behaves.
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 that front-loads the core purpose. It wastes no words but could be slightly more structured by separating operation types from validation. Every element earns its place, though it's borderline terse given the tool's complexity.
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?
Given the tool's high complexity (7 parameters, multiple mutation actions, nested objects) and lack of annotations or output schema, the description is insufficient. It doesn't explain return values, error conditions, or operational constraints. For a multi-action data manipulation tool, this leaves the agent under-informed about critical behavioral aspects.
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 description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema by listing operation types, but doesn't provide additional context about parameter interactions or usage patterns. The baseline score of 3 reflects adequate but not enhanced parameter understanding.
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 performs data operations (insert, update, delete, bulk operations) with validation, which is a specific verb+resource combination. It distinguishes itself from siblings like 'query' or 'tables' by focusing on data manipulation rather than querying or metadata. However, it doesn't explicitly differentiate from all siblings (e.g., 'transactions' might also involve data operations).
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'data' over 'query' for data retrieval, or how it relates to 'transactions' for atomic operations. There's no context about prerequisites, dependencies, or exclusions, leaving the agent to infer usage from the action list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
indexesC
Index management: list, create, drop indexes and analyze index usage
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: list (all indexes), create (new index), drop (remove index), analyze (index statistics), reindex (rebuild index), unused (find unused indexes) | |
| schemaName | No | Schema name (default: public) | public |
| tableName | No | Table name (required for create, list by table) | |
| indexName | No | Index name (required for drop, reindex) | |
| columns | No | Column names for index (required for create) | |
| options | No | Index creation options |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions actions but doesn't describe what 'create' or 'drop' actually do (e.g., whether they're destructive, require permissions, have side effects). It mentions 'analyze index usage' but doesn't explain what that analysis entails or returns. For a multi-action tool with potential destructive operations, this is insufficient behavioral context.
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 that lists all key actions. It's appropriately sized for a multi-action tool and front-loads the core purpose. However, it could be slightly more structured by separating actions with clearer grouping or indicating which are read vs write operations.
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 complex tool with 6 parameters, multiple actions (including potentially destructive ones like 'drop'), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns for different actions, what permissions are needed, or how actions affect database performance. The agent lacks crucial context for proper tool invocation.
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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work, even though the description provides no additional parameter semantics.
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's purpose as 'Index management' with specific actions (list, create, drop, analyze). It provides a verb+resource combination but doesn't explicitly differentiate from sibling tools like 'tables' or 'schemas' that might also involve index operations. The description is specific about what the tool does but lacks sibling differentiation.
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 no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when to choose specific actions, or how this tool relates to sibling tools like 'tables' or 'schemas' that might handle similar operations. The agent receives no usage context beyond the action list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
monitoringC
Database monitoring: performance metrics, statistics, health checks
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes | Metric type to retrieve | |
| timeRange | No | Time range for metrics | 1h |
| limit | No | Maximum number of results |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It implies a read-only operation by mentioning 'retrieval' of metrics, but doesn't specify authentication needs, rate limits, potential side effects, or what the output format looks like (e.g., structured data vs. raw logs). This leaves significant gaps for a monitoring 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 brief and front-loaded with the core purpose, using only one sentence without unnecessary elaboration. However, it could be slightly more structured by explicitly stating it's a retrieval tool (e.g., 'Retrieve database monitoring metrics...') to enhance clarity.
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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the what (monitoring data) but lacks details on behavioral aspects, output expectations, and differentiation from siblings. Without annotations or output schema, more context on what the tool returns would improve completeness.
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 description coverage is 100%, so the schema fully documents all parameters (metric, timeRange, limit) with enums and defaults. The description adds no additional parameter semantics beyond what's in the schema, such as explaining how metrics are aggregated or what 'limit' applies to. This meets the baseline for high schema coverage.
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's purpose as retrieving database monitoring data (performance metrics, statistics, health checks), which is specific and actionable. However, it doesn't distinguish this from potential sibling tools like 'connections' or 'performance' that might overlap in functionality, preventing a perfect score.
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 no guidance on when to use this tool versus alternatives like 'connections' or 'performance' from the sibling list. It mentions general categories (metrics, statistics, health checks) but offers no explicit when/when-not instructions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
permissionsC
Database permissions management: users, roles, grants, privileges
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Permission operation to perform | |
| username | No | Username for user operations | |
| rolename | No | Role name for role operations | |
| password | No | Password for user creation/modification | |
| database | No | Database name for grants | |
| schema | No | Schema name for grants | |
| table | No | Table name for grants | |
| privileges | No | Privileges to grant/revoke | |
| attributes | No | User/role attributes | |
| grantOption | No | Grant with GRANT OPTION |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It mentions 'management' which implies mutations, but doesn't specify required permissions, whether operations are reversible, potential side effects, or error conditions. For a tool with 16 diverse operations including destructive ones like 'drop_user', this is inadequate.
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 extremely concise - a single phrase that efficiently communicates the tool's domain and scope. Every word earns its place, with no redundant or unnecessary information. The structure is front-loaded with the core purpose.
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 complex permissions management tool with 10 parameters, 16 operations including destructive ones, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects, return values, error handling, or the relationship between different operations. The agent would struggle to use this tool correctly without significant trial and error.
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 schema has 100% description coverage, so parameters are well-documented in the schema itself. The description adds minimal value by listing resource types (users, roles, grants, privileges) which helps contextualize the operation parameter, but doesn't provide additional syntax, format, or constraint details beyond what the schema already specifies.
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's purpose as 'Database permissions management' and lists the key resources involved (users, roles, grants, privileges). It provides a specific domain and scope, though it doesn't explicitly differentiate from sibling tools like 'security' or 'admin' which might have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when to choose specific operations, or how it relates to sibling tools like 'security' or 'admin' that might handle related tasks. The agent must infer usage from the operation enum alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
queryC
Execute SQL queries with transaction support, query analysis, and performance monitoring
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: execute (single query), transaction (multiple queries), explain (execution plan), analyze (performance), validate (syntax), cancel (query by PID), active (list active queries) | |
| sql | No | SQL query to execute (required for execute, explain, analyze, validate actions) | |
| parameters | No | Query parameters for parameterized queries | |
| queries | No | Array of queries for transaction action | |
| options | No | Query execution options | |
| pid | No | Process ID of query to cancel (required for cancel action) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'transaction support, query analysis, and performance monitoring', it doesn't address critical behavioral aspects: whether queries can modify data, authentication requirements, rate limits, error handling, or what happens with long-running queries. For a tool with multiple actions including potentially destructive operations, this is insufficient.
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 extremely concise - a single sentence that efficiently communicates the core functionality and key features. Every word earns its place: 'Execute SQL queries' establishes the primary purpose, while 'with transaction support, query analysis, and performance monitoring' efficiently lists additional capabilities without redundancy or unnecessary elaboration.
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 complex tool with 6 parameters, multiple actions (including potentially destructive ones like 'execute'), no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, security implications, or how the different actions relate to each other. The single sentence description fails to provide sufficient context for safe and effective use of this multi-faceted tool.
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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions general capabilities but provides no additional context about parameter usage, relationships between parameters, or practical examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Execute SQL queries' with additional capabilities like 'transaction support, query analysis, and performance monitoring'. It specifies the verb ('Execute') and resource ('SQL queries'), but doesn't explicitly differentiate from sibling tools like 'transactions' or 'monitoring' which might have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. With sibling tools like 'transactions', 'monitoring', 'admin', and 'data', there's no indication of which scenarios call for this multi-action query tool versus those specialized tools. The description only lists capabilities without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
schemasC
Schema management: list, create, drop schemas and manage schema permissions
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: list (all schemas), create (new schema), drop (remove schema), permissions (schema permissions) | |
| schemaName | No | Schema name (required for create, drop, permissions) | |
| owner | No | Schema owner (for create action) | |
| options | No | Action-specific options |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions actions like 'drop' (which implies destructive operations) and 'permissions' (which implies access control), it doesn't describe critical behavioral traits such as required permissions, whether operations are reversible, potential side effects of dropping schemas, or rate limits. The description is too high-level to guide safe usage.
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 concise and front-loaded, consisting of a single, efficient sentence that summarizes the tool's scope. There's no wasted text, and it immediately communicates the key actions. However, it could be slightly more structured by separating actions or adding brief context.
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?
Given the complexity of schema management (including destructive operations like 'drop'), lack of annotations, and no output schema, the description is insufficient. It doesn't address critical aspects such as error handling, return values, or security implications, leaving significant gaps for an AI agent to understand how to use the tool safely and effectively.
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 100% description coverage, with clear documentation for all parameters and their purposes. The description adds minimal value beyond the schema—it lists the same actions (list, create, drop, permissions) but doesn't provide additional context like parameter dependencies or usage examples. Since schema coverage is high, the baseline score of 3 is appropriate.
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's purpose as 'Schema management: list, create, drop schemas and manage schema permissions', which includes specific verbs (list, create, drop, manage) and the resource (schemas). However, it doesn't explicitly distinguish this tool from sibling tools like 'tables' or 'permissions', which might have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. It lists actions but doesn't specify prerequisites, constraints, or when to choose this over sibling tools like 'permissions' or 'tables'. There's no mention of when-not-to-use scenarios or explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
securityC
Database security management: SSL, authentication, encryption, auditing
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Security operation to perform | |
| table | No | Table name for RLS operations | |
| policy_name | No | RLS policy name | |
| policy_expression | No | RLS policy expression | |
| audit_type | No | Type of audit information |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'management' implies both read and write operations, the description doesn't clarify which operations are read-only versus mutative, what permissions are required, whether operations are destructive, or what the response format looks like. For a security tool with potentially sensitive operations, this is a significant gap.
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 extremely concise - a single phrase listing the tool's scope. Every word earns its place, with no redundant information. The structure is front-loaded with the core purpose followed by specific domains. This is an excellent example of efficient communication.
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 security management tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the tool's behavior, response format, or operational constraints. While the schema covers parameter mechanics, the description fails to provide the contextual understanding needed for an agent to use this tool effectively in security scenarios.
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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description mentions security domains that map to the 'operation' enum values (SSL, authentication, encryption, auditing), but doesn't add meaningful semantic context beyond what the schema provides. The baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose as 'Database security management' with specific domains listed (SSL, authentication, encryption, auditing). It distinguishes itself from siblings like 'permissions' or 'admin' by focusing on security aspects, though it doesn't explicitly contrast with them. The verb 'management' is somewhat broad but the listed domains provide good specificity.
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 no guidance on when to use this tool versus alternatives. With siblings like 'permissions', 'admin', and 'monitoring' that might overlap with security concerns, there's no indication of when this specific security tool is appropriate versus those other tools. The description simply lists domains without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tablesC
Table management: list, create, alter, drop tables and get detailed table information
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: list (all tables), info (table details), create (new table), drop (remove table), add_column (add column), drop_column (remove column), rename (rename table) | |
| schemaName | No | Schema name (default: public) | public |
| tableName | No | Table name (required for info, create, drop, add_column, drop_column, rename) | |
| columns | No | Column definitions for create action | |
| columnName | No | Column name (required for add_column, drop_column) | |
| dataType | No | Data type (required for add_column) | |
| newName | No | New name (required for rename action) | |
| options | No | Action-specific options |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It lists actions but doesn't describe their effects (e.g., that 'drop' is destructive, 'create' requires permissions, or how errors are handled). For a complex tool with 8 parameters and no annotations, this leaves critical behavioral traits undocumented.
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 extremely concise—a single, well-structured sentence that efficiently lists all key actions without redundancy. It's front-loaded with the core purpose ('Table management') and uses a colon to enumerate operations, making every word earn its place with zero waste.
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?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral traits, error handling, permissions, or output expectations. While the schema covers parameters well, the description fails to compensate for the absence of annotations and output schema, leaving gaps in contextual understanding.
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 schema description coverage is 100%, providing detailed parameter documentation. The description adds no parameter-specific information beyond the high-level action list, which the schema already covers comprehensively. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't enhance parameter understanding.
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's purpose as 'Table management: list, create, alter, drop tables and get detailed table information', which specifies the verb (manage) and resource (tables) with concrete actions. However, it doesn't differentiate this tool from potential siblings like 'schemas' or 'data' that might also handle table-related operations, preventing a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for choosing specific actions, or how it relates to sibling tools like 'schemas' or 'data'. The agent must infer usage solely from the action parameter, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transactionsC
Transaction management: begin, commit, rollback, savepoints
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: begin (start transaction), commit (commit transaction), rollback (rollback transaction), savepoint (create savepoint), rollback_to (rollback to savepoint), release (release savepoint), status (transaction status) | |
| transactionId | No | Transaction ID (required for commit, rollback, and operations within transaction) | |
| savepointName | No | Savepoint name (required for savepoint, rollback_to, release) | |
| readOnly | No | Start read-only transaction (for begin action) | |
| isolationLevel | No | Transaction isolation level (for begin action) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions actions but doesn't describe side effects (e.g., 'commit' permanently changes data, 'rollback' reverts changes), error handling, concurrency implications, or resource usage. For a transaction management tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise and front-loaded with a single phrase that captures the essence. Every word earns its place by listing key actions without redundancy. It's appropriately sized for a tool with a well-documented schema.
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?
Given the complexity of transaction management (with mutating actions like commit/rollback), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, error conditions, or integration with other tools. For a 5-parameter tool handling critical database operations, this is inadequate.
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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly with descriptions and enums. The description lists action types but doesn't add meaning beyond what the schema provides (e.g., it doesn't explain transaction lifecycle or savepoint usage). Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose as 'Transaction management' with specific actions listed (begin, commit, rollback, savepoints). It uses a verb+resource structure ('management' of 'transactions'), though it doesn't explicitly differentiate from sibling tools like 'query' or 'data' which might also involve transaction operations. The description is specific but lacks sibling differentiation.
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 no guidance on when to use this tool versus alternatives. It lists actions but doesn't indicate context, prerequisites, or relationships with sibling tools like 'query' (which might execute queries within transactions) or 'data' (which might handle data manipulation). There's no mention of when to begin/commit transactions versus using other tools.
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.
11 tool updates
- First observed
admin - First observed
connections - First observed
data - First observed
indexes - First observed
monitoring - First observed
permissions - First observed
query - First observed
schemas - First observed
security - First observed
tables - First observed
transactions
TDQS
Most tools have distinct purposes targeting specific database management areas like connections, data, indexes, and schemas. However, there is some overlap between 'admin' and 'permissions' (both mention user/role management) and 'admin' and 'security' (both cover authentication aspects), which could cause minor confusion for an agent.
All tool names follow a consistent singular noun pattern (e.g., admin, connections, data, indexes) without mixing conventions. This predictability makes it easy for an agent to understand and navigate the tool set.
With 11 tools, this server is well-scoped for comprehensive Postgres database management, covering administration, operations, monitoring, and security. Each tool earns its place by addressing a distinct aspect of the domain.
The tool set provides complete coverage for Postgres management, including CRUD operations (data), schema and table management, indexing, monitoring, security, and transaction support. There are no obvious gaps, enabling agents to handle full database workflows.
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
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Your Supabase account in natural language: run SQL, apply migrations, manage tables, storage, edge f
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Ask questions in plain language, get answers from your business database. No SQL required.
1
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/itsalfredakku/postgres-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server