Which integrations are available for this server?

Provides read-only SQL querying and schema inspection for PostgreSQL databases, with enforced LIMIT clauses and blocking of destructive statements to safely explore data. Provides read-only SQL querying and schema inspection for SQLite databases, with enforced LIMIT clauses and blocking of destructive statements to safely explore data.

How do I use PgSafe MCP?

1. Click on "Deploy 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., "@PgSafe MCP show me the schema for 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.

PgSafe MCP

by johannschiffer

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

PgSafe MCP (Lite Edition)

License: MIT Python 3.10+ MCP Compliant

PgSafe MCP is a Zero-Trust Model Context Protocol server that enables AI agents in Claude Desktop, Cursor, Windsurf, and Antigravity to inspect schemas and run analytical SQL queries without risking accidental data loss, destructive mutations (DROP, TRUNCATE, DELETE), or runaway table scans.

🛡️ Why PgSafe MCP?

Giving an AI assistant raw access to your database is terrifying:

Accidental Deletions: One ambiguous prompt can lead an LLM to generate DROP TABLE or DELETE FROM users;.
Production Table Locks: An unindexed query with a multi-table Cartesian product can consume 100% CPU and lock production tables.
Multi-Statement Injection: LLMs can be tricked via prompt injection into chaining malicious SQL commands (SELECT 1; TRUNCATE audit_logs;).

PgSafe acts as a strict guardrail sitting between the AI agent and your database engine.

Related MCP server: Universal Database MCP Server

⚡ Features (Lite Edition)

🔒 Enforced Read-Only Guard: Automatically detects and blocks all destructive statements (DROP, TRUNCATE, ALTER, UPDATE, INSERT, DELETE).
🛑 Anti-Chaining Protection: Disallows multi-statement execution via semicolons.
⏱️ Automatic LIMIT Injection: Ensures every SELECT query has a capped LIMIT clause (default: 100 rows, max: 1,000) to protect database memory.
📊 Zero-Cost Schema Reflection: Tools to explore public tables and columns without executing custom introspection queries.
🪶 Zero Dependency Core: Native support for SQLite out of the box; optional PostgreSQL adapter.

🚀 Quick Setup in 2 Minutes

1. Installation

git clone https://github.com/johannschiffer/pgsafe-mcp.git
cd pgsafe-mcp
pip install .

For PostgreSQL support:

pip install "psycopg[binary]>=3.1.0"

2. Configure Claude Desktop (`claude_desktop_config.json`)

On Linux: ~/.config/Claude/claude_desktop_config.json
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "pgsafe": {
      "command": "python",
      "args": ["-m", "pgsafe.server"],
      "cwd": "/path/to/pgsafe-mcp",
      "env": {
        "DATABASE_URL": "postgresql://user:password@localhost:5432/production_db"
      }
    }
  }
}

For SQLite, simply point to your .db file:

{
  "mcpServers": {
    "pgsafe": {
      "command": "python",
      "args": ["-m", "pgsafe.server"],
      "cwd": "/path/to/pgsafe-mcp",
      "env": {
        "DATABASE_URL": "sqlite:///data/nexus.db"
      }
    }
  }
}

🛠️ MCP Tools Exposed to AI Agents

Tool	Parameters	Description
`list_tables`	(none)	Returns list of all user tables in the database
`describe_table`	`table_name`	Returns column names, data types, nullability, and primary keys
`safe_query`	`query`, `limit`	Executes strictly read-only SQL with forced LIMIT enforcement
`analyze_query`	`query`	Inspects SQL for unindexed table scan and Cartesian join risks

💎 Need Enterprise Data Protection? Upgrade to PgSafe Pro

Running against live production workloads with sensitive customer data?

Feature	Lite (Open Source)	Pro ($14.99 USD)
Read-Only SQL Validation	✅	✅
Forced LIMIT Injection	✅	✅
PostgreSQL & SQLite	✅	✅
MySQL, MariaDB & ClickHouse	❌	✅
Automatic PII Redaction & Masking (Emails, Cards, Hashes)	❌	✅
Dry-Run Mutation Simulation (Auto-Rollback Test Harness)	❌	✅
Index Recommendation Advisor	❌	✅
Production Docker & Compose	❌	✅
Full Pytest Suite & Architecture Guide	❌	✅

