What can you do with this server?

This server lets an AI assistant run PostgreSQL queries through psql with enforced read-only safeguards. * list_databases: Lists configured databases and whether each is read-only or writable. * execute_sql: Runs SQL against a chosen database and returns results as CSV; writes are blocked on read-only databases regardless of request. * describe_schema: Shows tables/views in a schema, or columns, constraints, and indexes for one table; always read-only. * test_connection: Checks psql availability and connectivity, reporting psql path, server version, connected user, and each database's mode. * Enforces multi-layer read-only protection: blocks psql backslash commands, validates allowed SQL openers, wraps queries in BEGIN READ ONLY, and recommends a database-level read-only role. * Supports multiple database configurations via TOML, per-database read-only flags, timeouts, row limits, and environment-based password handling. * Can be forced globally read-only via --read-only or POSTGRES_MCP_READ_ONLY=1.

Which integrations are available for this server?

Provides tools for connecting to and interacting with PostgreSQL databases, including running SQL queries, describing table schemas, listing configured databases, and testing connections, with enforced read-only access where configured.

How do I use postgres-mcp?

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., "@postgres-mcp Describe the schema of the orders table" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

postgres-mcp

by azmym

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

postgres-mcp

An MCP server that lets an AI assistant run SQL against PostgreSQL through the psql command-line client.

Python 3.11 | 3.12 | 3.13 License: MIT

You configure several databases at once, and any of them can be marked read-only so that only read queries ever run against it.

It exists for one reason: when you hand a model a database, you want the read-only guarantee to come from the server and from PostgreSQL itself, not from the model's good behaviour. A prompt-injection payload in a web page or a table comment cannot talk its way into a write.

Related MCP server: Postgres Scout MCP

Requirements

Python 3.11 or newer
psql on your PATH

fastmcp is the only runtime dependency; everything else is the standard library.

Check for psql with psql --version. If it is missing:

Platform	Command
macOS, client only	`brew install libpq && brew link --force libpq`
macOS, full server	`brew install postgresql@18`
Debian, Ubuntu	`sudo apt install postgresql-client`
RHEL, Fedora	`sudo dnf install postgresql`
Arch	`sudo pacman -S postgresql-libs`
Windows	`scoop install postgresql`, or the EDB installer

brew install libpq is keg-only: without brew link --force, psql installs but stays off your PATH. test_connection detects that case and prints the export PATH=... line you need. You can also point the server at a specific binary with POSTGRES_MCP_PSQL=/path/to/psql.

Install

git clone https://github.com/azmym/postgres-mcp
cd postgres-mcp
uv venv && uv pip install -e ".[dev]"

Configure

Create ~/.config/postgres-mcp/config.toml (override the location with POSTGRES_MCP_CONFIG):

[defaults]
read_only = true          # safe by default
statement_timeout = "30s"
max_rows = 1000

[databases.local]
dsn = "postgresql://me@localhost:5432/appdb"
read_only = false

[databases.prod]
host = "prod.example.com"
port = 5432
user = "readonly_svc"
dbname = "app"
sslmode = "require"
password_env = "PROD_PG_PASSWORD"   # the env var NAME, never the secret
read_only = true

Each entry takes either dsn or the discrete fields (host, port, user, dbname, sslmode), not both. Passwords never go in this file: password_env names an environment variable, and ~/.pgpass covers the rest. The password travels to psql in the child process's PGPASSWORD environment variable, never on the command line, because argv is visible to ps.

Run test_connection with no arguments to validate the whole file at once.

Register with an MCP client

Directly from GitHub repo

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/azmym/postgres-mcp@v0.1.0",
        "postgres-mcp", "--read-only"
      ],
      "env": { "PROD_PG_PASSWORD": "..." }
    }
  }
}

Or refer to your local directory

{
  "mcpServers": {
    "postgres": {
      "command": "uv",
      "args": [
        "run", "--directory", "/absolute/path/to/postgres-mcp",
        "postgres-mcp", "--read-only"
      ],
      "env": {
        "POSTGRES_MCP_CONFIG": "/absolute/path/to/config.toml",
        "PROD_PG_PASSWORD": "..."
      }
    }
  }
}

Claude Code

Claude Code adds servers from the command line, so you do not edit JSON by hand:

