FastPostgresMCP
With this server, you can interact with and manage multiple PostgreSQL databases through a Model Context Protocol (MCP) server, enabling AI agents to execute queries, inspect schemas, and manage transactions.
Query Execution:
Execute read-only SQL queries using
query_toolto safely retrieve resultsExecute data-modifying SQL statements (INSERT, UPDATE, DELETE) using
execute_tool
Database Schema Inspection:
List available tables via
db://{dbAlias}/schema/tablesInspect detailed table schema (columns, types) using
schema_toolordb://{dbAlias}/schema/{tableName}
Transaction Management:
Execute multiple SQL statements as a single atomic transaction with rollback support
Multi-Database Support:
Connect to and manage multiple PostgreSQL databases defined in configuration
Security Features:
Prevent SQL injection via parameterized queries
Optional API Key authentication for network connections
Development Tools:
Built-in CLI and web UI tools for testing and debugging
Can be used programmatically as a library
Built on Bun runtime for high performance server execution, leveraging Bun's speed and JavaScript/TypeScript capabilities.
Allows AI agents to interact with multiple PostgreSQL databases, including running read-only queries, executing data-modifying statements, performing transactions, listing tables, and inspecting database schemas.
Implements end-to-end type-safety throughout the server with TypeScript, ensuring robust and error-resistant database interactions.
Uses Zod for parameter schema validation, ensuring that all inputs to database operations are properly validated and type-safe.
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., "@FastPostgresMCPshow me the schema for the users table in the production database"
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.
FastPostgresMCP 🐘⚡️ (Full-Featured Multi-DB MCP Server)
This project implements a blazing fast, type-safe, and full-featured Model Context Protocol (MCP) Server designed for AI Agents (like Cursor, Claude Desktop) to interact with multiple PostgreSQL databases, including listing tables and inspecting schemas.
It is built with Bun, TypeScript, postgres, and leverages advanced features of the fastmcp framework for building robust MCP servers.
Purpose: An MCP Server for AI Agents
This is not a library to be imported into your code. It is a standalone server application. You run it as a process, and MCP clients (like AI agents) communicate with it using the JSON-based Model Context Protocol (v2.0), typically over a stdio connection managed by the client application (e.g., Cursor).
Related MCP server: Postgres MCP Pro
Troubleshooting and Development
Using the CLI for Testing
The package includes a built-in CLI command for testing the MCP server directly:
# From the project repository:
bun run cli
# This will start an interactive MCP CLI session where you can:
# - Call any of the PostgreSQL tools (query_tool, execute_tool, etc.)
# - View server capabilities
# - Test queries against your configured databasesTesting with Built-in MCP Inspector
You can also use the MCP Inspector to visually test and debug:
# From the project repository:
bun run inspectCommon Issues
If you see this error when running bunx postgres-mcp:
FastPostgresMCP started
[warning] FastMCP could not infer client capabilitiesfollowed by ping messages, it means:
The MCP server started successfully
The client connected successfully
But the client is only sending ping requests and not properly negotiating capabilities
This usually indicates you need to use a proper MCP client. Try:
Using
bun run clito test with the MCP CLIConfiguring the MCP server in Cursor or Claude Desktop as described in the Installation section
If you're developing a custom MCP client, make sure it properly implements the MCP protocol including capabilities negotiation.
✨ Core Features
🚀 Blazing Fast: Built on Bun and
fastmcp.🔒 Type-Safe: End-to-end TypeScript with Zod schema validation.
🐘 Multi-Database Support: Connect to and manage interactions across several PostgreSQL instances defined in
.env.🛡️ Secure by Design: Parameterized queries via
postgresprevent SQL injection.🔑 Optional Authentication: Secure network-based connections (SSE/HTTP) using API Key validation (
fastmcp'sauthenticatehook).📄 Database Schema via MCP Resources:
List Tables: Get a list of tables in a database via
db://{dbAlias}/schema/tables.Inspect Table Schema: Get detailed column info for a specific table via
db://{dbAlias}/schema/{tableName}.
💬 Enhanced Tool Interaction:
In-Tool Logging: Tools send detailed logs back to the client (
logcontext).Progress Reporting: Long-running operations report progress (
reportProgresscontext).
🧠 Session-Aware: Access session information within tool execution context (
sessioncontext).📡 Event-Driven: Uses
server.onandsession.onfor connection/session event handling.🔧 Modern Developer Experience (DX): Clear configuration, intuitive API, easy testing with
fastmcptools.
What's Included (fastmcp Features Leveraged)
FastMCPServer Coreserver.addTool(forquery_tool,execute_tool,schema_tool, andtransaction_tool)server.addResourceTemplate(for listing tables and inspecting table schemas)server.start(withstdiofocus, adaptable forsse/http)Optional:
authenticateHook (for API Key validation)Tool Execution
context(log,reportProgress,session)Zod for Parameter Schema Validation
server.on(for connection logging)(Potentially)
session.onfor session-specific logic
📋 Prerequisites
Bun (v1.0 or later recommended): Installed and in PATH.
PostgreSQL Database(s): Access credentials and connectivity. User needs permissions to query
information_schema.
⚙️ Installation
Option 1: NPM Package
# Install globally
npm install -g postgres-mcp
# Or install locally in your project
npm install postgres-mcpThe npm package is available at https://www.npmjs.com/package/postgres-mcp
Option 2: Clone Repository
Clone the repository:
# Replace with your actual repository URL git clone https://github.com/llm-graph/postgres-mcp.git cd postgres-mcpInstall dependencies:
bun install
🔑 Configuration (Multi-Database & Optional Auth)
Configure via environment variables, loaded from appropriate .env files.
Create environment files:
For production:
cp .env.example .envFor development:
cp .env.development.example .env.development
Environment file loading order: The server loads environment variables from files in the following order of priority:
.env.<NODE_ENV>(e.g.,.env.development,.env.production,.env.staging).env.local(for local overrides, not version controlled).env(default fallback)
This allows different configurations for different environments.
Edit the environment files to define database connections and authentication:
DB_ALIASES- Comma-separated list of unique DB aliasesDEFAULT_DB_ALIAS- Default alias if 'dbAlias' is omitted in tool callsDatabase connection details for each alias (e.g.,
DB_MAIN_HOST,DB_REPORTING_HOST)Optional API Key authentication (
ENABLE_AUTH,MCP_API_KEY)
# Example .env file - Key Variables
# REQUIRED: Comma-separated list of unique DB aliases
DB_ALIASES=main,reporting
# REQUIRED: Default alias if 'dbAlias' is omitted in tool calls
DEFAULT_DB_ALIAS=main
# OPTIONAL: Enable API Key auth (primarily for network transports)
ENABLE_AUTH=false
MCP_API_KEY=your_super_secret_api_key_here # CHANGE THIS
# Define DB connection details for each alias (DB_MAIN_*, DB_REPORTING_*, etc.)
DB_MAIN_HOST=localhost
DB_MAIN_PORT=5432
DB_MAIN_NAME=app_prod_db
DB_MAIN_USER=app_user
DB_MAIN_PASSWORD=app_secret_password
DB_MAIN_SSL=disable
# Alternative: Use connection URLs
# DB_MAIN_URL=postgres://user:password@localhost:5432/database?sslmode=require
# --- Optional: Server Logging Level ---
# LOG_LEVEL=info # debug, info, warn, error (defaults to info)🚀 Running the Server (as a Process)
Run this server directly using Bun. The AI Client (like Cursor) will typically start and manage this command for you.
Option 1: Using the globally installed package
To run manually:
postgres-mcp
Option 2: Using the package in your project
To run from your project:
npx postgres-mcpOr import programmatically:
// server.js import { startServer } from 'postgres-mcp'; // Start the MCP server startServer();
Option 3: From cloned repository
To run manually (for testing):
bun run src/index.tsManual Development Mode:
bun run --watch src/index.ts
Testing with fastmcp CLI Tools
Interactive Terminal:
bunx fastmcp dev src/index.tsWeb UI Inspector:
bunx fastmcp inspect src/index.ts
💻 Using the Programmatic API (as a Library)
In addition to running as a standalone MCP server, postgres-mcp can also be used programmatically as a library in your Node.js/TypeScript applications.
Basic Usage
import { createPostgresMcp } from 'postgres-mcp';
// Create the PostgresMcp instance
const postgresMcp = createPostgresMcp();
// Start the server
postgresMcp.start();
// Direct database operations
const results = await postgresMcp.executeQuery(
'SELECT * FROM users WHERE role = $1',
['admin'],
'main' // optional database alias
);
// When done, stop the server and close connections
await postgresMcp.stop();Direct Function Imports
For simpler use cases, you can import specific functions directly:
import {
initConnections,
closeConnections,
executeQuery,
executeCommand,
executeTransaction,
getTableSchema,
getAllTableSchemas
} from 'postgres-mcp';
// Configure database connections
const dbConfigs = {
main: {
host: 'localhost',
port: 5432,
database: 'my_db',
user: 'db_user',
password: 'db_password'
}
};
// Initialize connections
initConnections(dbConfigs);
// Execute a query
const results = await executeQuery(
'SELECT * FROM users WHERE role = $1',
['admin'],
'main'
);
// Get schema for a single table
const schema = await getTableSchema('users', 'main');
// Get schema for all tables in the database
const allSchemas = await getAllTableSchemas('main');
// Close connections when done
await closeConnections();Configuration Options
const postgresMcp = createPostgresMcp({
// Custom database configurations (override .env)
databaseConfigs: {
main: {
host: 'localhost',
port: 5432,
database: 'app_db',
user: 'app_user',
password: 'password',
ssl: 'disable'
}
},
// Server configuration
serverConfig: {
name: 'Custom PostgresMCP',
defaultDbAlias: 'main'
},
// Transport options: 'stdio', 'sse', or 'http'
transport: 'http',
port: 3456
});For complete documentation on the programmatic API, see docs/programmatic-api.md.
🔌 Connecting with AI Clients (Cursor, Claude Desktop)
Configure your AI Agent (MCP Client) to execute this server script via its command/args mechanism.
Cursor AI - Detailed Example
Open Cursor Settings/Preferences (Cmd+, or Ctrl+,).
Navigate to "Extensions" -> "MCP".
Click "Add MCP Server" or edit
settings.json.Add the following JSON configuration:
// In Cursor's settings.json or MCP configuration UI { "mcpServers": { "postgres-mcp": { // Unique name for Cursor "description": "MCP Server for PostgreSQL DBs (Main, Reporting)", "command": "bunx", // Use 'bun' or provide absolute path: "/Users/your_username/.bun/bin/bun" "args": [ "postgres-mcp" // or // *** ABSOLUTE PATH to your server's entry point *** // "/Users/your_username/projects/postgres-mcp/src/index.ts" / ], "env": { // .env file in project dir is loaded automatically by Bun. // Add overrides or Cursor-specific vars here if needed. }, "enabled": true } } }Save and Restart Cursor or "Reload MCP Servers".
Verify connection in Cursor's MCP status/logs.
Claude Desktop
Locate and edit
config.json(see previous README for paths).Add a similar entry under
mcpServers, using the absolute path inargs.Restart Claude Desktop.
🛠️ MCP Capabilities Exposed
Authentication (Optional)
Secures network transports (HTTP/SSE) via
X-API-Keyheader matchingMCP_API_KEYifENABLE_AUTH=true.stdioconnections (default for Cursor/Claude) generally bypass this check.
Resources
1. List Database Tables
URI Template:
db://{dbAlias}/schema/tablesDescription: Retrieves a list of user table names within the specified database alias (typically from the 'public' schema).
Resource Definition (
addResourceTemplate):uriTemplate:"db://{dbAlias}/schema/tables"arguments:dbAlias: (string, required) - Alias of the database (from.env).
load({ dbAlias }): Connects to the database, queriesinformation_schema.tables(filtered for base tables in the public schema, customizable in implementation), formats the result as a JSON string array["table1", "table2", ...], and returns{ text: "..." }.
Example Usage (AI Prompt): "Get the resource db://main/schema/tables to list tables in the main database."
2. Inspect Table Schema
URI Template:
db://{dbAlias}/schema/{tableName}Description: Provides detailed schema information (columns, types, nullability, defaults) for a specific table.
Resource Definition (
addResourceTemplate):uriTemplate:"db://{dbAlias}/schema/{tableName}"arguments:dbAlias: (string, required) - Database alias.tableName: (string, required) - Name of the table.
load({ dbAlias, tableName }): Connects, queriesinformation_schema.columnsfor the specific table, formats as JSON string array of column objects, returns{ text: "..." }.
Example Usage (AI Prompt): "Describe the resource db://reporting/schema/daily_sales."
Example Response Content (JSON String):
"[{\"column_name\":\"session_id\",\"data_type\":\"uuid\",\"is_nullable\":\"NO\",\"column_default\":\"gen_random_uuid()\"},{\"column_name\":\"user_id\",\"data_type\":\"integer\",\"is_nullable\":\"NO\",\"column_default\":null},{\"column_name\":\"created_at\",\"data_type\":\"timestamp with time zone\",\"is_nullable\":\"YES\",\"column_default\":\"now()\"},{\"column_name\":\"expires_at\",\"data_type\":\"timestamp with time zone\",\"is_nullable\":\"YES\",\"column_default\":null}]"Tools
Tools receive context object (log, reportProgress, session).
1. query_tool
Executes read-only SQL queries.
Description: Safely execute read-only SQL, get results, with execution logging/progress.
Parameters:
statement(string),params(array, opt),dbAlias(string, opt).Context Usage:
log.info/debug, optionalreportProgress, accesssession.Returns: JSON string of the row array.
Example Request:
{
"tool_name": "query_tool",
"arguments": {
"statement": "SELECT product_id, name, price FROM products WHERE category = $1 AND price < $2 ORDER BY name LIMIT 10",
"params": ["electronics", 500],
"dbAlias": "main"
}
}Example Response Content (JSON String):
"[{\"product_id\":123,\"name\":\"Example Gadget\",\"price\":499.99},{\"product_id\":456,\"name\":\"Another Device\",\"price\":350.00}]"2. execute_tool
Executes data-modifying SQL statements.
Description: Safely execute data-modifying SQL, with execution logging.
Parameters:
statement(string),params(array, opt),dbAlias(string, opt).Context Usage:
log.info/debug, accesssession.Returns: String indicating rows affected.
Example Request:
{
"tool_name": "execute_tool",
"arguments": {
"statement": "UPDATE users SET last_login = NOW() WHERE user_id = $1",
"params": [54321]
// dbAlias omitted, uses DEFAULT_DB_ALIAS
}
}Example Response Content (String):
"Rows affected: 1"3. schema_tool
Retrieves detailed schema information for a specific table.
Description: Get column definitions and details for a database table.
Parameters:
tableName(string),dbAlias(string, opt).Context Usage:
log.info, accesssession.Returns: JSON string array of column information objects.
Example Request:
{
"tool_name": "schema_tool",
"arguments": {
"tableName": "user_sessions",
"dbAlias": "main"
}
}Example Response Content (JSON String):
"[{\"column_name\":\"session_id\",\"data_type\":\"uuid\",\"is_nullable\":\"NO\",\"column_default\":\"gen_random_uuid()\"},{\"column_name\":\"user_id\",\"data_type\":\"integer\",\"is_nullable\":\"NO\",\"column_default\":null},{\"column_name\":\"created_at\",\"data_type\":\"timestamp with time zone\",\"is_nullable\":\"YES\",\"column_default\":\"now()\"},{\"column_name\":\"expires_at\",\"data_type\":\"timestamp with time zone\",\"is_nullable\":\"YES\",\"column_default\":null}]"4. transaction_tool
Executes multiple SQL statements atomically.
Description: Execute SQL sequence in a transaction, with step logging/progress.
Parameters:
operations(array of {statement, params}),dbAlias(string, opt).Context Usage:
log.info/debug/error,reportProgress, accesssession.Returns: JSON string summarizing success/failure:
{"success": true, "results": [...]}or{"success": false, "error": ..., "failedOperationIndex": ...}.
Example Request:
{
"tool_name": "transaction_tool",
"arguments": {
"operations": [
{
"statement": "INSERT INTO orders (customer_id, order_date, status) VALUES ($1, NOW(), 'pending') RETURNING order_id",
"params": [101]
},
{
"statement": "INSERT INTO order_items (order_id, product_sku, quantity, price) VALUES ($1, $2, $3, $4)",
"params": [9999, "GADGET-X", 2, 49.99]
},
{
"statement": "UPDATE inventory SET stock_count = stock_count - $1 WHERE product_sku = $2 AND stock_count >= $1",
"params": [2, "GADGET-X"]
}
],
"dbAlias": "main"
}
}Example Success Response Content (JSON String):
"{\"success\":true,\"results\":[{\"operation\":0,\"rowsAffected\":1},{\"operation\":1,\"rowsAffected\":1},{\"operation\":2,\"rowsAffected\":1}]}"Example Error Response Content (JSON String):
"{\"success\":false,\"error\":\"Error executing operation 2: new row for relation \\\"inventory\\\" violates check constraint \\\"stock_count_non_negative\\\"\",\"failedOperationIndex\":2}"Server & Session Events
Uses
server.on('connect'/'disconnect')for logging client connections.Can use
session.on(...)for more granular session event handling if needed.
🔒 Security Considerations
SQL Injection: Mitigated via parameterized queries. No direct input concatenation.
Database Permissions: Critical. Assign least privilege to each
DB_<ALIAS>_USER, including read access toinformation_schemafor schema/table listing resources.SSL/TLS: Essential for production (
DB_<ALIAS>_SSL=requireor stricter).Secrets Management: Protect
.envfile (add to.gitignore). Use secure secret management for production environments (Vault, Doppler, cloud secrets).Authentication Scope:
authenticatehook primarily secures network transports.stdiosecurity relies on the execution environment.Data Sensitivity: Be aware of data accessible via connections/tools.
Resource Queries: The queries used for listing tables (
information_schema.tables) and schemas (information_schema.columns) are generally safe but rely on database permissions. Ensure the configured users have appropriate read access. Customize the table listing query (e.g., schema filtering) if needed for security or clarity.
📜 License
This project is licensed under the MIT License. See the LICENSE file for details.
📋 Changelog
1.0.0
Initial release
Full-featured MCP Server for PostgreSQL
Support for multiple database connections
Tools for queries, execution, schema inspection, and transactions
Resources for schema introspection
Comprehensive documentation and examples
Available Tools
4 toolsexecute_toolC
Safely execute a data-modifying SQL statement
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| dbAlias | No | ||
| statement | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Uses the word 'Safely' but does not elaborate on safety mechanisms, error handling, or any behavioral traits. No annotations provided to compensate.
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?
Single sentence, adequately concise but too brief to provide useful information beyond the name.
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?
With no output schema, no annotations, and 3 undocumented parameters, the description is incomplete for an SQL execution tool. Does not explain return values or parameter usage.
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 description does not mention any parameters despite 0% schema coverage. No explanation of 'params', 'dbAlias', or 'statement' meaning beyond the schema.
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?
Clearly states 'Safely execute a data-modifying SQL statement', specifying verb (execute) and resource (SQL statement), and distinguishes from read-only query_tool and schema_tool.
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?
No guidance on when to use vs. sibling tools (query_tool, schema_tool, transaction_tool). Does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_toolC
Safely execute a read-only SQL query and retrieve results
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| dbAlias | No | ||
| statement | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It only mentions 'safely' and 'read-only', but fails to cover error handling, authentication requirements, result format, rate limits, or side effects. The minimal disclosure leaves significant uncertainty about tool behavior.
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, which is concise but at the expense of necessary details. It is front-loaded with the purpose but omits parameter explanations and usage context. Every sentence should earn its place; this one only partially does.
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 complexity (3 parameters, no schema descriptions, no annotations, no output schema, and sibling tools), the description is incomplete. It fails to document how to use parameters, the output format, or how this tool relates to siblings. Significant gaps remain for the agent to function correctly.
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 0%, and the description provides no details about the three parameters (statement, params, dbAlias). It does not explain what params does, how to format the statement, or the role of dbAlias. The description adds zero semantic value beyond the raw schema.
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: 'Safely execute a read-only SQL query and retrieve results'. It specifies a verb ('execute'), a resource ('SQL query'), and a key constraint ('read-only'), effectively distinguishing it from sibling tools like execute_tool (likely for writes) and transaction_tool (for transactional 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 implies usage for read-only queries via the 'read-only' qualifier, but does not explicitly state when to use this tool versus alternatives like execute_tool for writes or transaction_tool for transactions. No when-not guidance or alternative names are provided, leaving the agent to infer usage from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
schema_toolC
Retrieve detailed schema information for a specific table
| Name | Required | Description | Default |
|---|---|---|---|
| dbAlias | No | ||
| tableName | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it retrieves schema info but does not disclose read-only nature, error handling, or authentication requirements.
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, front-loaded with key action, but lacks necessary detail. It is minimally concise at the expense of completeness.
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 no output schema, no annotations, and 2 under-documented parameters, the description is severely incomplete. It does not explain what 'detailed schema information' entails or how to use the optional dbAlias.
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 0%, yet the description does not explain the parameters (dbAlias, tableName) beyond the bare schema. The description fails to add meaning, e.g., the role of dbAlias or format of tableName.
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 'retrieve' and the resource 'detailed schema information for a specific table'. However, it does not differentiate from sibling tools like query_tool, which might also retrieve schema-related data.
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?
No guidance is given on when to use this tool versus alternatives such as execute_tool or query_tool. The description does not mention prerequisites or exclusionary conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transaction_toolB
Execute multiple SQL statements as a single atomic transaction
| Name | Required | Description | Default |
|---|---|---|---|
| dbAlias | No | ||
| operations | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Atomic transaction' implies ACID properties, but doesn't disclose rollback behavior, error handling, timeouts, or constraints. Adequate but not detailed.
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?
Single sentence, no wasted words. Efficiently conveys core functionality.
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?
No output schema, no annotations, and sibling tools suggest similar operations. Description lacks details on return values, error handling, transaction lifecycle, or limitations. Incomplete for a multi-statement 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 0%, meaning description adds no information about parameters like dbAlias or operations. The term 'multiple SQL statements' loosely maps to operations array but does not explain structure, required fields, or defaults.
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 executes multiple SQL statements atomically, which is a specific verb+resource. It distinguishes from siblings like execute_tool (likely single statement) and query_tool (read-only) by emphasizing atomic multi-statement execution.
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?
No guidance on when to use this tool versus alternatives like execute_tool or query_tool. Description does not mention use cases, prerequisites, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a well-defined and distinct purpose: execute_tool for data modification, query_tool for read-only queries, schema_tool for table metadata, and transaction_tool for atomic operations. There is no ambiguity or overlap.
All tool names follow a consistent verb_tool pattern using snake_case (execute_tool, query_tool, schema_tool, transaction_tool). The naming is predictable and clear.
With four tools, the set is minimal but covers essential database operations (read, write, schema, transactions). While missing some auxiliary functions like listing tables, the count is appropriate for a focused server.
The tools cover the main CRUD lifecycle (via query and execute) and add schema retrieval and transactions. Minor gaps exist, such as lacking a tool to list all tables, but the core workflows are supported.
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
Xata MCP server lets AI agents interact with your Xata projects, and Postgres database branches.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
- mcpOAuthcom.gibsonai
GibsonAI MCP server: manage your databases with natural language
Related MCP Servers
- AlicenseBqualityNot gradedmaintenanceA universal MCP server that enables AI agents to securely manage PostgreSQL databases, make API requests, and execute SSH commands with features for database analysis, schema editing, and data operations.31
- AlicenseNot gradedqualityNot gradedmaintenanceAn open-source MCP server that provides AI agents with advanced PostgreSQL capabilities including index tuning, query plan optimization, and comprehensive database health analysis. It supports safe SQL execution through configurable access modes and offers both stdio and SSE transport options for various development environments.
- AlicenseNot gradedqualityDmaintenanceZero-config MCP server that empowers AI agents to safely query SQL and NoSQL databases like PostgreSQL, MySQL, SQLite, MongoDB, and Redis.241MIT
- AlicenseAqualityDmaintenanceA production-grade MCP server that gives AI agents safe, authenticated access to a PostgreSQL database.3MIT
Appeared in Searches
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/llm-graph/postgres-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server