What can you do with this server?

pg-mcp is a PostgreSQL MCP server that enables AI assistants to securely interact with PostgreSQL databases, with built-in read-only protection by default. * pg_connect: Connect to a PostgreSQL database via a connection URL or individual parameters (host, port, user, password, database), with optional SSL and read-only mode settings. * pg_disconnect: Close and clean up an existing database connection by its connection ID. * pg_query: Execute SQL queries against a connected database, with support for parameterized/prepared statements. * pg_list_schemas: List all schemas available in the connected database. * pg_get_ddl: Retrieve the complete DDL for a database (CREATE TABLE statements, indexes, constraints, foreign keys, sequences, and views), optionally filtered by schema. * Read-only mode: Enabled by default, blocking DML (INSERT, UPDATE, DELETE, TRUNCATE, MERGE) and DDL/DCL operations (CREATE, ALTER, DROP, GRANT, REVOKE). Can be explicitly disabled per connection. * Auto-connect: Automatically connects on startup if DATABASE_URL or standard libpq environment variables are set, using connection ID "default".

Which integrations are available for this server?

Enables querying of PostgreSQL databases, schema inspection, and retrieval of DDL with built-in read-only protection. It provides tools for connecting to databases, executing SQL queries, listing schemas, and fetching complete DDL structures.

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pg-mcp list all tables in the public schema" 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.

pg-mcp

by shedyhs

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

pg-mcp

MCP server for PostgreSQL. Query databases, inspect schemas, backup data, and manage dumps — with built-in read-only protection.

Quick Start

npm install -g @shedyhs/pg-mcp

Add to your AI provider config:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@shedyhs/pg-mcp"],
      "env": {
        "DATABASE_URL": "postgres://user:pass@localhost:5432/mydb"
      }
    }
  }
}

With DATABASE_URL or PGHOST/PGDATABASE set, the server auto-connects as "default" on startup.

Set PG_MCP_READ_ONLY=false in env to allow write operations (read-only by default).

Related MCP server: PostgreSQL MCP Server

Tools

Tool	Description	Requires
`pg_connect`	Connect to a PostgreSQL database (URL, params, or libpq env vars)	—
`pg_disconnect`	Disconnect from a database	—
`pg_query`	Execute SQL queries with read-only protection	—
`pg_list_schemas`	List all user schemas	—
`pg_get_ddl`	Get complete DDL (tables, indexes, constraints, FKs, sequences, enums, views)	—
`pg_backup_query`	Backup specific rows as INSERT statements before destructive operations	—
`pg_dump`	Dump a database or specific tables to a file	`pg_dump` CLI
`pg_restore`	Restore a database from a dump file (custom, directory, or tar format)	`pg_restore` CLI

Where to Put the Config

Provider	Config file
Claude Desktop	`~/Library/Application Support/Claude/claude_desktop_config.json` (macOS) / `%APPDATA%\Claude\claude_desktop_config.json` (Windows)
Claude Code	`.claude/settings.json` or `~/.claude/settings.json`
Cursor	`.cursor/mcp.json`
Windsurf	`~/.codeium/windsurf/mcp_config.json`
Codex	`codex.json`

All providers above use the same JSON format from Quick Start.

GitHub Copilot (VS Code) uses a slightly different format in .vscode/mcp.json:

{
  "servers": {
    "postgres": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@shedyhs/pg-mcp"],
      "env": {
        "DATABASE_URL": "postgres://user:pass@localhost:5432/mydb"
      }
    }
  }
}

From source — replace command/args with "command": "node", "args": ["/path/to/pg-mcp/dist/index.js"].

Installing pg_dump & pg_restore

Only needed if you use pg_dump or pg_restore. All other tools work without external dependencies.

OS	Command
macOS	`brew install libpq`
Debian/Ubuntu	`sudo apt-get install postgresql-client-16`
RHEL/Fedora	`sudo dnf install postgresql16`
Windows	`winget install PostgreSQL.PostgreSQL.16`