claude mcp add postgres -s user \
  --env POSTGRES_MCP_CONFIG=~/.config/postgres-mcp/config.toml \
  -- uvx --from git+https://github.com/azmym/postgres-mcp@v0.1.0 postgres-mcp --read-only

Two details decide whether that command works.

The -- is required. Everything after it goes to the server process untouched. Leave it out and claude mcp add reads --from as one of its own flags, then fails.

-s user registers the server for every project you open. The default is local, which limits it to the directory you run the command in. -s project writes the registration into that repository's .mcp.json, which commits it for everyone who works on the repo, so choose project only when the whole team should reach the same databases.

The tilde works here because your shell expands it before claude sees the value. Nothing expands it inside a JSON file, so write an absolute path when you edit one by hand.

That command produces this entry:

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/azmym/postgres-mcp@v0.1.0",
        "postgres-mcp", "--read-only"
      ],
      "env": {
        "POSTGRES_MCP_CONFIG": "/absolute/path/to/config.toml"
      }
    }
  }
}

Check it with claude mcp list, and use claude mcp remove postgres -s user to undo it.

Flags and variables

--read-only forces every configured database read-only regardless of the config file. POSTGRES_MCP_READ_ONLY=1 does the same.

The env block needs one entry for every password_env your config declares. The example above shows one because the example config has one: local connects with a dsn and no password, and only prod names a variable. A config with four databases needs four entries, one per variable name.

Writing the password here puts it in a second file on disk, which is what password_env was meant to avoid. Two ways around that: put the credentials in ~/.pgpass, which psql reads without any variable, or export the variable in the shell that launches your MCP client and leave it out of the JSON. The server only needs the variable to exist in its environment; it does not care who set it.

POSTGRES_MCP_CONFIG points the server at a specific config file, which is what lets you run more than one instance. See below.

Several environments

Say you run MSS on both staging and production. You have two ways to set that up, and they differ in how much separation you get.

One config file

Put both databases in ~/.config/postgres-mcp/config.toml and tell them apart by name:

[defaults]
read_only = true          # anything you forget to mark stays read-only

[databases.mss_staging]
host = "mss-staging.internal"
port = 5432
user = "app"
dbname = "mss"
password_env = "MSS_STAGING_PW"
read_only = false

[databases.mss_production]
host = "mss-prod.internal"
port = 5432
user = "readonly_svc"
dbname = "mss"
sslmode = "require"
password_env = "MSS_PROD_PW"
read_only = true
statement_timeout = "10s"
max_rows = 200

You manage one file and one client entry. Each database keeps its own mode and limits, so a write against mss_staging goes through while the gate refuses the same statement against mss_production, which also runs on a shorter timeout and a smaller row cap.

The assistant sees both databases in one list and picks between them by name. Read-only on production stops a wrong pick from damaging data, but it will still return production rows into a conversation you meant to keep on staging, and nothing enforces your naming convention.

Two server instances

Split the databases across two config files, staging.toml and production.toml, each holding one entry, then register both:

{
  "mcpServers": {
    "mss-staging": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/azmym/postgres-mcp@v0.1.0",
        "postgres-mcp"
      ],
      "env": {
        "POSTGRES_MCP_CONFIG": "/Users/you/.config/postgres-mcp/staging.toml",
        "MSS_STAGING_PW": "..."
      }
    },
    "mss-production": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/azmym/postgres-mcp@v0.1.0",
        "postgres-mcp", "--read-only"
      ],
      "env": {
        "POSTGRES_MCP_CONFIG": "/Users/you/.config/postgres-mcp/production.toml",
        "MSS_PROD_PW": "..."
      }
    }
  }
}

The environment becomes part of the tool name, so the assistant selects mss-production as its own tool rather than pulling a string from a list. The production instance also carries --read-only at the process level, where a mistake in the config file cannot reach it, and its password lives only in that process's environment, so a staging session never holds it.

You pay two files and two client entries, and you lose the ability to query staging and production in one call.

Choosing

Use one file while you work on your own machine against data you can afford to break. Move to two instances once production data is in reach, where the cost of the assistant picking the wrong name outweighs the cost of a second config file.

Either way, create a read-only role on production and point that entry's user at it. It holds even if this server has a bug, and the SQL is below.

