A
licenseA
qualityD
maintenanceEnables safe, read-only SQL access to SQLite databases for AI agents, allowing schema exploration and SELECT queries with defense-in-depth protections.
3
MIT
PgSafe MCP
Based on the exposed server schema, this server provides read-only database inspection and SQL query safety analysis.
List all public database tables available for inspection and querying.
Describe a table’s columns, data types, nullability, and keys.
Execute strictly read-only SQL queries (SELECT/EXPLAIN) with automatic LIMIT enforcement (default 100, max 1000) and mutation blocking.
Analyze SQL queries for dangerous operations, unindexed scans, and Cartesian join risks without executing them.
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.
Click on "Deploy 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., "@PgSafe MCPshow 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
PgSafe MCP is a read-only Model Context Protocol server for PostgreSQL and SQLite that enables AI coding agents in Claude Desktop, Cursor, Windsurf, and Antigravity to inspect schemas, run bounded analytical SQL queries with automatic PII masking, and test DML statements inside rolled-back SQLite transactions.
Quickstart
Run directly via uvx:
uvx pgsafe-mcpClaude Desktop / Cursor configuration:
{
"mcpServers": {
"pgsafe-mcp": {
"command": "uvx",
"args": ["pgsafe-mcp"],
"env": {
"DATABASE_URL": "postgresql://readonly_user:password@localhost:5432/analytics_db"
}
}
}
}For SQLite databases:
{
"mcpServers": {
"pgsafe-mcp": {
"command": "uvx",
"args": ["pgsafe-mcp"],
"env": {
"DATABASE_URL": "sqlite:///path/to/database.db"
}
}
}
}For PostgreSQL support when installing from source:
pip install "pgsafe-mcp[postgres]"Related MCP server: shop-mcp
Core Capabilities
Lexer-Aware Read-Only SQL Guard: Tokenizes SQL comments and string/dollar-quoted literals before validating statement boundaries, blocking
DROP,TRUNCATE,DELETE,UPDATE,INSERT,ALTER,COPY,VACUUM,ATTACH,EXPLAIN ANALYZE, and semicolon chaining.Engine-Level Read-Only Enforcement: Configures PostgreSQL sessions with
SET default_transaction_read_only = onand SQLite connections with?mode=roplussqlite3.Connection.set_authorizer.Top-Level Row Limit Enforcement: Applies
LIMITbounds to outerSELECTandWITHqueries without corruptingPRAGMA,EXPLAIN,OFFSET, or trailing SQL comments.Live PII Redaction: Masks emails, payment card numbers, phone numbers, password hashes, and sensitive column values before returning rows to the LLM context.
SQLite Dry-Run Mutation Harness: Simulates single-statement
INSERT,UPDATE, orDELETEchanges inside an immediate transaction with authorizer restrictions and automaticROLLBACK.Heuristic Query & Index Inspection: Flags missing
WHEREclauses, unconstrained joins, and candidate filter columns for indexing.
MCP Tools
Tool | Parameters | Description |
| (none) | Lists user tables in the connected PostgreSQL or SQLite database |
|
| Returns column names, types, nullability, defaults, and primary key metadata |
|
| Validates read-only SQL, enforces row limits, executes query, and masks PII |
|
| Simulates a single DML statement on SQLite inside an auto-rolled-back transaction |
|
| Evaluates read-only safety and full-scan / Cartesian join risk heuristics |
|
| Suggests candidate indexes from |
| (none) | Reports active guard status and credential-redacted |
Related Open-Source MCP Servers
Package | Description | Repository |
genesis-blackbox | Runtime flight recorder and AST blast-radius crash compiler | |
crawlengine-mcp | HTTP web extraction, clean Markdown conversion, and proxy rotation | |
browserbridge-mcp | Session-pooled HTTP DOM inspection and SHA-256 action trail receipts | |
omnibridge-mcp | Multi-channel notification bus with SQLite retry queue | |
sysflow-mcp | Linux resource inspection, systemd unit generator, and log tailer | |
fastmcp-forge | MCP server framework and project scaffolder |
Support
If this project is useful in your workflow, you can support ongoing maintenance on Ko-fi.
License
MIT License. Copyright (c) 2026 Johann Schiffer.
Available Tools
4 toolsanalyze_queryA
Analyze a SQL query for dangerous operations, unindexed scans, and Cartesian join risks without executing it.
| 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.
| 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.
| 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.
| 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 updates
v1.0.0- First observed
analyze_query - First observed
describe_table - First observed
list_tables - First observed
safe_query
TDQS
A3.8/5.0
Scored 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
Related MCP Connectors
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
- dataOAuthco.thinair
PostgreSQL, MySQL, and SQL Server in one session. 26 read-only MCP tools for AI agents.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables 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.3MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to safely query and explore SQLite databases through read-only, guard-protected tools that block writes, sensitive table access, and runaway queries.1MIT
- AlicenseBqualityBmaintenanceEnables AI assistants to safely run read-only SQL against SQLite databases through whitelist-validated queries, capped result sets, and confined file paths. It also exposes schema inspection so models can discover tables and columns before querying.2MIT