Verify with pg_dump --version.

Installation from Source

git clone https://github.com/shedyhs/pg-mcp
cd pg-mcp
npm install && npm run build

License

MIT

Available Tools

5 tools

pg_connectB

Connect to a PostgreSQL database using a URL or individual parameters

ParametersJSON Schema

Name	Required	Description
`connectionId`	Yes	Unique identifier for this connection
`url`	No	PostgreSQL connection URL (e.g., postgresql://user:pass@host:5432/dbname?ssl=true)
`host`	No	PostgreSQL host (ignored if url is provided)
`port`	No	PostgreSQL port (default: 5432, ignored if url is provided)
`database`	No	Database name (ignored if url is provided)
`user`	No	Username (ignored if url is provided)
`password`	No	Password (ignored if url is provided)
`ssl`	No	Use SSL connection (default: false, ignored if url is provided)
`readOnly`	No	Enable read-only mode - blocks INSERT, UPDATE, DELETE, and DDL operations (default: true)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It only states the connection method but omits what happens on success/failure, whether connections are pooled, or any side effects. The readOnly parameter is not mentioned in the description, though it is in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, effective sentence that immediately conveys the core purpose. It is front-loaded and contains no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, no annotations, no output schema), the description is too minimal. It fails to explain the return behavior (e.g., what happens after connecting), error handling, or how to use the connection with sibling tools. The schema covers parameter details, but the description should provide broader context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds a high-level distinction between URL and individual parameters, which echoes the schema's 'ignored if url is provided' notes. It does not add substantial new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action ('Connect') and the resource ('PostgreSQL database'), and distinguishes between two connection methods (URL or individual parameters). This clearly differentiates it from sibling tools like pg_disconnect, pg_query, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., before querying, after disconnect). It does not mention prerequisites, such as needing a connectionId, or that it must be called before other database operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pg_disconnectB

Disconnect from a PostgreSQL database

ParametersJSON Schema

Name	Required	Description	Default
`connectionId`	Yes	Connection ID to disconnect

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only states the basic action. It does not disclose side effects (e.g., rolling back transactions), error conditions, or whether repeated disconnects are safe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the essential action. No superfluous words; every word contributes to the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description covers the core action but lacks behavioral context (e.g., prerequisites, side effects). Adequate but with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter 'connectionId', and the description does not add any additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Disconnect' and the resource 'PostgreSQL database', which is specific and distinct from sibling tools like pg_connect, pg_get_ddl, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool, prerequisites (e.g., must have an active connection), or alternatives. The description does not help the agent decide when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pg_get_ddlA

Get the complete DDL (Data Definition Language) of the database including CREATE TABLE statements, indexes, constraints, foreign keys, sequences, and views

ParametersJSON Schema

Name	Required	Description	Default
`connectionId`	Yes	Connection ID to use
`schema`	No	Filter by schema (optional, returns all user schemas if not specified)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description carries full burden. It indicates a read operation returning DDL content, but could add statements about non-destructiveness or potential performance impact on large databases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with precise content; no unnecessary words. Efficiently conveys purpose and scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description reasonably describes the output (DDL statements). Missing explicit mention of return format (e.g., string or array), but still informative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions, so baseline is 3. The description adds no extra meaning beyond the schema; it only reiterates the schema's optionality note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'Get', the resource 'complete DDL', and lists included objects (CREATE TABLE, indexes, etc.), clearly distinguishing it from sibling tools like pg_query or pg_list_schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when DDL is needed, but provides no explicit when-to-use, when-not-to-use, or alternative guidance. It is adequate but lacks direct differentiation from pg_query or pg_list_schemas.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pg_list_schemasA

List all schemas in the database

ParametersJSON Schema