Both approaches take more than two databases. Adding MAS alongside MSS gives you four entries in one file, or two files of two entries each if you split them by environment.

Tools

Tool	Purpose
`list_databases`	Configured databases and their read-only status
`execute_sql`	Run SQL, returns CSV
`describe_schema`	Tables in a schema, or one table's columns, constraints and indexes
`test_connection`	Check psql and connectivity; reports the psql binary, server version, connected user, and each database's mode

describe_schema is always read-only, even against a writable database.

How read-only is enforced

Three independent layers, plus a fourth you should add yourself. The diagram above counts all four; this one shows what the three enforced layers check, including the keywords each one permits and blocks.

Backslash commands are always rejected. \! runs a shell command on this host and never reaches the server, and \copy and \o write local files, so any statement opening with a backslash is refused in both modes.
A statement gate scrubs comments, string literals, quoted identifiers and dollar-quoted bodies, then requires every statement to open with one of six keywords: SELECT, WITH, EXPLAIN, SHOW, TABLE or VALUES. It then scans for the write verbs INSERT, UPDATE, DELETE, MERGE and INTO (SELECT ... INTO creates a table), so WITH x AS (...) INSERT ... is caught even though it opens with an allowed keyword. EXPLAIN ANALYZE SELECT is allowed; EXPLAIN ANALYZE UPDATE is not, because ANALYZE executes its argument. SELECT ... FOR UPDATE and FOR SHARE are rejected too, since they take row locks a read-only transaction refuses.
BEGIN READ ONLY wraps the statements, so PostgreSQL itself refuses a write even if the gate were fooled.

No tool takes a read_only argument, so the model cannot escalate its own privileges. The switch lives in configuration, not in the request.

Read-only precedence, highest first: the --read-only flag or POSTGRES_MCP_READ_ONLY=1, then a per-database read_only, then [defaults].read_only, then a built-in default of true. The global switch can only tighten, never loosen.

A read-only role (recommended)

The only layer that does not depend on this server's correctness is the database's own permissions:

CREATE ROLE mcp_reader LOGIN PASSWORD 'choose-something-strong';
GRANT CONNECT ON DATABASE app TO mcp_reader;
GRANT USAGE ON SCHEMA public TO mcp_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO mcp_reader;

Point prod.user at mcp_reader and a bug in this server still cannot write.

Known limits

SET is not an allowed opener in read-only mode, so search_path cannot be changed. Schema-qualify your tables, or use describe_schema.
Output is CSV, truncated by max_rows (default 1000) with a trailer naming the real total, plus a 100 KB byte ceiling. No LIMIT is injected into your SQL, so the reported total is the real one; add your own LIMIT if the query itself is expensive.
NULL renders as [NULL] to distinguish it from an empty string. A column whose literal text is [NULL] is therefore ambiguous with a real NULL.

Tests

tests/test_integration.py runs against a real PostgreSQL server. When none is reachable it skips rather than failing. Point it at a server with the standard libpq variables:

PGHOST=localhost PGUSER=admin PGPASSWORD=admin uv run pytest

Or spin up a throwaway server with Docker:

docker run --rm -d --name pg-mcp-test \
  -e POSTGRES_PASSWORD=admin -p 5432:5432 postgres:18
PGHOST=localhost PGUSER=postgres PGPASSWORD=admin uv run pytest
docker rm -f pg-mcp-test

Without a server the integration tests skip and the unit tests still run (151 passed, 10 skipped). Against a live server all 161 pass. Verified against PostgreSQL 18.6.

Troubleshooting

The first failure you will hit is psql not being found. The server looks on PATH, then probes common install locations, and raises a specific message for each case. On macOS the usual cause is brew install libpq without brew link --force, which installs psql but leaves it off your PATH; the error tells you the exact export PATH=... line to add. Set POSTGRES_MCP_PSQL to skip the search.

Contributing

CONTRIBUTING.md covers the setup, the two test modes, and the conventions the code follows. The project is MIT-licensed (LICENSE).

Security is the whole point of this server, so SECURITY.md is worth reading: it documents the threat model, what counts as a vulnerability, and how to report one privately.

Available Tools

4 tools

describe_schemaA

Describe a schema's tables, or one table's columns and indexes.

