This MCP server provides safe, read-only access to PostgreSQL, MySQL, and MongoDB databases for schema inspection, query analysis, performance diagnostics, and health monitoring — designed for AI assistants like Claude, Cursor, and Windsurf.
Multi-database connectivity: Connect up to 3 databases simultaneously (PostgreSQL, MySQL, MongoDB) with automatic type detection from URL prefixes, referenced by aliases instead of direct credentials.
Schema inspection: List configured databases, schemas, tables/views/collections, sequences, and extensions; retrieve detailed object metadata including columns, constraints, indexes, and sample MongoDB documents.
Safe query execution: Run read-only SQL queries (SELECT, EXPLAIN, SHOW, WITH) with a 30-second timeout and read-only transactions enforced at the database level. MongoDB supports JSON-based queries with filtering.
Query analysis: Generate EXPLAIN plans (with optional ANALYZE), simulate hypothetical indexes via hypopg, and retrieve top/slow/resource-intensive queries via pg_stat_statements, MySQL performance_schema, or MongoDB system.profile.
Index analysis: Analyze query workloads to recommend missing indexes, detect sequential scan hotspots and FK columns without indexes, and analyze specific queries for index needs.
Health monitoring: Comprehensive checks covering index usage, connection status, replication lag, buffer hit ratios, vacuum/dead tuple status, sequence usage, and constraint validity.
Advanced diagnostics: Detect lock contention, blocking chains, idle-in-transaction sessions, and analyze table/index bloat with VACUUM recommendations.
Security: Credentials are never exposed to the AI (alias-only references), write operations are blocked in restricted mode, SQL statements are validated, and query timeouts are enforced. Zero configuration needed beyond environment variables in the MCP client config.
Provides safe, structured access to a PostgreSQL database, enabling health checks, index tuning, lock analysis, bloat detection, schema inspection, and SQL execution with read-only enforcement.
Click on "Install 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., "@postgres-mcp-js Run a full health check on the primary 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.
One MCP server. Any database. PostgreSQL, MySQL, and MongoDB — all at once. Give Claude, Cursor, Windsurf, or any MCP-compatible AI safe, structured access to all your databases without ever exposing credentials.
anydb-mcp is a Model Context Protocol (MCP) server that connects AI assistants to your databases. Connect up to 3 databases simultaneously — mix and match PostgreSQL, MySQL, and MongoDB. The AI can inspect schemas, diagnose performance problems, detect missing indexes, analyze locks, find slow queries across all databases in one call, and run safe read-only queries — all through a single, unified interface.
Works with: Claude Desktop, Claude Code, Cursor, Windsurf, Zed, and any MCP-compatible client.
Related MCP server: PostgreSQL MCP Server
PostgreSQL + MySQL + MongoDB — connect any combination, up to 3 at once
Auto-detects DB type from the URL prefix (postgresql://, mysql://, mongodb://)
Up to 3 databases simultaneously — primary, secondary, tertiary — switchable per tool call
14 built-in tools — schema inspection, health checks, index analysis, lock detection, bloat, slow queries
list_slow_queries fans out across all DBs — one call, combined report from every connected database
Credential isolation — passwords never appear in tool calls or AI responses; AI only sees aliases like "primary"
Restricted mode — read-only transactions enforced at the database level (PostgreSQL/MySQL), 30s timeout
Index miss detection — sequential scan hotspots, FK columns without indexes, unused index stats
Lock analysis — blocking chains (PostgreSQL/MySQL), current operations (MongoDB)
Table bloat — dead-tuple analysis with VACUUM recommendations (PostgreSQL)
hypopg support — simulate hypothetical indexes before creating them (PostgreSQL)
Zero config — credentials go in the MCP client env block, no .env file needed
npx anydb-mcpnpm install -g anydb-mcp
anydb-mcpgit clone https://github.com/shubham4038/anydb-mcp.git
cd anydb-mcp
npm install && npm run build
node dist/index.jsCredentials go in the env block — no .env file needed on the user's side.
File: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"anydb": {
"command": "npx",
"args": ["anydb-mcp"],
"env": {
"DB_PRIMARY_URL": "postgresql://user:pass@localhost:5432/mydb",
"ACCESS_MODE": "restricted"
}
}
}
}File: ~/.claude/settings.json
{
"mcpServers": {
"anydb": {
"command": "npx",
"args": ["anydb-mcp"],
"env": {
"DB_PRIMARY_URL": "postgresql://user:pass@localhost:5432/mydb",
"ACCESS_MODE": "restricted"
}
}
}
}Settings → MCP → Add new MCP server:
{
"command": "npx",
"args": ["anydb-mcp"],
"env": {
"DB_PRIMARY_URL": "mysql://user:pass@localhost:3306/mydb",
"ACCESS_MODE": "restricted"
}
}File: ~/.codeium/windsurf/mcp_config.json
{
"mcpServers": {
"anydb": {
"command": "npx",
"args": ["anydb-mcp"],
"env": {
"DB_PRIMARY_URL": "mongodb://user:pass@localhost:27017/mydb"
}
}
}
}Mix any combination of PostgreSQL, MySQL, and MongoDB. The AI uses the alias to target the right database — it never sees connection strings.
{
"env": {
"DB_PRIMARY_URL": "postgresql://user:pass@pg-host:5432/production",
"DB_PRIMARY_NAME": "production",
"DB_SECONDARY_URL": "mysql://user:pass@mysql-host:3306/legacy",
"DB_SECONDARY_NAME": "legacy",
"DB_TERTIARY_URL": "mongodb://user:pass@mongo-host:27017/analytics",
"DB_TERTIARY_NAME": "analytics",
"ACCESS_MODE": "restricted"
}
}DB type is auto-detected from the URL prefix:
URL prefix | Database |
| PostgreSQL |
| MySQL |
| MongoDB |
Example multi-DB AI prompts:
"List slow queries across all my databases"
"Compare index health between production and legacy"
"Show me what's currently locking on production"
"Is the analytics MongoDB missing any indexes?"
Every tool accepts an optional database parameter (defaults to the primary database). Call list_databases first to see what's configured.
Tool | PostgreSQL | MySQL | MongoDB |
| schemas | schemas | databases |
| ✅ | ✅ | ✅ |
| tables/views | tables/views | collections |
| columns + indexes | columns + indexes | indexes + sample doc |
Tool | Description |
| PostgreSQL/MySQL: SQL string. MongoDB: JSON |
| EXPLAIN plan. PostgreSQL supports |
| PostgreSQL: |
| All databases at once — historical + currently running slow queries, combined report |
Tool | PostgreSQL | MySQL | MongoDB |
| ✅ full | ✅ via perf_schema | ✅ via $indexStats |
| ✅ EXPLAIN | ✅ EXPLAIN | ✅ explain() |
| ✅ seq scans + FK | ✅ perf_schema | ✅ $indexStats |
Pass health_type: "all" or any specific check:
Check | PostgreSQL | MySQL | MongoDB |
| unused/invalid/duplicate | unused via perf_schema | unused via $indexStats |
| state breakdown | processlist | connections from serverStatus |
| dead tuples + wraparound | ❌ N/A | ❌ N/A |
| sequences > 75% used | ❌ N/A | ❌ N/A |
| replica lag + slots | ❌ N/A | ✅ replSetGetStatus |
| shared buffer hit ratio | InnoDB buffer pool | ❌ N/A |
| invalid constraints | ❌ N/A | ❌ N/A |
Tool | PostgreSQL | MySQL | MongoDB |
| blocking chains + idle-in-tx | InnoDB trx + data_lock_waits | currentOp |
| ✅ dead tuples + VACUUM | not applicable | not applicable |
Protection | How it works |
Credentials never reach the AI | DB URLs read from env at startup only — never in tool args or results |
Alias-only identity | AI sees |
DB-level read-only | PostgreSQL/MySQL: every query runs inside |
Statement validation | PostgreSQL/MySQL: first SQL keyword checked before query reaches the DB |
Query timeout | 30-second |
Completely isolated adapters | PostgreSQL, MySQL, MongoDB code never imports from each other — enforced by TypeScript |
CREATE EXTENSION IF NOT EXISTS pg_stat_statements; -- enables get_top_queries
CREATE EXTENSION IF NOT EXISTS hypopg; -- enables hypothetical index simulationAdd to postgresql.conf:
shared_preload_libraries = 'pg_stat_statements'performance_schema should be enabled by default in MySQL 5.6+. Verify:
SHOW VARIABLES LIKE 'performance_schema';Enable the profiler for slow query tracking:
db.setProfilingLevel(1, { slowms: 100 })docker build -t anydb-mcp .
docker run --rm -i \
-e DB_PRIMARY_URL="postgresql://user:pass@host:5432/mydb" \
-e DB_SECONDARY_URL="mysql://user:pass@host:3306/mydb" \
-e ACCESS_MODE=restricted \
anydb-mcpgit clone https://github.com/shubham4038/anydb-mcp.git
cd anydb-mcp
npm install
npm run dev # runs with tsx, no build step needed
npm run typecheck # type check only
npm run build # production buildEach database adapter is 100% self-contained. PostgreSQL code never imports MySQL code, MySQL never imports MongoDB code. They only share a common TypeScript interface.
src/
adapters/
types.ts ← shared interface only (no logic)
postgres/ ← all PostgreSQL code, isolated
mysql/ ← all MySQL code, isolated
mongodb/ ← all MongoDB code, isolated
db/
registry.ts ← only place that knows all 3 adapters exist
server.ts ← MCP tools, calls adapter.method() without knowing which DBAdd these in Settings → Topics for discoverability:
mcp model-context-protocol postgresql mysql mongodb database multi-database ai claude cursor llm developer-tools typescript nodejs
MIT — free to use, modify, and distribute.
Run comprehensive database health checks across multiple dimensions.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database alias to query. Omit to use the primary database. | |
| health_type | No | Which health check(s) to run. "all" runs everything. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description lacks any disclosure of behavioral traits such as whether queries are read-only, require special permissions, or have performance impact. A health check tool should at least indicate if it is safe to run concurrently.
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, front-loaded sentence that conveys the core functionality without wasted words. It could benefit from slight expansion, but remains concise.
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 two well-documented parameters, but lacks information about the output format or return structure. Given the absence of an output schema, the description should indicate what the agent can expect from the health checks.
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 coverage is 100% with clear descriptions for both parameters. The description adds 'across multiple dimensions' but does not elaborate beyond the schema-provided enum values and defaults. Baseline 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?
The name 'analyze_db_health' clearly indicates database health analysis. The description 'Run comprehensive database health checks across multiple dimensions' adds specificity about scope and distinguishes from siblings that focus on individual aspects like locks or bloat.
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?
No explicit guidance on when to use this tool versus siblings. The description implies use for a broad health overview, but does not state when not to use or provide alternatives, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect lock contention: blocking chains, long-running queries, idle-in-transaction sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database alias to query. Omit to use the primary database. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists what is detected but omits details on permissions, side effects, output format, or whether it is read-only (likely read-only given the purpose).
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 sentence with a list, no wasted words, and efficiently conveys the tool's purpose.
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?
With no output schema and one optional parameter, the description lacks detail on return format, expected output structure, and how results are presented, making it incomplete for a diagnostic 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?
Schema coverage is 100% (parameter 'database' documented). The description adds no parameter meaning beyond the schema; a 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?
The description clearly states the tool detects lock contention and lists specific aspects (blocking chains, long-running queries, idle-in-transaction sessions), differentiating it from sibling tools like analyze_db_health or analyze_table_bloat.
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 lock-related issues but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze specific SQL queries and identify missing indexes. Maximum 10 queries.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | List of SQL queries to analyze | |
| database | No | Database alias to query. Omit to use the primary database. | |
| max_index_size_mb | No |
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 a limit of 10 queries, which is a behavioral trait, but it does not state whether the tool is read-only (it appears to be, but not explicitly), what happens if more than 10 queries are submitted, or any side effects. Basic behavioral info is present but minimal.
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 extremely concise: one sentence plus a standalone limit statement. It is front-loaded and contains no wasted words or repetition. Every part serves a purpose.
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 has 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the output format (e.g., list of missing indexes), prerequisites (e.g., query plan access), or how the database parameter affects analysis. The complexity demands more contextual detail.
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 has 3 parameters with 67% description coverage (queries and database have descriptions, max_index_size_mb does not). The description redundantly states 'Maximum 10 queries' (already in schema) but adds no meaning for max_index_size_mb (what does it limit? Index size?). The description fails to compensate for the missing schema description for this parameter.
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: analyze specific SQL queries to identify missing indexes, with a limit of 10 queries. This distinguishes it from siblings like analyze_workload_indexes (which likely analyzes workloads) and detect_index_misses (which may not take explicit 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 description implies usage when you have specific SQL queries to check for missing indexes, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., analyze_workload_indexes, detect_index_misses) or any exclusions. No when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect table and index bloat from dead tuples. Returns vacuum recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database alias to query. Omit to use the primary database. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavioral traits. It only states the primary action and output, omitting whether the operation is read-only, requires special permissions, or any side effects.
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 sentences totaling 11 words are highly concise and front-loaded with the key action and output. No superfluous 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?
For a low-complexity tool with one optional parameter and no output schema, the description sufficiently conveys purpose and return value. Could mention safety (read-only) but not essential.
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 coverage is 100% (single parameter 'database' described). The description adds no parameter details beyond the schema, so baseline score of 3 applies.
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: 'Detect table and index bloat from dead tuples' with a specific verb (detect) and resource (table and index bloat). It also mentions output (vacuum recommendations), which distinguishes it from sibling tools like analyze_db_health or analyze_locks.
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?
No guidance on when to use this tool versus alternatives. It neither specifies prerequisites nor suggests scenarios where other tools (e.g., analyze_db_health) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze query workload from pg_stat_statements and recommend missing indexes.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database alias to query. Omit to use the primary database. | |
| max_index_size_mb | No | Maximum index size budget in MB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool analyzes and recommends, but does not disclose whether it modifies the database, requires special privileges, or what side effects (if any) occur. The read-only nature is implied but not explicit.
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 of 12 words. It efficiently conveys the core purpose, though it could be slightly expanded to include usage guidance without losing conciseness.
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 lacks information about the output format, return value, or what actions the agent should take with the recommendations. Given no output schema, this is a significant gap for agent decision-making.
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?
Both parameters are fully described in the input schema with clear descriptions. The tool description adds nothing beyond the schema, meeting the baseline for 100% 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 verb 'Analyze', the resource 'query workload from pg_stat_statements', and the outcome 'recommend missing indexes'. It distinguishes from siblings like 'analyze_query_indexes' and 'detect_index_misses' by specifying the data source and purpose.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies use for index recommendation based on workload, but does not mention alternatives like 'analyze_query_indexes' or prerequisites like requiring pg_stat_statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect tables likely suffering from missing indexes: seq-scan dominance, FK columns without indexes, under-indexed hot tables.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database alias to query. Omit to use the primary database. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states detection criteria. It does not disclose whether the tool is read-only, requires permissions, or what the output format is. Key behavioral traits are missing.
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 extremely concise: one sentence with a colon-separated list of indicators. Every word contributes meaning, and the main verb 'Detect' is front-loaded. No wasted text.
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 there is no output schema, the description should explain what the tool returns. It lists detection criteria but omits details like the format or structure of results. For a simple tool with a single optional parameter, this is acceptable but not entirely 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% for the single parameter 'database', which is clearly described in the schema. The tool description adds no additional semantic value beyond the schema definition, so 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?
The description clearly states the tool's function: detecting tables likely suffering from missing indexes, with specific indicators like seq-scan dominance, FK columns without indexes, and under-indexed hot tables. This distinguishes it from sibling tools like analyze_workload_indexes, which focus on queries rather than table-level detection.
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?
No guidance is provided on when to use this tool versus alternatives such as analyze_workload_indexes or analyze_query_indexes. The description does not mention exclusion criteria or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a read-only SQL query (SELECT, EXPLAIN, SHOW, WITH). Write operations are blocked. Max execution time: 30 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Read-only SQL query | |
| database | No | Database alias to query. Omit to use the primary database. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, blocked writes, and 30-second timeout. Sufficient given no annotations, though more detail on side effects could be added.
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 with purpose and constraints front-loaded. No wasted words.
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?
Adequate for a simple read-only SQL tool. No output schema, but return format is implicit. Could mention result format, but not critical.
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 covers both parameters. Description adds context for database parameter (primary database fallback), but does not significantly enhance beyond 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?
Clear verb+resource: 'Execute a read-only SQL query' with explicit query types (SELECT, EXPLAIN, SHOW, WITH). Distinct from sibling analysis tools.
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?
Explicitly states read-only constraint and timeout, but lacks guidance on when to use versus siblings like explain_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the query execution plan. Supports hypothetical index simulation (requires hypopg extension).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to explain | |
| analyze | No | Run EXPLAIN ANALYZE (executes the query — use with care on write queries in unrestricted mode) | |
| database | No | Database alias to query. Omit to use the primary database. | |
| hypothetical_indexes | No | Hypothetical indexes to simulate (requires hypopg extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic function. Importantly, it omits that EXPLAIN ANALYZE executes the query, which is a critical side effect. Annotations are absent, so the description carries the full burden, but fails to address safety or execution implications.
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 extremely concise with two sentences, no filler, and front-loads the primary purpose. Every word contributes meaning.
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?
Despite its clarity, the description is minimal. It does not mention the return format (e.g., plan in text or JSON), nor does it provide guidance on when to choose this tool over sibling analysis tools. For a 4-parameter tool with no output schema, this is adequate but not comprehensive.
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?
While the input schema already describes all 4 parameters (100% coverage), the description adds value by noting that hypothetical index simulation requires the hypopg extension, providing context beyond the schema's descriptions.
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: obtaining a query execution plan. It also highlights the unique capability of hypothetical index simulation via hypopg, effectively distinguishing it from sibling analysis tools.
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?
No guidance is provided on when to use this tool versus sibling tools like analyze_query_indexes or execute_sql. The description mentions the hypopg extension prerequisite but lacks usage context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get columns, constraints, and indexes for a table or view.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database alias to query. Omit to use the primary database. | |
| object_name | Yes | Table, view, sequence, or extension name | |
| object_type | No | table | |
| schema_name | Yes | Schema name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose read-only nature, permissions, performance impact, or other behavioral traits beyond what is inferred from name.
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?
Single sentence, no redundancy, but omits mention of all supported object types, slightly reducing accuracy.
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?
No output schema; description partly covers return values (columns, constraints, indexes) but not for all object types, and lacks error or permission context.
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?
Description adds no meaning to parameters; schema already describes them at 75% coverage, but the description does not clarify how parameters relate to the output.
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 columns, constraints, and indexes for a table or view, but omits sequences and extensions as valid object types, making it slightly inaccurate.
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?
No guidance on when to use this tool vs siblings like list_objects or explain_query; lacks context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the slowest or most resource-intensive queries using pg_stat_statements.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sort_by | No | "resources" = combined CPU + I/O; "total_time" = cumulative; "mean_time" = per execution | resources |
| database | No | Database alias to query. Omit to use the primary database. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the tool 'report the slowest or most resource-intensive queries' but fails to disclose whether it is a read-only operation, potential performance impact, required permissions, or output characteristics.
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 that front-loads the action ('Report') and resource. However, the mention of 'using pg_stat_statements' is slightly redundant if the tool implicitly uses that view.
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 lack of an output schema and the complexity of the tool (three parameters, zero required), the description should provide context on output format or prerequisites (e.g., requiring pg_stat_statements extension). It does not meet this need.
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 already describes 'sort_by' and 'database' with some detail, and 'limit' has constraints. The description adds no additional parameter meaning beyond what the schema provides, and with 67% schema coverage, it does not compensate for the lack of description on 'limit'.
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 'Report' and identifies the resource as 'slowest or most resource-intensive queries', sourced from 'pg_stat_statements'. This clearly distinguishes it from sibling tools like 'explain_query' or 'analyze_workload_indexes'.
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?
While the description implies usage for performance diagnostics, it does not explicitly state when to prefer this tool over alternatives (e.g., 'analyze_workload_indexes' for index-specific analysis) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured database aliases. Use the returned names in the "database" parameter of other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions listing aliases but does not disclose if the operation is expensive, requires auth, or any side effects. It is adequate but lacks depth.
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 sentences, no wasted words. Every sentence provides essential information. Perfectly concise.
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?
For a parameterless listing tool with no output schema, the description fully explains what it does and how to use the output. Complete for its simplicity.
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 tool has zero parameters. Baseline score of 4 applies as the description adds no parameter info, but that's fine since there are none.
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 lists configured database aliases, a specific verb+resource. It distinguishes from sibling tools (analysis, query, etc.) by being a listing tool.
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 explicitly instructs to use the returned names in the 'database' parameter of other tools, providing clear context. However, it does not exclude any situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tables, views, sequences, or extensions in a schema.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database alias to query. Omit to use the primary database. | |
| object_type | No | Type of objects to list | table |
| schema_name | Yes | Target schema name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the function without specifying side effects, permissions, or that it is a read-only operation. For a listing tool, minimal transparency is given.
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?
Single sentence, 9 words, no fluff. Front-loaded with the action and target.
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?
Adequate for a simple list tool but lacks detail on return format (e.g., list of names, details) and no output schema exists. Does not mention optional parameters like database or object_type default behavior.
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 coverage is 100%, so baseline is 3. The description repeats the object types already defined in the enum, adding no new meaning or constraints 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 verb 'List' and the resource 'tables, views, sequences, or extensions in a schema'. It precisely defines the scope and distinguishes from sibling tools like list_databases and list_schemas.
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?
No guidance on when to use this tool vs alternatives such as get_object_details or execute_sql. There are no contextual hints about prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all schemas in the database.
| Name | Required | Description | Default |
|---|---|---|---|
| database | No | Database alias to query. Omit to use the primary database. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the basic action, without details on return format, error handling, or read-only nature. More transparency is needed.
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 sentence that is front-loaded and concise. Every word adds value; there is no superfluous 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?
For a simple list tool with one optional parameter and no output schema, the description is functional but minimal. It does not state what the output contains (e.g., schema names only or details), which could be incomplete for agents.
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% for the single parameter. The description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate as the schema already documents the parameter adequately.
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 ('List') and the resource ('all schemas in the database'). It is specific and unambiguous, distinguishing the tool from sibling analysis tools.
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 indicates when to use the tool (to list schemas) but does not provide guidance on when not to use it or mention alternatives. There are no siblings that conflict, so the lack of explicit exclusions is acceptable but still a gap.
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. Dates show when Glama detected each change.
v1.0.0analyze_db_healthanalyze_locksanalyze_query_indexesanalyze_table_bloatanalyze_workload_indexesdetect_index_missesexecute_sqlexplain_queryget_object_detailsget_top_querieslist_databaseslist_objectslist_schemasMost tools have clear and distinct purposes, though the index analysis tools (analyze_query_indexes, analyze_workload_indexes, detect_index_misses) overlap somewhat in focus, potentially causing some confusion for an agent.
All tools use a consistent underscore-separated verb_noun pattern (e.g., analyze_locks, list_databases), making the tool set predictable and easy to navigate.
With 13 tools, the set is well-scoped for a database analysis server, covering essential operations without being overwhelming or insufficient.
The tool set comprehensively covers read-only database analysis: health, locks, bloat, indexes, query explanation, and object listing. There are no obvious gaps for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Xata MCP server lets AI agents interact with your Xata projects, and Postgres database branches.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shubham4038/postgres-mcp-js'
If you have feedback or need assistance with the MCP directory API, please join our Discord server