Name	Required	Description	Default
`connectionId`	Yes	Connection ID to use

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description indicates a read-only operation ('list'), but lacks details on permissions, performance, or potential side effects. For a simple read tool, minimal transparency is acceptable but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence with no wasted words. It 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.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, no output schema), the description provides sufficient context for an agent to understand its purpose. A minor improvement would be to indicate the return format (e.g., list of schema names), but it is not mandatory.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters, and the description adds no additional meaning beyond the schema's own description of the connectionId parameter. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all schemas in the database, using a specific verb and resource. It is distinct from sibling tools like pg_connect (connection management) and pg_query (arbitrary queries).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when schemas need to be enumerated, but does not provide explicit guidance on when to use versus siblings, nor any preconditions (e.g., needing an active connection).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pg_queryC

Execute a SQL query on a PostgreSQL database

ParametersJSON Schema

Name	Required	Description
`connectionId`	Yes	Connection ID to use
`sql`	Yes	SQL query to execute
`params`	No	Query parameters for prepared statements

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavioral traits. It does not mention whether the query can modify data, require specific permissions, or produce side effects. The minimal description leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but under-informative for a significant operation. It is not overlong, but additional context could be incorporated without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is too sparse. It omits details on return format, error handling, security (e.g., SQL injection mitigation via params), and proper usage of parameters. In comparison to sibling tools, it provides insufficient context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters have descriptions. The tool description adds no extra meaning beyond the schema; for example, 'sql' is described as 'SQL query to execute' which repeats the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Execute') and resource ('SQL query on a PostgreSQL database'). It is specific and unambiguous, though it does not explicitly differentiate from sibling tools like pg_get_ddl, which also executes queries for DDL. A score of 4 reflects clarity without sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use pg_query versus alternatives like pg_get_ddl or pg_list_schemas. There is no mention of appropriate use cases, prerequisites, or exclusions. The agent receives no contextual advice for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a distinct purpose: connection management, schema listing, DDL retrieval, and arbitrary query execution. No overlap or ambiguity.

Naming Consistency5/5

All tools use the 'pg_' prefix followed by a verb_noun pattern (connect, disconnect, get_ddl, list_schemas, query). Naming is consistent and predictable.

Tool Count5/5

With 5 tools, the server covers essential database operations without being too sparse or overwhelming. The count is well-scoped for its purpose.

Completeness4/5

The server provides core functionality for connecting, exploring schemas, viewing DDL, and running queries. It lacks dedicated tools for listing tables or indexes, but the SQL query tool can compensate.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

QueryBear
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
PlainQuery | MCP DB Agent
io.github.Jarvis-27
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Databases Search
2
Veto — SQL Safety & Cost Oracle A
com.vetosql
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Databases Security Autonomous Agents
32
mcpmyadmin
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
2

Related MCP Servers

PostgreSQL MCP Server
Databases Data Platforms Developer Tools
gldc
A
license
Not graded
quality
D
maintenance
Enables AI agents to interact with PostgreSQL databases through the Model Context Protocol, providing database schema exploration, table structure inspection, and SQL query execution capabilities.
Updated 7 months ago (2026-02-18 22:00 UTC)
15
MIT
PostgreSQL MCP Server
Databases Developer Tools
gharshit
A
license
Not graded
quality
D
maintenance
Enables AI assistants to safely interact with PostgreSQL databases through read-only operations, providing schema discovery, table inspection, and query execution capabilities with structured context awareness.
Updated 9 months ago (2025-12-11 15:39 UTC)
MIT
PostgreSQL MCP Server
Databases RAG Systems
abhinv98
A
license
Not graded
quality
D
maintenance
Enables AI agents to query, explore, and analyze PostgreSQL databases through the Model Context Protocol. It provides robust security features including read-only mode, schema restrictions, and query timeouts for safe data interaction.
Updated 9 months ago (2025-12-04 07:49 UTC)
19
MIT
PostgreSQL MCP Server
adelhassen
F
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with PostgreSQL databases by executing SQL queries and inspecting database schemas. It provides tools to facilitate database exploration and management through the Model Context Protocol.
Updated 7 months ago (2026-02-04 04:39 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/shedyhs/pg-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server