Analyze MySQL databases: inspect schemas, detect index problems, analyze table bloat, and explain query plans.
Analyze PostgreSQL databases: inspect schemas, detect index problems, analyze table bloat, and explain query plans.
Analyze SQLite databases: inspect schemas, detect index problems, analyze table bloat, and explain query plans.
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., "@mcp-db-analyzer Check for missing indexes and slow queries"
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.
A Model Context Protocol (MCP) server that gives AI assistants deep visibility into your databases. It inspects schemas, detects index problems, analyzes table bloat/fragmentation, and explains query plans — so your AI can give you actionable database optimization advice instead of generic suggestions.
Supports PostgreSQL, MySQL, and SQLite.
There are dozens of database MCP servers — most are CRUD gateways (run queries, list tables). This tool analyzes your database: schema problems, missing indexes, bloated tables, slow queries, vacuum health.
Other analytical MCP servers (CrystalDBA, pg-dash, MCP-PostgreSQL-Ops) cover PostgreSQL only. MCP DB Analyzer is the only analytical MCP server that supports PostgreSQL, MySQL, and SQLite in a single npx install — no Python, no Go, no Docker.
Related MCP server: PostgreSQL MCP Server
9 MCP tools for comprehensive database analysis
PostgreSQL + MySQL + SQLite support via --driver flag
Read-only by design — all queries wrapped in READ ONLY transactions
Markdown output optimized for LLM consumption
Zero configuration — just set DATABASE_URL
Generate exportable diagnostic reports (HTML + PDF) with a Pro license key.
Full JVM thread dump analysis report with actionable recommendations
PDF export for sharing with your team
Priority support
$9.00/month — Get Pro License
Pro license key activates the generate_report MCP tool in mcp-jvm-diagnostics.
npx mcp-db-analyzerOr install globally:
npm install -g mcp-db-analyzerSet the DATABASE_URL environment variable:
export DATABASE_URL="postgresql://user:password@localhost:5432/mydb"Or use individual PG variables: PGHOST, PGPORT, PGDATABASE, PGUSER, PGPASSWORD.
Set DATABASE_URL with a MySQL connection string and pass --driver mysql:
export DATABASE_URL="mysql://user:password@localhost:3306/mydb"
mcp-db-analyzer --driver mysqlOr use individual MySQL variables: MYSQL_HOST, MYSQL_PORT, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD.
You can also set DB_DRIVER=mysql as an environment variable instead of passing the flag.
Pass a file path via DATABASE_URL and use --driver sqlite:
export DATABASE_URL="/path/to/database.db"
mcp-db-analyzer --driver sqliteAdd to ~/.claude/claude_desktop_config.json:
{
"mcpServers": {
"db-analyzer": {
"command": "npx",
"args": ["-y", "mcp-db-analyzer"],
"env": {
"DATABASE_URL": "postgresql://user:password@localhost:5432/mydb"
}
}
}
}{
"mcpServers": {
"db-analyzer": {
"command": "npx",
"args": ["-y", "mcp-db-analyzer", "--driver", "mysql"],
"env": {
"DATABASE_URL": "mysql://user:password@localhost:3306/mydb"
}
}
}
}{
"mcpServers": {
"db-analyzer": {
"command": "npx",
"args": ["-y", "mcp-db-analyzer", "--driver", "sqlite"],
"env": {
"DATABASE_URL": "/path/to/database.db"
}
}
}
}Once configured, try these prompts in Claude:
"Show me the schema and how tables are related" — Returns table structures, foreign keys, and identifies orphan tables
"Are there any slow queries or missing indexes?" — Ranks slow queries by execution time and suggests indexes to add
"How many connections are active? Are any queries blocked?" — Shows connection pool utilization, idle-in-transaction sessions, and blocked queries
inspect_schemaList all tables with row counts and sizes, or drill into a specific table's columns, types, constraints, and foreign keys.
Parameters:
table (optional) — Table name to inspect. Omit to list all tables.
schema (default: "public") — Database schema.
> inspect_schema
## Tables in schema 'public'
| Table | Rows (est.) | Total Size |
|-------------|-------------|------------|
| users | 12,450 | 3.2 MB |
| orders | 89,100 | 18.4 MB |
| order_items | 245,000 | 12.1 MB |> inspect_schema table="users"
## Table: public.users
- **Rows (est.)**: 12,450
- **Total size**: 3.2 MB
### Columns
| # | Column | Type | Nullable | Default |
|---|--------|---------------|----------|---------|
| 1 | id | integer | NO | nextval |
| 2 | email | varchar(255) | NO | - |
| 3 | name | varchar(100) | YES | - |analyze_indexesFind unused indexes wasting disk space and missing indexes causing slow sequential scans. Also detects unindexed foreign keys.
Parameters:
schema (default: "public") — Database schema.
mode ("usage" | "missing" | "all", default: "all") — Analysis mode.
> analyze_indexes
### Unused Indexes (2 found)
| Table | Index | Size | Definition |
|-------|--------------------|--------|-------------------------------|
| users | idx_users_legacy | 1.2 MB | CREATE INDEX ... (old_col) |
### Unindexed Foreign Keys (1 found)
| Table | Column | FK → | Constraint |
|-------------|---------|--------|-------------------|
| order_items | user_id | users | fk_items_user_id |explain_queryRun EXPLAIN on a SQL query and get a formatted execution plan with cost estimates, node types, and optimization warnings. Optionally run EXPLAIN ANALYZE for actual timing (SELECT queries only).
Parameters:
sql — The SQL query to explain.
analyze (default: false) — Run EXPLAIN ANALYZE (executes the query; SELECT only).
> explain_query sql="SELECT * FROM orders WHERE status = 'pending'"
## Query Plan Analysis
- **Estimated Total Cost**: 1234.56
- **Estimated Rows**: 500
### Plan Tree
→ Seq Scan on orders (cost=0..1234.56 rows=500)
Filter: (status = 'pending')
### Potential Issues
- **Sequential Scan** on `orders` (~500 rows). Consider adding an index.analyze_table_bloatAnalyze table bloat by checking dead tuple ratios, vacuum history, and table sizes. Recommends VACUUM ANALYZE for tables with >10% dead tuples.
Parameters:
schema (default: "public") — Database schema.
> analyze_table_bloat
### Tables Needing VACUUM (1 found)
| Table | Live Tuples | Dead Tuples | Bloat % | Size | Last Vacuum |
|-----------|-------------|-------------|---------|-------|-------------|
| audit_log | 8,000 | 2,000 | 20.0% | 10 MB | Never |
### Recommended Actions
VACUUM ANALYZE public.audit_log;suggest_missing_indexesFind tables with high sequential scan counts and zero index usage, cross-referenced with unused indexes wasting space. Provides actionable CREATE INDEX and DROP INDEX recommendations.
Parameters:
schema (default: "public") — Database schema.
> suggest_missing_indexes
### Tables Missing Indexes (1 found)
| Table | Seq Scans | Index Scans | Rows | Size |
|--------|-----------|-------------|--------|-------|
| events | 5,000 | 0 | 50,000 | 25 MB |
### Unused Indexes (1 found)
| Table | Index | Size | Definition |
|-------|------------------|------|----------------------------------|
| users | idx_users_legacy | 8 kB | CREATE INDEX ... (legacy_col) |
DROP INDEX public.idx_users_legacy;analyze_slow_queriesFind the slowest queries using pg_stat_statements (PostgreSQL) or performance_schema (MySQL). Shows execution times, call counts, and identifies optimization candidates.
Parameters:
schema (default: "public") — Database schema.
limit (default: 10) — Number of slow queries to return.
> analyze_slow_queries
## Slow Query Analysis (by avg execution time)
| # | Avg Time | Total Time | Calls | Avg Rows | Query |
|---|----------|------------|-------|----------|-------|
| 1 | 150.0ms | 750000ms | 5000 | 5 | `SELECT * FROM orders WHERE status = $1` |
| 2 | 200.0ms | 40000ms | 200 | 2 | `SELECT u.* FROM users u JOIN orders o...` |
### Recommendations
- **2 high-impact queries** — called >100 times with >100ms avg
- **2 queries returning few rows but slow** — likely missing indexesanalyze_connectionsAnalyze active database connections. Detects idle-in-transaction sessions, long-running queries, lock contention, and connection pool utilization. PostgreSQL and MySQL only.
> analyze_connections
## Connection Analysis (PostgreSQL)
### Connection States
| State | Count |
|-------|-------|
| active | 3 |
| idle | 12 |
| idle in transaction | 2 |
| **Total** | **17** |
**Max connections**: 100
**Utilization**: 17.0%
### Idle-in-Transaction Connections
| PID | User | Duration | Query |
|------|------|----------|-------|
| 1234 | app | 00:05:30 | UPDATE orders SET status = $1 |analyze_table_relationshipsAnalyze foreign key relationships between tables. Builds a dependency graph showing entity connectivity, orphan tables (no FKs), cascading delete chains, and hub entities.
Parameters:
schema (default: "public") — Database schema.
> analyze_table_relationships
## Table Relationships
**Tables**: 5
**Foreign Keys**: 4
### Entity Connectivity
| Table | Incoming FKs | Outgoing FKs | Total |
|-------|-------------|-------------|-------|
| users **hub** | 5 | 0 | 5 |
| orders | 1 | 2 | 3 |
### Orphan Tables (no FK relationships)
- `audit_log`
### Cascading Delete Chains
- **users** → cascades to: orders, addresses
- **orders** → further cascades to: order_itemsanalyze_vacuumAnalyze PostgreSQL VACUUM maintenance status. Checks dead tuple ratios, vacuum staleness, autovacuum configuration, and identifies tables needing manual VACUUM. PostgreSQL only.
> analyze_vacuumDetects:
Tables with high dead tuple ratios (>10% warning, >20% critical)
Tables never vacuumed or analyzed
Autovacuum disabled globally
Autovacuum configuration issues
Output includes:
Findings grouped by severity (CRITICAL / WARNING / INFO)
Tables needing VACUUM with dead tuple percentages
Full vacuum history per table
Autovacuum configuration settings
All queries are wrapped in READ ONLY transactions by default
EXPLAIN ANALYZE is restricted to SELECT queries only
DDL/DML statements are rejected in ANALYZE mode
No data modification queries are allowed
Clone the repo
npm install
npm run build — TypeScript compilation
npm test — Run unit tests (vitest)
npm run dev — Watch mode for development
Read-only: All queries use read-only connections. Cannot modify data or schema.
pg_stat_statements required: Slow query analysis on PostgreSQL requires the pg_stat_statements extension to be installed and loaded.
MySQL performance_schema: Index usage and scan statistics require performance_schema to be enabled (off by default in some MySQL installations).
SQLite: No index usage statistics available (SQLite doesn't track this). Sequential scan analysis and slow query detection are not supported for SQLite.
Large databases: Schema inspection on databases with 500+ tables may produce very long output. Use the schema parameter to limit scope.
Table name parameterization: SQLite PRAGMA statements use string interpolation for table names (SQLite does not support parameterized PRAGMAs). Table names are sourced from sqlite_master system table.
Cross-database queries: Cannot analyze queries that span multiple databases or use database links.
Estimated row counts: MySQL TABLE_ROWS in information_schema is an estimate, not exact.
Schema scope: All tools default to public schema. Non-public schemas require explicit specification. Multi-schema analysis requires running tools per schema separately.
Connection analysis: analyze_connections is PostgreSQL/MySQL only. Not available for SQLite databases.
Vacuum analysis: analyze_vacuum is PostgreSQL only. For MySQL, use OPTIMIZE TABLE or analyze_table_bloat.
mcp-spring-boot-actuator — Spring Boot health, metrics, and bean analysis
mcp-jvm-diagnostics — Thread dump and GC log analysis
mcp-redis-diagnostics — Redis memory, slowlog, and client diagnostics
mcp-migration-advisor — Flyway/Liquibase migration risk analysis
MIT
End-of-life: 2026-05-10.
This MCP server is no longer maintained or distributed. The Corporation
has pivoted to Apify marketplace actors. See
irrationalways on Apify and
irrcorp/bzp-poland-tenders for current Corporation work.
The npm package has been unpublished. The repository is archived for historical reference only.
Analyze active database connections. Detects idle-in-transaction sessions and lock contention between sessions (PostgreSQL), long-running queries flagged at >30 seconds, and connection pool utilization. Idle-in-transaction and lock contention detection are not available on MySQL — use this tool's output to investigate PostgreSQL-specific blocking scenarios. Not available for SQLite.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool detects but does not state whether it is read-only or has any side effects. The description is adequate but could be improved by explicitly noting the tool is non-destructive.
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 with three sentences. The first sentence states the purpose, the second elaborates on specific detections and database differences, and the third provides a constraint. No redundant or unnecessary 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?
Given the complexity of analyzing database connections, the description covers key detection items and database-specific limitations. However, the absence of an output schema means the agent must infer the return format, which could be clarified.
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 (timeout_ms) has a schema description that is clear, but the tool description adds additional context: 'Increase for slow or remote databases.' This provides practical usage advice 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 analyzes active database connections and lists specific detections (idle-in-transaction, lock contention, long-running queries, connection pool utilization). It also differentiates between PostgreSQL, MySQL, and SQLite, effectively distinguishing it from sibling tools like analyze_slow_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 provides explicit guidance on when not to use (MySQL/SQLite for certain features) and suggests using for PostgreSQL-specific blocking scenarios. However, it does not explicitly compare with alternatives like analyze_slow_queries or explain_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze index usage statistics to find unused indexes wasting space and missing indexes causing slow sequential scans. Also detects unindexed foreign keys.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Database schema to analyze (default: public) | public |
| mode | No | Analysis mode: 'usage' for unused index detection, 'missing' for missing index suggestions, 'all' for both | all |
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It describes the output (unused indexes, missing indexes, unindexed foreign keys) but does not disclose behavioral traits such as whether the tool is read-only, resource-intensive, or requires specific permissions. The verb 'analyze' implies no modification, but this is 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 two sentences long and immediately states the core value proposition. Every sentence adds distinct information about what the tool finds (unused indexes, missing indexes, unindexed foreign keys). No redundant or unnecessary 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 the lack of annotations and output schema, the description provides a clear overview of the tool's outcomes (unused and missing indexes, unindexed foreign keys). It does not explain the return format or any side effects, but the information is sufficient for an agent to understand the tool's primary function.
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?
All three parameters (schema, mode, timeout_ms) have descriptions in the input schema (100% coverage), so the baseline is 3. The tool description does not add any additional meaning or usage tips beyond what the schema already provides.
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: analyzing index usage statistics to find unused indexes, missing indexes, and unindexed foreign keys. It uses specific verbs and resources, and the purpose is distinct from sibling tools like analyze_connections or analyze_slow_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?
No guidance is provided on when to use this tool versus alternatives (e.g., suggest_missing_indexes). The description does not mention when-not to use it or any prerequisites. Users must infer usage context solely from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the slowest queries using pg_stat_statements (PostgreSQL) or performance_schema (MySQL). Shows execution times, call counts, and optimization recommendations. PostgreSQL requires the pg_stat_statements extension to be installed and listed in shared_preload_libraries — the tool returns setup instructions if the extension is missing. Not available for SQLite.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Database schema (default: public) | public |
| limit | No | Number of slow queries to return (default: 10) | |
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses reliance on specific system views, graceful handling of missing extension (returns setup instructions), and output contents. With no annotations, description covers key behavioral aspects adequately.
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?
Three sentences, under 60 words, front-loaded with purpose. Every sentence adds value; no 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?
Covers purpose, database requirements, and high-level outputs. Lacks explicit mention of return format or pagination, but acceptable for a diagnostic tool with simple parameters.
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?
All three parameters are fully described in the input schema (100% coverage). Description adds no extra meaning beyond schema defaults and descriptions, so baseline 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?
Clearly states it finds slow queries using specific database extensions, shows execution times, counts, and recommendations. Distinct from sibling tools like analyze_indexes or explain_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?
Provides clear context: available for PostgreSQL and MySQL, not for SQLite; PostgreSQL requires pg_stat_statements extension. Does not explicitly mention alternatives but siblings are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze table bloat by checking dead tuple ratios (PostgreSQL) or InnoDB fragmentation (MySQL), vacuum history, and table sizes.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Database schema to analyze (default: public) | public |
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions what metrics are checked but does not state whether the tool is read-only, requires specific permissions, or has side effects. For a diagnostic tool, it omits important safety information.
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?
A single sentence that efficiently conveys the tool's purpose and scope. No redundancy, but could benefit from clearer separation of the separate metrics. Still, it is well front-loaded.
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 only two simple parameters and no output schema, the description explains what the tool checks but omits details about the return format, supported databases beyond mentioning Postgres and MySQL, and potential errors. Adequate but not fully 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 coverage is 100% (both parameters have descriptions). The description adds no additional meaning beyond the schema's parameter descriptions. Baseline score of 3 is appropriate as the schema already documents parameters 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 tool analyzes table bloat by checking specific metrics (dead tuple ratios, InnoDB fragmentation, vacuum history, table sizes). It includes database-specific details but does not explicitly differentiate from siblings like analyze_vacuum, which may have overlapping vacuum history checks.
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 alternatives. The description implies it targets PostgreSQL and MySQL, but does not state prerequisites or scenarios where it is preferred over sibling tools like analyze_vacuum or inspect_schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze foreign key relationships between tables. Builds a dependency graph showing entity connectivity, orphan tables (no FKs), cascading delete chains (shown at full depth), hub entities (tables with 5+ FK connections), and circular FK dependencies. Useful for understanding schema design, planning migrations, and impact analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Database schema to analyze (default: public) | public |
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles behavioral disclosure. It explains the output (dependency graph, specific analyses) and the timeout parameter hints at potential long-running behavior. No contradictions.
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 that are packed with information without superfluous words. The first sentence immediately states the core action, and the second lists specific outputs.
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 having no output schema, the description fully details what the analysis produces. For the given complexity (2 parameters, no nested objects), the description is complete and leaves no ambiguity about the tool's capabilities.
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 with descriptions, achieving 100% coverage. The description does not add additional meaning beyond the schema, so baseline score 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 it analyzes foreign key relationships and builds a dependency graph. It specifies exact outputs like orphan tables, cascading delete chains, hub entities, and circular FK dependencies, distinguishing it from siblings like analyze_connections or inspect_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?
The description indicates the tool is useful for understanding schema design, planning migrations, and impact analysis. While it doesn't explicitly contrast with siblings, the context signals provide sibling names and the description implies appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze PostgreSQL VACUUM maintenance status. Checks dead tuple ratios, vacuum staleness, autovacuum configuration, and identifies tables needing manual VACUUM. PostgreSQL only.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Database schema to analyze (default: public) | public |
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses what is checked but omits behavioral traits such as whether the tool modifies data (assumed read-only), required permissions, output format, or side effects. Identifying tables needing manual vacuum hints at output but lacks detail. This is minimal disclosure.
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 zero wasted words. The first sentence states the core action, the second adds detail on checks and constraints. Information is front-loaded and easily parsed.
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 diagnostic tool with 2 optional parameters and no output schema, the description provides the core purpose and checks but lacks details on output interpretation, prerequisites (e.g., database access), or how the results should guide action. It is adequate but not fully complete given the complexity of vacuum analysis.
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%; both parameters (schema, timeout_ms) have descriptions in the input schema. The description adds no further meaning beyond the schema, so 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 description clearly states the tool's purpose: analyzing PostgreSQL VACUUM maintenance status. It specifies the exact checks performed (dead tuple ratios, vacuum staleness, autovacuum configuration, tables needing manual VACUUM) and includes the constraint 'PostgreSQL only,' which clearly distinguishes it from siblings like analyze_connections or analyze_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?
The description implies usage for checking vacuum status but does not explicitly state when to use this tool versus alternatives. It lacks exclusions or comparison with sibling tools. The constraint 'PostgreSQL only' gives some guidance, but no direct 'when-not-to-use' or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run EXPLAIN on a SQL query and return a formatted plan with cost estimates, node types, and optimization warnings. Optionally runs EXPLAIN ANALYZE for actual execution statistics (read-only queries only).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | The SQL query to explain | |
| analyze | No | Run EXPLAIN ANALYZE to get actual execution times (executes the query). Only allowed for SELECT queries. | |
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It correctly notes that ANALYZE executes the query and is only allowed for SELECT queries. However, it does not disclose potential performance impact, resource consumption, or permissions needed, which are important for a SQL execution tool.
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 efficiently convey the core purpose and key optional behavior. No unnecessary words or repetition. Front-loaded with the primary action.
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 no output schema and 3 parameters, the description covers the main functionality but lacks details on the return format, timeout configuration (beyond default), and potential pitfalls. It 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?
Schema coverage is 100%, so the baseline is 3. The description adds context about output (formatted plan types), but does not enrich parameter meaning beyond what the schema already provides.
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 explains a SQL query with a formatted plan including cost estimates, node types, and optimization warnings. It distinctly sets the tool apart from siblings like analyze_slow_queries or suggest_missing_indexes by focusing on a single query execution plan.
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 clear context for use: running EXPLAIN on a SQL query, with an optional EXPLAIN ANALYZE for actual stats, restricted to read-only queries. It implicitly guides when to use the analyze flag, but does not explicitly contrast with sibling tools or mention 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 all tables in a schema with row counts and sizes, or inspect a specific table's columns, types, constraints, and foreign keys.
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Specific table name to inspect. Omit to list all tables. | |
| schema | No | Database schema to inspect (default: public) | public |
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states what information is returned but does not explicitly confirm it is read-only or mention potential performance impact on large schemas. While obviously non-destructive, the description lacks such explicit transparency.
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 efficiently conveys the two modes of operation. No extraneous words; it is front-loaded and easily scannable.
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 covers the main return elements (row counts, sizes, columns, types, constraints, foreign keys). Although no output schema exists, this is sufficient for an agent to understand what to expect. It does not detail ordering or formatting, but that is acceptable for this tool's complexity.
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?
All parameters have descriptions in the schema. The description adds value beyond the schema: it explains that omitting 'table' lists all tables, and for 'timeout_ms' it advises increasing for slow/remote databases. This provides helpful context.
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: listing all tables with row counts and sizes, or inspecting a specific table's columns, types, constraints, and foreign keys. This distinguishes it from sibling tools which focus on performance analysis (indexes, slow queries, bloat, etc.).
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 does not provide explicit guidance on when to use this tool vs. alternatives, nor does it state when not to use it. However, the purpose is clear enough that an agent can infer it should be used for schema exploration before more specific analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tables with high sequential scan counts and zero index usage, cross-referenced with unused indexes wasting space. Provides actionable CREATE INDEX and DROP INDEX recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Database schema to analyze (default: public) | public |
| timeout_ms | No | Connection timeout in milliseconds (default: 30000). Increase for slow or remote databases. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool provides recommendations but does not explicitly confirm it is read-only (no side effects), mention any performance impact, or indicate required permissions. This leaves some behavioral 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?
Two sentences efficiently convey purpose and output. Information is front-loaded with the key action ('Find tables...') followed by the output type. No unnecessary 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?
Given no output schema, the description reasonably indicates the tool returns actionable SQL recommendations. However, it does not detail the format (e.g., list of strings, structured objects). Slight improvement could specify output structure, but overall adequate for a simple 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% with both parameters described ('schema' default public, 'timeout_ms' default 30000 with hint). The tool description adds no additional parameter semantics beyond what the schema already provides, 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: identifying tables with high sequential scans and zero index usage, cross-referenced with unused indexes, and providing CREATE INDEX and DROP INDEX recommendations. This distinguishes it from sibling tools like analyze_indexes which likely focus on existing 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?
The description implies usage context (analyzing missing and unused indexes) but does not explicitly state when to use this tool versus alternatives like analyze_indexes or analyze_slow_queries. No exclusions or prerequisites are mentioned.
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.
v0.2.14analyze_connectionsanalyze_indexesanalyze_slow_queriesanalyze_table_bloatanalyze_table_relationshipsanalyze_vacuumexplain_queryinspect_schemasuggest_missing_indexesEach tool addresses a distinct database analysis concern (connections, indexes, slow queries, etc.). Overlaps like analyze_indexes and suggest_missing_indexes are clearly differentiated by their descriptions, ensuring an agent can select the correct tool without confusion.
All tools follow a consistent verb_noun pattern in snake_case (e.g., analyze_connections, explain_query). This predictable structure aids agent understanding and navigation.
With 9 tools, the server is well-scoped for its purpose of database analysis. Each tool serves a specific need without redundancy or bloat.
The tool set covers a comprehensive range of database analysis tasks: connections, indexes, slow queries, bloat, relationships, vacuum, explain, schema inspection, and index suggestions. There are no obvious gaps for a server focused on analysis and optimization.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
GibsonAI MCP server: manage your databases with natural language
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dmitriusan/mcp-db-analyzer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
