Provides read-only SQL querying for DuckDB (columnar analytics, in-process) including native querying of Parquet, CSV, and JSON files while applying security layers.
Provides read-only SQL querying, schema inspection, and query explanation for MySQL databases with built-in injection prevention.
Provides read-only SQL querying, schema inspection, and query explanation for PostgreSQL databases with multi-layer injection prevention and security hardening.
Provides read-only SQL querying for SQLite databases (local files) with zero infrastructure and defense-in-depth security layers.
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., "@Universal Database MCP Server list all tables in the database"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The security-first, Python-native MCP server for database access from AI agents.
Most database MCP servers give AI agents raw SQL access and hope for the best. This server assumes the LLM is untrusted input and applies 8 layers of injection prevention before any query reaches your database — including blocking UNION attacks, stacked statements, time-based injection, and comment bypasses.
Supports: PostgreSQL · SQLite · MySQL · DuckDB (columnar analytics)
Related MCP server: mcp-server-postgres
No Docker. No cloud account. No database server to install. DuckDB and SQLite run in-process:
# Query a local SQLite database — one command, zero infra
SQLITE_PATH=./myapp.db uvx universal-db-mcp
# Query a local DuckDB file or parquet files
DUCKDB_PATH=./analytics.duckdb uvx universal-db-mcp
# In-memory DuckDB for throwaway analysis
DUCKDB_PATH=:memory: uvx universal-db-mcpAdd to Claude Code in ~/.claude/mcp_servers.json, or to Claude Desktop in
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) /
%APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"mydb": {
"command": "uvx",
"args": ["universal-db-mcp"],
"env": {
"SQLITE_PATH": "/Users/you/projects/myapp/db.sqlite3",
"ALLOW_DESTRUCTIVE": "false"
}
}
}
}Restart Claude Desktop / Claude Code after saving — that's it.
That's it. Claude Code discovers the tools automatically.
More client configs (Claude Desktop, Cursor, Windsurf, Docker) in
examples/.
Read-only by default. Defense-in-depth. Every query validated before it touches the driver.
Layer | What it does |
1 | Driver-level read-only — PostgreSQL session flag, SQLite |
2 | Keyword blocking — |
3 | Injection pattern detection — UNION SELECT, stacked statements, SQL comments ( |
4 | Multiple statement rejection — |
5 | Parameter type enforcement — only |
6 | Result size limits — truncated at |
7 | Identifier sanitization — table/column names stripped of metacharacters in internally-generated SQL |
8 | DuckDB filesystem blocklist — |
Full threat model: docs/SECURITY.md
DuckDB runs in-process (no server) and reads Parquet, CSV, JSON natively. Connect AI agents to your analytics data without spinning up a warehouse:
# Query parquet files directly
DUCKDB_PATH=:memory: uvx universal-db-mcpThen in Claude Code:
You: "Load sales.parquet and show me monthly revenue by region"
Claude: [uses query tool → SELECT region, strftime('%Y-%m', date) AS month, SUM(revenue) ...]No separate NL-to-SQL tool needed — Claude already does this. Give it the
schema tool and ask in plain English:
You: "Which customers placed more than 5 orders last month?"
Claude: [calls schema() to see table structure, then query() with the
generated SQL — every query still passes through all 8 security
layers before touching your database]Pair with dry_run: true (DRYRUN=true) while prototyping — Claude gets the
query plan back without anything executing.
docker build -t universal-db-mcp .
docker run -i --rm \
-e POSTGRES_URI=postgresql://readonly:pass@host.docker.internal:5432/mydb \
-e ALLOW_DESTRUCTIVE=false \
universal-db-mcpSee examples/docker_mcp_config.json for
wiring this into an MCP client.
# PostgreSQL
POSTGRES_URI=postgresql://readonly:pass@localhost/mydb uvx universal-db-mcp
# SQLite (local file, zero infra)
SQLITE_PATH=./db.sqlite3 uvx universal-db-mcp
# MySQL
MYSQL_URI=mysql://readonly:pass@localhost/mydb uvx universal-db-mcp
# DuckDB (columnar, in-process analytics)
DUCKDB_PATH=./analytics.duckdb uvx universal-db-mcp
# Multiple databases simultaneously
POSTGRES_URI=... SQLITE_PATH=... uvx universal-db-mcpTool | Description |
| Execute SQL — read-only by default, all 8 security layers apply |
| Inspect tables and columns — no config needed |
| Get query execution plan without running the query |
| Check connection status, DB version, and pool metrics |
| Show all configured databases and connection state |
| Inspect the last 100 executed queries |
| Capture current schema for drift detection |
| Compare current schema against the last snapshot |
v1.1.0: dry-run mode (DRYRUN=true), table allowlists (WHITELISTED_TABLES), query
complexity warnings, structured audit logs, and a --check CLI flag for connectivity
validation. See CHANGELOG.md.
# ── PostgreSQL ─────────────────────────────────────
POSTGRES_URI=postgresql://user:pass@host:5432/db
POSTGRES_READONLY=true # default: true
# ── SQLite ─────────────────────────────────────────
SQLITE_PATH=/path/to/database.db
SQLITE_READONLY=true # default: true
# ── MySQL ──────────────────────────────────────────
MYSQL_URI=mysql://user:pass@host:3306/db
MYSQL_READONLY=true # default: true
# ── DuckDB ─────────────────────────────────────────
DUCKDB_PATH=/path/to/analytics.duckdb # or :memory:
DUCKDB_READONLY=true # default: true
# ── Security ───────────────────────────────────────
ALLOW_DESTRUCTIVE=false # default: false — blocks INSERT/UPDATE/DELETE/DROP
MAX_RESULT_ROWS=1000 # truncate large results
ENABLE_LOGGING=true # log queries to stderr
QUERY_TIMEOUT=30 # seconds
RATE_LIMIT_RPM=60 # requests per minuteAlways use a dedicated read-only account. Never give the MCP server credentials that can modify data.
PostgreSQL:
CREATE USER mcp_agent WITH PASSWORD 'strong_random_password';
GRANT CONNECT ON DATABASE mydb TO mcp_agent;
GRANT USAGE ON SCHEMA public TO mcp_agent;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_agent;MySQL:
CREATE USER 'mcp_agent'@'localhost' IDENTIFIED BY 'strong_random_password';
GRANT SELECT ON mydb.* TO 'mcp_agent'@'localhost';
FLUSH PRIVILEGES;git clone <repo-url>
cd universal-db-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
# Run tests (67+ passing, no external DB required for SQLite + DuckDB)
pytest
# Security tests only
pytest tests/test_security.py -v
# With coverage
pytest --cov=src/universal_db_mcp --cov-report=term-missingsrc/universal_db_mcp/
├── server.py # FastMCP server — 5 tools
├── config.py # Env-var config via Pydantic
├── adapters/
│ ├── base.py # Abstract adapter + result dataclasses
│ ├── postgresql.py # asyncpg, connection pool, read-only via init callback
│ ├── sqlite.py # aiosqlite, read-only via file URI mode=ro
│ ├── mysql.py # aiomysql, DictCursor
│ └── duckdb.py # duckdb, thread-pool executor, lock-guarded
└── security/
└── sanitizer.py # SQLSanitizer — 8-layer injection prevention
docs/
└── SECURITY.md # Full security architecture and threat modelThis project | Google MCP Toolbox | |
Runtime | Python — | Go binary / Docker |
Local DBs | SQLite + DuckDB zero-infra | No SQLite |
Analytics | DuckDB in-process | No columnar adapter |
Auth model | Read-only by default + env vars | IAM / GCP-native |
SQL injection | 8-layer sanitizer + parameterized | Auth-focused |
Extend | Python ecosystem, any | Go plugins |
Vendor | Neutral | Google Cloud funnel |
Different tools for different jobs. Use this when you want Python-native, local-first, security-hardened access without cloud dependencies.
MIT — LICENSE
Security Notice: This server provides AI agents with database access. Always
use read-only credentials, review docs/SECURITY.md before
production deployment, and never commit .env files.
Get query execution plan without running the query.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to analyze | |
| params | No | Optional parameters for the query | |
| database | No | Database key (format: "type:name") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining side effects, and it does so by stating the query is not run. This is the most important behavioral detail, though it does not elaborate on other potential behaviors such as needing a live database connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the core purpose and immediately clarifies the key non-execution behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values. It covers the main purpose, the critical behavioral constraint, and is supported by schema-level parameter details. It could be slightly more explicit about how this relates to the query sibling tool, but it is still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema descriptions add moderate value: 'sql' is tied to analysis, 'params' is generic, and 'database' provides a useful format hint. None of the parameter descriptions are deeply enriched beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('query execution plan'), and explicitly notes it does not run the query. This distinguishes it well from sibling tools like query, which actually executes queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without running the query' gives clear guidance that this is for plan inspection rather than execution. It does not explicitly name alternatives like query, but the intent is still clear enough for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check database connection health and get server version info.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database key (format: "type:name") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description uses 'Check' and 'get', suggesting a read-only operation, but it does not explicitly guarantee no side effects or mention any side effects that might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence to convey the tool's purpose without unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, but it is not shown, and the description does not mention what the response will contain (e.g., a status object or version string). This leaves some ambiguity about the expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'database' has a description that merely repeats the schema's format hint ('Database key (format: "type:name")'), adding no new meaning or usage guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and distinct objects ('database connection health' and 'server version info'), distinguishing it from sibling tools like schema or query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for health checks but does not explicitly state when to use this tool versus alternatives (e.g., query for specific data or schema for structure).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured databases and their connection status.
Returns: JSON with list of databases including key, type, database name, and connection status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description accurately reflects a read-only listing operation; no side effects mentioned or contradicted, though it doesn't explicitly state immutability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no fluff, and the purpose is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mentions return format (JSON with key fields) though no explicit output schema is shown; sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the empty schema is fully covered; baseline score applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all configured databases with connection status, which is distinct from sibling tools like query or schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when a high-level overview of databases is needed, but does not explicitly differentiate from alternatives like health or schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SQL query against the database.
Supports parameterized queries for injection safety. In read-only mode, destructive operations (INSERT, UPDATE, DELETE, DROP, etc.) are blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute | |
| params | No | Optional list of parameters for parameterized queries (use instead of string formatting) | |
| database | No | Database key (format: "type:name"). Required when multiple databases are configured. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It discloses read-only mode blocking destructive operations, but does not explain error behavior, side effects, or what happens to the query if parameters are omitted, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and immediately follow with important usage constraints. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. It covers the essential inputs and key behavioral constraints, though it could mention potential errors or edge cases for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already defines the parameters, but the description adds meaning by explaining that params are for parameterized queries and database is required when multiple databases are configured. This goes beyond the raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Execute a SQL query against the database' with a clear verb and resource. It is distinct from sibling tools like schema or explain, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance to use parameterized queries for injection safety and notes that destructive operations are blocked in read-only mode. While not explicitly contrasting with sibling tools, these practical tips help decide how to invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent query execution history (most recent first).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of history entries to return (default 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does disclose ordering ('most recent first') and implies read-only behavior via 'Get', but it does not mention side effects, scope of history, or what constitutes a query entry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action verb, and contains no unnecessary words or repetition. It is very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema present, so the description does not need to explain return fields. It could mention the scope of history (e.g., session vs. persistent), but the core usage is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'limit' parameter with a default and meaning. The description adds no additional parameter semantics, so the baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('query execution history'), and the 'most recent first' qualifier adds useful specificity. It is easily distinguished from sibling tools like query, explain, or schema, which serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if an agent needs past query executions, this is the tool. However, it does not explicitly state when to use this versus alternatives, nor does it mention any exclusions such as 'use query to execute a new query'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get database schema information: tables, columns, types, and constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| tables | No | Optional list of specific table names to inspect | |
| database | No | Database key (format: "type:name") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Get' implies a read-only operation, which is transparent for a schema inspection tool. However, the description does not explicitly state side effects, permissions, or limitations. Given that annotations are absent, the description carries the full burden and only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant details. It efficiently conveys the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the core function for a simple tool, and an output schema exists so return values need not be described. However, it lacks any context on when to use this tool relative to other schema-related siblings, leaving some completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (tables and database) with descriptions, achieving 100% coverage. The tool description adds no additional meaning beyond the schema definitions, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves database schema information (tables, columns, types, constraints). This verb-resource pairing is specific and distinct from sibling tools like query or explain, which focus on data operations rather than structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as snapshot_schema or schema_diff. No conditions, exclusions, or comparison with siblings are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare the current schema against the last snapshot taken with snapshot_schema.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database key (format: "type:name") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not mention side effects, read-only nature, or safety. While a diff operation is likely non-destructive, this is not explicitly disclosed, leaving uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It efficiently conveys the core functionality without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter) and the presence of an output schema (indicated by the context), the description sufficiently covers the purpose and parameter. No additional context is required for a user to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'database' has a description with a format hint ('type:name'), which aids understanding. However, the meaning of null (default) is not explained, and there is no elaboration on how the database key is used in the comparison.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (compare), the subject (current schema), and the reference (last snapshot). It distinguishes itself from sibling tools like snapshot_schema and schema by conveying a comparison operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the need for a previous snapshot (taken with snapshot_schema) but does not explicitly state when to use this tool over others, such as schema or query_history. No direct guidance on conditions or alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a snapshot of the current database schema for later drift detection.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database key (format: "type:name") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey side effects. 'Take a snapshot' implies some persistence or state change, but it is ambiguous whether the tool is read-only or writes a stored snapshot. There is no mention of side effects, permissions, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary detail. It front-loads the action and resource, and the optional parameter is handled succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), the description is largely complete. It does not mention return values or output format, but with an output schema present, this is a minor omission. It could be slightly richer by naming the expected output type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'database' is well-described with its format ('type:name') and optionality (default null). The description fully clarifies the expected input, leaving no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (take a snapshot) and the resource (database schema), and the phrase 'for later drift detection' distinguishes it from simply viewing the schema. However, it does not explicitly name sibling tools like schema_diff, so it misses full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a vague purpose ('for later drift detection') but gives no explicit guidance on when to use this tool versus alternatives such as schema or schema_diff. It lacks prerequisites, context, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.3explainhealthlist_databasesqueryquery_historyschemaschema_diffsnapshot_schemaScored across 8 tools
Each tool targets a distinct operation: schema introspection, query execution, plan explanation, health checking, history, schema snapshot/diff, and database listing. The schema-related trio (schema, snapshot_schema, schema_diff) and health/list_databases have adjacent concerns, but descriptions clarify boundaries.
Tool names mix styles: noun-only (schema, health), verb-only (query, explain), and snake_case compounds (query_history, snapshot_schema, schema_diff, list_databases). All are readable and lowercase, but there is no consistent verb_noun pattern.
Eight tools is well-scoped for a universal database server, covering introspection, execution, planning, health, history, and schema drift. Each tool earns its place without redundancy.
The set covers schema reading, arbitrary SQL execution, query plans, health checks, history, and schema drift detection, which covers most database workflows. Missing dedicated transaction control or database administration tools, though query can handle many of those operations.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