👉 Get PgSafe Pro on Gumroad ($14.99)

📄 License

MIT License. See LICENSE for details.

Available Tools

4 tools

analyze_queryA

Analyze a SQL query for dangerous operations, unindexed scans, and Cartesian join risks without executing it.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query to inspect

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does deliver the key safety trait: the query is not executed. However, it says nothing about required permissions, behavior on malformed queries, size/dialect limits, or whether analysis is exhaustive or best-effort, leaving notable behavioral gaps.

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?

One sentence, front-loaded with the verb and the check categories, ending with the most decision-relevant constraint ('without executing it'). Every clause earns its place.

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 one-parameter tool with no output schema and no annotations, the description covers purpose and the safety guarantee but leaves the return shape (severity levels, findings format) and operating constraints unspecified. Adequate but with clear 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?

There is a single parameter at 100% schema description coverage ('SQL query to inspect'), so the schema already does the work and the baseline is 3. The description adds the non-execution constraint but no format guidance (dialect, multi-statement input, length limits) 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 states a specific verb ('Analyze') and resource ('a SQL query') and enumerates the exact hazards it inspects: dangerous operations, unindexed scans, and Cartesian join risks. The clause 'without executing it' distinguishes it from the sibling safe_query, so an agent can choose between them without opening a schema.

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?

Usage is only implied: the phrase 'without executing it' hints that this is the pre-flight/inspection option versus safe_query, but the description never explicitly says when to prefer this tool or what alternatives exist. No prerequisites or exclusions are stated.

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

describe_tableA

Retrieve column definitions, data types, nullability, and keys for a specific table.

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes	Name of the table to inspect

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. 'Retrieve' signals a read-only, non-destructive operation, and it usefully enumerates what metadata is returned (types, nullability, keys). However, it says nothing about behavior on a missing table, permissions required, or formatting of the results.

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?

A single sentence that front-loads the verb and lists the returned metadata with zero filler. Nothing to trim.

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?

For a simple one-parameter read tool with no output schema, describing the returned fields inline largely satisfies the agent's needs. Missing only edge-case behavior (invalid/nonexistent table, permission errors).

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 one well-documented parameter, so the schema already explains table_name. The phrase 'for a specific table' adds no meaning beyond the schema, making the baseline 3 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?

States a specific verb (Retrieve) and resource (column definitions, data types, nullability, keys) for a named table, which is clearly distinguishable from list_tables and analyze_query. It stops short of explicitly contrasting with those siblings, so it lands just below the top tier.

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?

Usage is implied: an agent can infer this is the tool for inspecting a single table's schema, but the description never states when to prefer it over list_tables or analyze_query, nor any preconditions.

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

list_tablesB

List all public database tables available for inspection and querying.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It discloses one useful scope qualifier ('public', excluding non-public schemas) but says nothing about return format, whether this can be slow on large catalogs, permission requirements, or that it is a read-only operation.

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

Conciseness4/5

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

A single front-loaded sentence with no padding. The trailing clause 'available for inspection and querying' is slightly loose but does carry usage context, so it is not waste.

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 zero-parameter read tool with no output schema and no annotations, the description covers the what but omits the practical details an agent would want: whether results are names, schema-qualified identifiers, or metadata, and confirmation that no side effects occur.

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 takes zero parameters, so per the rubric the baseline is 4. Nothing in the description is needed to disambiguate arguments.

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?

States a specific verb and resource: 'List all public database tables.' An agent immediately knows this is a discovery/enumeration tool. It does not explicitly differentiate itself from siblings like describe_table or safe_query, so it stops short of a 5.

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 phrase 'available for inspection and querying' hints that this is the entry point before describe_table or safe_query, but the workflow is only implied. No explicit when-to-use, when-not-to-use, or alternative is named.

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

safe_queryA

Execute a strictly read-only SQL query with automatic LIMIT enforcement and mutation blocking.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum rows to return (default: 100, max: 1000)
`query`	Yes	SQL query to execute (must be SELECT/EXPLAIN)

