Postgres MCP Pro Plus

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between analyze_query_indexes and analyze_workload_indexes, both focusing on index recommendations, which could cause confusion. However, their descriptions clarify that one analyzes specific queries while the other analyzes frequently executed queries, helping to differentiate them.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., analyze_db_health, execute_sql, list_schemas) with minor deviations like get_blocking_queries and get_database_overview using 'get' instead of 'list' or 'analyze'. Overall, the pattern is predictable and readable.
Tool Count5/5
With 13 tools, the count is well-scoped for a Postgres database management server, covering analysis, execution, and listing functions. Each tool appears to serve a specific purpose without feeling excessive or insufficient for the domain.
Completeness5/5
The tool set provides comprehensive coverage for Postgres database management, including health analysis, query optimization, schema exploration, and SQL execution. There are no obvious gaps; it supports CRUD-like operations and lifecycle management through tools like execute_sql and various analysis functions.
Average 3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Execute any SQL query', which fails to disclose critical traits such as whether this is a read-only or write operation, potential side effects (e.g., data modification), authentication needs, rate limits, or error handling. This is inadequate for a tool that could perform destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Execute any SQL query'), which is front-loaded and wastes no words. It efficiently conveys the core action, though this brevity contributes to gaps in other dimensions. Every word earns its place, making it structurally optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of SQL execution (potential for data mutation, security implications) and the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral risks, return values, or usage context, leaving significant gaps for an agent to safely invoke this tool. More detail is needed to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'sql' parameter documented as 'SQL to run'. The description adds no additional meaning beyond this, such as syntax examples, supported SQL dialects, or constraints. Since the schema provides full coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Execute any SQL query'), which is clear but vague. It specifies the verb ('Execute') and resource ('SQL query'), but doesn't differentiate from siblings like 'explain_query' or 'get_top_queries', which also involve SQL operations. The purpose is understandable but lacks specificity about scope or type of execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'explain_query' (for analysis) and 'get_top_queries' (for monitoring), the description doesn't indicate that this tool is for direct execution, nor does it mention prerequisites, exclusions, or typical use cases. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'show detailed information' implies a read-only operation, it doesn't specify what kind of information is returned, whether there are permission requirements, rate limits, or any other behavioral characteristics. The description is too minimal for a tool that presumably returns structured data about database objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. While this conciseness comes at the cost of completeness, as a standalone statement it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' includes, what format it returns, or how this differs from related tools. The agent would have significant gaps in understanding what this tool actually does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema - it doesn't explain relationships between parameters, provide examples of valid combinations, or clarify edge cases. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show detailed information about a database object' clearly states the verb ('show') and resource ('database object'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'list_objects' or 'get_database_overview' - it's vague about what 'detailed information' means compared to what those other tools provide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that also retrieve database information (list_objects, get_database_overview, analyze_* tools), there's no indication of when this specific 'detailed information' tool is appropriate versus when to use other tools for different types of database insights.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning permissions, pagination, rate limits, or response format. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'List objects in a schema,' which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is incomplete. It doesn't explain what 'objects' entail, how results are returned, or any behavioral traits, making it inadequate for a tool with two parameters and no structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (schema_name and object_type). The description adds no additional meaning beyond what's in the schema, such as examples or constraints, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List objects in a schema' states the basic action and resource (list objects in a schema), but it's vague about what 'objects' specifically means and doesn't differentiate from sibling tools like list_schemas or get_object_details. It provides a minimal viable purpose without specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 list_schemas or get_object_details. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent with no explicit or implied usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'analysis' implies a read-only operation, the description doesn't explicitly state whether this is a safe read operation or if it has any side effects. It mentions 'maintenance recommendations' but doesn't clarify if these are just suggestions or if any actions are taken. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality. It's appropriately sized for a tool with no parameters. While it could potentially be more specific about what 'comprehensive' entails, the description doesn't waste words and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of database analysis tools and the lack of both annotations and output schema, the description is insufficient. It doesn't explain what format the analysis results will take, what 'bloat detection' specifically means, or what kind of maintenance recommendations are provided. For a tool that presumably returns detailed analysis results, the description should provide more context about the output format and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so there's no parameter documentation burden. The description appropriately doesn't discuss parameters since none exist. The baseline for 0 parameters is 4, as there's no need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'comprehensive vacuum analysis' with 'maintenance recommendations and bloat detection', which gives a general sense of purpose. However, it doesn't clearly distinguish this from sibling tools like 'analyze_db_health' or 'analyze_query_indexes' - all seem to be analysis tools for database optimization. The description lacks a specific verb+resource combination that would differentiate it from similar analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple analysis tools available (analyze_db_health, analyze_query_indexes, analyze_schema_relationships, analyze_workload_indexes), there's no indication of when vacuum analysis is appropriate versus other types of database analysis. No prerequisites, exclusions, or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the limit of 'up to 10' queries, which is useful, but fails to describe other key behaviors: it doesn't specify what the recommendations include (e.g., index types, columns), whether analysis is read-only or has side effects, performance implications, or output format. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does and includes a key constraint ('up to 10'), making it easy to parse. Every part of the sentence earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing queries for index optimization) and lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the recommendations entail, how they're presented, or any behavioral nuances like error handling or performance limits. For a tool with no structured output and no annotations, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying the 'queries' parameter handles up to 10 items. It doesn't explain why 'max_index_size_mb' or 'method' matter, or how they affect recommendations. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze a list of (up to 10) SQL queries and recommend optimal indexes.' It specifies the verb ('analyze'), resource ('SQL queries'), and outcome ('recommend optimal indexes'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'analyze_workload_indexes' or 'explain_query', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'analyze_workload_indexes' for broader analysis or 'explain_query' for single-query optimization, nor does it specify prerequisites or exclusions. This lack of context leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analysis and recommendation but does not cover critical aspects like whether this is a read-only operation, if it requires specific permissions, potential performance impact, or output format. For a tool that likely involves database analysis, this omission is significant and limits the agent's understanding of its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and avoids redundancy, making it easy for an agent to parse quickly. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of database analysis tools and the lack of annotations and output schema, the description is insufficient. It does not explain what the recommendations look like, how they are generated, or any behavioral traits like safety or side effects. With siblings that may overlap, more context is needed to ensure the agent can use this tool effectively in the broader toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting both parameters ('max_index_size_mb' and 'method') with details like defaults and enums. The description does not add any semantic information beyond the schema, such as explaining when to choose 'dta' vs 'llm' methods or the implications of index size limits. Thus, it meets the baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze frequently executed queries in the database and recommend optimal indexes.' This specifies the verb ('analyze'), resource ('frequently executed queries'), and outcome ('recommend optimal indexes'). However, it does not explicitly differentiate from sibling tools like 'analyze_query_indexes' or 'get_top_queries', which may have overlapping functionality, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings such as 'analyze_query_indexes', 'get_top_queries', and 'explain_query', there is no indication of context, prerequisites, or exclusions. This lack of differentiation leaves the agent to infer usage, which is inadequate for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't address critical behavioral aspects like whether this is a heavy operation (given performance analysis), whether it requires specific permissions, potential impact on database performance, or what the output format looks like. The mention of 'comprehensive' analysis hints at scope but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly communicates the core purpose. Every word earns its place - 'comprehensive' sets scope, 'database overview' specifies the resource, and 'performance and security analysis' clarifies the analysis dimensions. There's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs 'comprehensive database overview' with performance and security analysis, the description is insufficient. There's no output schema, and with no annotations, the description doesn't address what information is returned, how extensive the analysis is, whether this is a resource-intensive operation, or how it differs from similar analysis tools. The agent lacks critical context for proper tool invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear documentation for all three parameters (max_tables, sampling_mode, timeout). The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it doesn't explain how these parameters affect the 'comprehensive overview' or their practical implications. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comprehensive database overview with performance and security analysis'. It specifies the verb ('Get') and resource ('database overview') with additional scope ('performance and security analysis'). However, it doesn't explicitly differentiate from sibling tools like 'analyze_db_health' or 'get_object_details', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools focused on database analysis (e.g., analyze_db_health, analyze_query_indexes), there's no indication of what makes this tool distinct or when it should be preferred over others. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'visual representation', hinting at output format, but doesn't specify what that entails (e.g., graph, diagram, text), whether it's read-only or has side effects, or any performance or permission requirements. This leaves significant gaps for a tool with potential complexity in analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function. It's front-loaded with the core purpose and avoids unnecessary words, though it could be slightly more structured by elaborating on the 'visual representation' aspect to enhance clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description is minimally complete but lacks depth. It hints at output ('visual representation') but doesn't detail what that means, and with no annotations, it fails to cover behavioral aspects like safety or performance. For an analysis tool, this leaves the agent with insufficient context to fully understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, with 100% schema description coverage, so there's no need to compensate for undocumented inputs. The description doesn't add parameter details beyond the schema, but with no parameters, a baseline of 4 is appropriate as it avoids confusion and aligns with the empty input structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Analyze schema relationships and dependencies with visual representation', specifying the verb 'analyze' and the resource 'schema relationships and dependencies'. It distinguishes from siblings like 'list_schemas' or 'get_object_details' by focusing on analysis rather than listing or retrieval, though it doesn't explicitly differentiate from other analysis tools like 'analyze_db_health'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and with siblings like 'list_schemas' and 'analyze_db_health', there's no indication of when this specific analysis tool is preferred over others for understanding schema structures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions 'comprehensive blocking queries analysis,' it doesn't describe what this entails operationally—such as whether it requires specific database permissions, if it's read-only or has side effects, how it handles large datasets, or what the output format looks like. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get comprehensive blocking queries analysis with lock information, hierarchy, and recommendations.' It's front-loaded with the core purpose and includes key details without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'comprehensive analysis' and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'blocking queries analysis' means in practice, what the recommendations entail, or how the results should be interpreted. For a tool that likely returns detailed database diagnostics, this leaves too much ambiguity for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for this scenario is 4, as the description appropriately doesn't waste space on non-existent parameters, though it doesn't add value beyond the schema (which already fully covers the lack of parameters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comprehensive blocking queries analysis with lock information, hierarchy, and recommendations.' It specifies the verb ('Get') and resource ('blocking queries analysis') with additional details about what the analysis includes. However, it doesn't explicitly differentiate from sibling tools like 'analyze_db_health' or 'get_top_queries,' which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'analyze_db_health,' 'get_top_queries,' and 'execute_sql,' there's no indication of when this specific blocking queries analysis is appropriate, what prerequisites might exist, or when other tools should be used instead. This lack of contextual guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'List all schemas' implies a read-only operation, it doesn't specify whether this requires specific permissions, what format the output takes, whether there are pagination limits, or if there are any side effects. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a simple tool with no parameters and gets straight to the point. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description provides the minimum viable information about what the tool does. However, without annotations or output schema, it doesn't address important behavioral aspects like output format, permissions, or limitations. Given the simplicity of the tool, the description is adequate but leaves room for improvement in behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description appropriately doesn't discuss parameters since none exist. It correctly focuses on what the tool does rather than trying to explain non-existent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all schemas in the database'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_objects' or 'get_object_details', but the specificity of 'schemas' provides some implicit distinction. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_objects' and 'get_object_details' that might overlap in functionality, there's no indication of when this specific tool is appropriate or what makes it different. The description is purely functional without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what health checks are available and how to specify them, but it doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, potential performance impact, rate limits, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose, followed by a bulleted list of checks and usage notes. Every sentence earns its place by adding necessary information, though it could be slightly more streamlined by integrating the bullet points into prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that performs health analysis. It covers the parameter well but lacks details on behavioral aspects (e.g., safety, permissions) and output format, which are crucial for an AI agent to use it correctly. The complexity of health checks warrants more context than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by providing a detailed list of health check categories (e.g., 'index - checks for invalid, duplicate, and bloated indexes'), which gives semantic meaning beyond the schema's enum-like list. It also clarifies that multiple checks can be specified as a comma-separated list, which isn't explicitly stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Analyzes database health' and lists specific health check categories (index, connection, vacuum, etc.), providing a specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like 'analyze_query_indexes' or 'analyze_vacuum_requirements', which appear to be more specialized versions of these checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing available health checks and stating the default is 'all' checks, but it doesn't explicitly say when to use this tool versus alternatives like the sibling tools. No exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions the data source but doesn't describe output format, whether results are real-time or historical, potential performance impact of running this tool, or authentication requirements. For a read operation with zero annotation coverage, this leaves significant gaps in understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes essential contextual detail about the data source. Every element earns its place, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the output looks like (e.g., query text, metrics, timestamps), whether results are aggregated or raw, or how the tool handles different database states. Given the complexity of query performance analysis and lack of structured output documentation, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain the practical difference between 'resources' versus time-based sorting, or how 'limit' interacts with different sort criteria. Baseline 3 is appropriate when schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Reports') and target resource ('slowest or most resource-intensive queries'), with precise source attribution ('using data from the pg_stat_statements extension'). It effectively distinguishes this tool from siblings like get_blocking_queries or analyze_query_indexes by focusing on performance ranking rather than blocking analysis or index optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'slowest or most resource-intensive queries' and the pg_stat_statements data source, suggesting it's for performance monitoring. However, it doesn't explicitly state when to use this versus alternatives like analyze_db_health for broader health checks or get_blocking_queries for concurrency issues, nor does it mention prerequisites like needing the extension enabled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool provides execution plans and cost estimates, and hints at performance implications ('Takes longer but provides more accurate information' for the analyze parameter). However, it doesn't cover other behavioral traits like permissions needed, rate limits, or what the output format looks like (no output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and efficiently adds key details. Every phrase earns its place by clarifying scope and output without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose and hints at behavior but doesn't fully address usage scenarios, output format, or integration with sibling tools. Without annotations or output schema, more context on what the explanation includes would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'detailed cost estimates' which relates to the sql parameter's purpose. With high schema coverage, the baseline is 3, but the description slightly enhances understanding of the tool's output context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('explains the execution plan'), identifies the resource ('SQL query'), and distinguishes it from siblings like execute_sql (which runs queries) and analyze_query_indexes (which focuses on indexes). The phrase 'showing how the database will execute it and provides detailed cost estimates' adds precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context for query optimization and performance analysis, which differentiates it from execute_sql (for running queries) and get_top_queries (for monitoring). However, it lacks explicit guidance on when to choose this tool over alternatives like analyze_query_indexes or when not to use it (e.g., for simple queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![postgres-mcp-pro-plus MCP server](https://glama.ai/mcp/servers/cloudthinker-ai/postgres-mcp-pro-plus/badges/card.svg)](https://glama.ai/mcp/servers/cloudthinker-ai/postgres-mcp-pro-plus)

Score Badge

Copy to your README.md:

[![postgres-mcp-pro-plus MCP server](https://glama.ai/mcp/servers/cloudthinker-ai/postgres-mcp-pro-plus/badges/score.svg)](https://glama.ai/mcp/servers/cloudthinker-ai/postgres-mcp-pro-plus)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cloudthinker-ai/postgres-mcp-pro-plus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server