Without table, lists the schema's tables, views and column counts. With table, returns that table's columns, constraints and indexes. Always read-only, even against a writable database.

ParametersJSON Schema

Name	Required	Default
`table`	No
`schema`	No	public
`database`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that the operation is always read-only, even against a writable database, and it clarifies the two distinct behaviors based on the table parameter. This adds meaningful safety and behavior context beyond 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 compact and well-structured: it states the core purpose first, then uses a clear without/with contrast to explain behavior. Every sentence earns its place, and the read-only note is brief but high-value.

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?

The description covers the two main behaviors, the read-only guarantee, and the inputs that matter most. An output schema exists, so not detailing return values is acceptable. A small gap is that it does not mention how schema and database relate or what happens if the database or table does not exist, but for a read-only introspection tool this is minor.

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 0%, so the description needs to explain parameters. It does explain the table parameter thoroughly (without vs. with behavior), but it does not add meaning for database or schema beyond their obvious names. The schema default values are visible in the input schema, so this is partially compensated.

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 opens with a specific verb and resource ('Describe a schema's tables, or one table's columns and indexes') and then details both invocation modes. This clearly distinguishes it from siblings like list_databases and execute_sql.

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

Usage Guidelines4/5

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

The description clearly explains when to use the tool without a table (list tables, views, column counts) versus with a table (columns, constraints, indexes). It also signals that this is the safe introspection alternative by noting it is always read-only, but it does not explicitly name execute_sql as the write-capable alternative.

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

execute_sqlA

Run SQL against a configured database and return the rows as CSV.

database is a name from list_databases. Whether writes are permitted is fixed by configuration and cannot be changed per call: against a read-only database, only read queries run.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`database`	Yes
`max_rows`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden and does it well: it reveals CSV output, that write permissions are configuration-fixed, and that read-only databases only run read queries. This is meaningful context beyond the schema, though it does not explicitly warn that writable databases may be modified.

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 two tight sentences with the core action and output front-loaded. Every sentence earns its place: the first defines what the tool does, the second adds the database-source and write-permission constraints.

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?

The description covers the key facts an agent needs: what SQL is run, where database names come from, whether writes are allowed, and what the return format is. Missing details like `max_rows` semantics and error behavior are present, but the output schema and otherwise solid context keep this from being incomplete.

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 0%, so the description must compensate. It adds meaning for `database` by tying it to list_databases and implies `query` is the SQL to run, but it leaves `max_rows` entirely unexplained, which is a gap for an optional limit parameter.

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?

"Run SQL against a configured database and return the rows as CSV" states a specific verb, resource, and output format. This clearly distinguishes execute_sql from siblings like list_databases, test_connection, and describe_schema, which do not execute queries.

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

Usage Guidelines4/5

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

The description gives concrete usage context by noting that `database` is a name from list_databases and that write behavior is fixed by configuration. It does not explicitly name alternative tools for when not to use it, but the prerequisite and permission constraints provide clear operational guidance.

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

list_databasesA

List the configured PostgreSQL databases and their read-only status.

Returns each database's name, connection target and whether it accepts writes. Passwords are never included.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly states the operation is a listing, describes the returned fields (name, connection target, write acceptance), and proactively notes that passwords are never included. This is meaningful behavioral context, though it does not explicitly state side-effect-free behavior.

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 concise and front-loaded, with the core purpose in the first sentence and supporting output/security details in two short follow-up sentences. Every sentence contributes useful information with no redundancy.

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

Completeness5/5

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

For a zero-parameter tool with an output schema, the description fully covers what the agent needs to know: what the tool returns, the security guarantee about passwords, and the general scope. Nothing critical is missing.

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

Parameters4/5

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

The tool has zero parameters, so the description does not need to explain parameter meanings. The baseline of 4 applies, and the description adds value by focusing on what the output contains rather than input details.

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 uses a specific verb ('List') and resource ('configured PostgreSQL databases') and clearly distinguishes this tool from the siblings execute_sql, test_connection, and describe_schema by focusing on database enumeration and write-access status. The purpose is immediately obvious and not confused with querying, testing connections, or describing 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 the tool is used when you need to see available databases and their read-only status, but it does not explicitly state when to prefer this over siblings or when not to use it. There is no mention of alternatives or conditions, leaving usage largely implied.

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

test_connectionA