TDQS

A3.8/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 disclose key behavior: read-only enforcement, automatic LIMIT injection, and mutation blocking. It stops short of covering error behavior, result truncation, or permission requirements, but the safety profile is unusually well communicated for an unannotated tool.

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?

A single front-loaded sentence with zero filler. The scope constraint and the two enforcement behaviors are packed in without redundancy.

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?

No output schema exists, yet the description adequately frames what the tool returns conceptually (rows, capped by LIMIT). It omits result-format, error, and truncation details, but with both parameters fully documented in the schema and the safety semantics stated, it is close to complete for a two-parameter read tool.

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 both the limit (default 100, max 1000) and query (SELECT/EXPLAIN) parameters are already fully documented in the schema. The description adds no syntax, format, or edge-case detail beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb (Execute) and resource (SQL query) with a clear scope qualifier (strictly read-only). It does not explicitly distinguish itself from the sibling analyze_query, so an agent must infer the execute-vs-analyze split rather than being told.

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 phrase 'strictly read-only' and 'must be SELECT/EXPLAIN' implicitly define the acceptable usage context, but the description never says when to pick this over analyze_query or describe_table, nor what to do when a query is rejected. Usage is implied rather than 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 updatesv1.0.0Oct 21, 2026
- First observedanalyze_query
- First observeddescribe_table
- First observedlist_tables
- First observedsafe_query

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-10-21 05:55 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: list_tables vs describe_table target different levels of schema introspection, while safe_query executes read-only queries and analyze_query performs static analysis without execution. There is no meaningful overlap that would cause misselection.

Naming Consistency4/5

All names use snake_case, which is consistent. However, safe_query deviates slightly from the dominant verb_noun pattern seen in list_tables, describe_table, and analyze_query by using an adjective_noun construction.

Tool Count5/5

Four tools is well-scoped for a read-only PostgreSQL safety server. Each tool covers a necessary capability: table discovery, schema inspection, safe execution, and query risk analysis.

Completeness4/5

The core read-only workflow is covered: discover tables, inspect their structure, query safely, and analyze query risk. Minor gaps exist, such as explicit schema/view listing or index introspection, but agents can work around these using safe_query against system catalogs.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

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
dataOAuth
co.thinair
PostgreSQL, MySQL, and SQL Server in one session. 26 read-only MCP tools for AI agents.
Databases Developer Tools
2

Related MCP Servers

SQLite Read-Only MCP Server
Databases Developer Tools
skycandykey1
A
license
A
quality
D
maintenance
Enables safe, read-only SQL access to SQLite databases for AI agents, allowing schema exploration and SELECT queries with defense-in-depth protections.
Updated 4 months ago (2026-06-14 15:46 UTC)
3
MIT
Universal Database MCP Server
Databases RAG Systems
Fashad-Ahmed
A
license
A
quality
D
maintenance
Enables AI agents to securely query databases (PostgreSQL, SQLite, MySQL, DuckDB) with read-only defaults and multi-layer SQL injection prevention.
Updated 4 months ago (2026-06-11 21:37 UTC)
8
1
MIT
shop-mcp
Databases
stalexsm
F
license
A
quality
C
maintenance
Enables AI agents to safely explore and query a SQLite database in read-only mode, allowing them to inspect schema and run analytical SQL queries without risking data modification.
Updated 2 months ago (2026-08-23 15:32 UTC)
3
-
sql-guard-mcp
Databases Security
egoring
A
license
Not graded
quality
B
maintenance
Enables AI agents to safely query and explore SQLite databases through read-only, guard-protected tools that block writes, sensitive table access, and runaway queries.
Updated a month ago (2026-09-17 06:46 UTC)
1
MIT

PgSafe MCP (Lite Edition)

🛡️ Why PgSafe MCP?

⚡ Features (Lite Edition)

🚀 Quick Setup in 2 Minutes

1. Installation

2. Configure Claude Desktop (claude_desktop_config.json)

🛠️ MCP Tools Exposed to AI Agents

💎 Need Enterprise Data Protection? Upgrade to PgSafe Pro

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

2. Configure Claude Desktop (`claude_desktop_config.json`)