Check psql and connectivity, for one database or all of them.

Reports the path to the psql binary, the server version, the connected user, and each database's configured read-only or read-write mode. Omit database to check every configured entry, which also validates the config file.

ParametersJSON Schema

Name	Required	Description	Default
`database`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by disclosing the specific outputs: psql binary path, server version, connected user, and read-only/read-write mode. It also mentions config-file validation when checking all databases. It does not explicitly state that no data is modified, but 'check' and 'reports' strongly imply a non-destructive diagnostic.

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 compact and front-loaded: the first sentence gives the core action and scope, and the second adds useful behavioral detail. Every sentence contributes information without redundancy.

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

Completeness5/5

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

For a simple diagnostic tool with one optional parameter and an output schema, the description covers the invocation scope, the meaning of omitting the parameter, and the reported fields. An agent has enough information to call it correctly without needing more context.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It clearly explains the semantic difference between providing `database` (check one database) and omitting it (check every configured entry and validate the config file). This is sufficient for correctly using the single optional parameter.

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 states a specific diagnostic action ('Check psql and connectivity') and the exact scope ('for one database or all of them'). It also lists concrete reported outputs, making it clearly distinguishable from sibling tools like list_databases and execute_sql.

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 explains how to scope the check by omitting or providing `database`, but gives no guidance on when to prefer this tool over siblings such as list_databases, execute_sql, or describe_schema. Usage context is implied rather than explicitly stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 9, 2026
- First observeddescribe_schema
- First observedexecute_sql
- First observedlist_databases
- First observedtest_connection

Install Server

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

TDQS

A4.3/5.0

Scored 2026-09-09 17:30 across 4 tools

Disambiguation4/5

execute_sql and describe_schema are clearly distinct, and list_databases is primarily about enumerating configured databases. test_connection overlaps somewhat by reporting each database's read-only/write mode, but its focus on psql and connectivity makes the boundary clear enough.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: list_databases, execute_sql, test_connection, describe_schema. There are no mixed conventions or vague verbs.

Tool Count5/5

Four tools is well-scoped for a focused Postgres server: enumeration, querying, introspection, and diagnostics. Each tool earns its place without redundancy.

Completeness4/5

Arbitrary SQL execution covers CRUD/write operations where permitted, while list_databases and describe_schema enable discovery and introspection. A minor gap is the lack of a direct list-schemas tool, but agents can work around it via information_schema queries.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

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

PlainQuery | MCP DB Agent
io.github.Jarvis-27
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Databases Search
2
QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
mcpmyadminOAuth
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
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

Related MCP Servers

PostgreSQL MCP Server
Databases Search
melihbirim
F
license
A
quality
D
maintenance
Enables AI assistants to interact with PostgreSQL databases using natural language queries, providing secure read-only access to database schemas and SQL translation capabilities.
Updated a year ago (2025-07-21 17:09 UTC)
6
12
-
Postgres Scout MCP
Databases Developer Tools Code Analysis
bluwork
A
license
Not graded
quality
D
maintenance
Enables AI assistants to safely explore, analyze, and maintain PostgreSQL databases with read-only mode by default, SQL injection prevention, query performance analysis, and optional write operations.
Updated 6 months ago (2026-03-07 12:29 UTC)
37
Apache 2.0
PostgreSQL MCP Server
Databases RAG Systems
ArkTechNWA
A
license
Not graded
quality
Not graded
maintenance
Provides AI assistants with safe, controlled access to PostgreSQL databases with read-only defaults, granular permissions, query safety features, and schema introspection capabilities.
Updated 8 months ago (2025-12-30 21:20 UTC)
1
-
postgresdb-mcp
Databases Developer Tools
nayzo
A
license
Not graded
quality
C
maintenance
Enables AI assistants to interact with PostgreSQL databases, providing tools for querying, table listing, schema exploration, and multi-environment management with write protection and schema scoping.
Updated 4 months ago (2026-05-04 10:44 UTC)
1
MIT

postgres-mcp

Contents

Requirements

Install

Configure

Register with an MCP client

Claude Code

Flags and variables

Several environments

One config file

Two server instances

Choosing

Tools

How read-only is enforced

A read-only role (recommended)

Known limits

Tests

Troubleshooting

Contributing

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers