Postgres MCP Pro

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Most tools have distinct purposes, such as analyze_db_health for health checks and execute_sql for query execution, but analyze_query_indexes and analyze_workload_indexes could be confused as both focus on index recommendations, though their scopes differ (specific queries vs. workload analysis).
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as analyze_db_health, execute_sql, and list_objects, making them predictable and easy to understand.
Tool Count5/5
With 9 tools, the set is well-scoped for a Postgres database management server, covering key areas like health analysis, query optimization, schema exploration, and SQL execution without being overwhelming.
Completeness4/5
The tools provide strong coverage for monitoring, analysis, and query execution in Postgres, but there are minor gaps such as missing CRUD operations for database objects (e.g., create_table or drop_schema) that agents might need to work around.
Average 3/5 across 9 of 9 tools scored. Lowest: 2.4/5.
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 passing
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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this executes read-only queries, mutations, or both; what permissions are needed; whether it's safe for production; what happens on errors; or any rate limits. 'Execute any SQL query' is dangerously broad without safety context.
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, front-loaded sentence with zero wasted words. It directly states the tool's function without fluff or redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary SQL with no annotations, no output schema, and siblings offering analysis/explanation functions, this description is severely incomplete. It lacks critical context on safety, return values, error handling, and differentiation from other tools, making it inadequate for responsible agent 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% with one parameter 'sql' documented as 'SQL to run'. The description adds no additional meaning beyond this—it doesn't clarify syntax, supported SQL dialects, parameter binding, or query length limits. Baseline 3 is appropriate since the schema does the minimal 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 'Execute any SQL query' states the basic action (execute) and resource (SQL query), but it's vague about scope and doesn't distinguish from siblings like analyze_db_health or explain_query. It doesn't specify what database/context the SQL runs against or what types of queries are supported.
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 like analyze_query_indexes or explain_query. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to guess based on tool names alone.
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 only states the basic action without mentioning permissions needed, pagination behavior, rate limits, or what the output looks like (e.g., format, fields). This leaves significant gaps for a tool that likely returns a list of 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 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, making it easy to parse quickly.
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 listing database objects, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'objects' entail (e.g., tables, views), how results are formatted, or any behavioral aspects like error handling. This makes it inadequate for proper tool selection and invocation.
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 input schema fully documents both parameters (schema_name and object_type with its default and allowed values). The description adds no additional meaning beyond what's in the schema, such as examples or edge cases, meeting 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 'List objects in a schema' clearly states the action (list) and target (objects in a schema), but it's vague about what 'objects' specifically means and doesn't distinguish from siblings like 'list_schemas' or 'get_object_details'. It provides basic purpose but lacks specificity about scope or resource type.
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. The description doesn't mention sibling tools like 'list_schemas' (for listing schemas instead of objects within them) or 'get_object_details' (for detailed object information), nor does it specify prerequisites or appropriate contexts for use.
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 mentions analysis and recommendations but lacks details on behavioral traits such as whether this is a read-only operation, execution time, side effects (e.g., if it modifies the database), or output format. For a tool with no annotations, 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized and earns its place by clearly stating 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, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, output details, or usage context. For a tool with 2 parameters and potential side effects, more information is needed to be fully helpful.
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 both parameters ('max_index_size_mb' and 'method'). The description doesn't add any meaning beyond what the schema provides, such as explaining the impact of these parameters on the analysis. Baseline 3 is appropriate when the schema does the heavy lifting.
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.' It specifies the action (analyze queries, recommend indexes) and resource (database). However, it doesn't explicitly differentiate from sibling tools like 'analyze_query_indexes' or 'get_top_queries,' which may have overlapping functionality.
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 'analyze_query_indexes,' 'get_top_queries,' and 'analyze_db_health,' there's no indication of context, prerequisites, or exclusions. Usage is implied but not specified.
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 states it 'shows detailed information,' implying a read-only operation, but doesn't cover aspects like permissions needed, rate limits, error handling, or what 'detailed information' includes (e.g., metadata, statistics). This is inadequate for a tool with potential complexity.
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's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 'detailed information' entails (e.g., format, content), potential side effects, or dependencies, which is insufficient for a tool that interacts with database objects and has sibling tools offering related functionalities.
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 schema description coverage is 100%, with clear descriptions for all parameters (e.g., 'object_type' specifies allowed values). The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage notes, so it 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 with a specific verb ('show') and resource ('detailed information about a database object'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_objects' or 'explain_query', which might also provide object information in different contexts.
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 sibling tools like 'list_objects' (which might list objects without details) or 'explain_query' (which might analyze queries related to objects), leaving 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 full burden for behavioral disclosure. It describes what health checks are available but doesn't mention whether this is a read-only operation, if it requires specific permissions, what the output format looks like, whether it's resource-intensive, or if there are rate limits. For a health analysis tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The bulleted list efficiently presents health check options, and the final sentence adds important usage context about optional specification and default behavior. Every sentence earns its place, though the bulleted format could be slightly more concise.
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 no annotations and no output schema, the description is incomplete for a health analysis tool. It doesn't explain what the tool returns (e.g., health scores, warnings, detailed reports), how results are structured, whether it provides actionable recommendations, or what authentication/authorization is required. The parameter information is adequate, but overall context is insufficient.
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 the single parameter with its default value and valid options. The description adds marginal value by explaining the comma-separated list option and providing more detailed explanations of what each health check does (e.g., 'checks for invalid, duplicate, and bloated indexes' for 'index'), but doesn't fundamentally enhance understanding beyond what the schema provides.
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 analyzing database health and lists specific health check categories (index, connection, vacuum, etc.). It distinguishes from siblings like analyze_query_indexes by focusing on overall database health rather than query-specific analysis. However, it doesn't explicitly contrast with all siblings like execute_sql or list_schemas.
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 for database health monitoring but doesn't explicitly state when to use this tool versus alternatives like analyze_query_indexes or get_top_queries. It mentions the default behavior ('all' checks) but provides no guidance on prerequisites, timing, or exclusion criteria relative to sibling tools.
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 the data source ('pg_stat_statements') but doesn't cover critical aspects like whether this is a read-only operation, potential performance impact, authentication needs, rate limits, or output format. For a tool reporting on database queries without annotations, this leaves significant gaps in understanding 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's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes essential information, earning 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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and data source but lacks details on behavioral traits, usage context, and output. Without annotations or an output schema, the agent has incomplete information to use the tool effectively, though the purpose is clear.
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 input schema fully documents both parameters ('sort_by' and 'limit') with descriptions and defaults. The description adds no additional parameter semantics beyond what's in the schema, such as clarifying the 'resources' option or interaction effects. This meets the baseline of 3 when the schema handles parameter documentation effectively.
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: 'Reports the slowest or most resource-intensive queries using data from the 'pg_stat_statements' extension.' It specifies the verb ('reports') and resource ('queries'), and mentions the data source. However, it doesn't explicitly differentiate from sibling tools like 'analyze_db_health' or 'explain_query', which might also involve query analysis, so it falls short of a perfect 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. It doesn't mention sibling tools like 'analyze_query_indexes' or 'explain_query', nor does it specify prerequisites or contexts for usage. The agent must infer usage from the purpose alone, which is insufficient for clear decision-making.
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 for behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention permissions needed, rate limits, pagination, or what 'all schemas' entails (e.g., system vs. user schemas). This leaves significant gaps for a tool that likely returns critical database metadata.
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 action and resource, making it easy to parse. Every word earns its place.
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 schema listing (which often involves permissions, scoping, and structured output), the description is inadequate. With no annotations, no output schema, and minimal behavioral context, it doesn't provide enough information for reliable tool invocation. It should at least hint at the return format or constraints.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is justified since the schema fully describes 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 verb ('List') and resource ('all schemas in the database'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_objects' or 'get_object_details', but the scope is specific enough to understand what it returns.
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 like 'list_objects' or 'get_object_details'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
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, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only analysis, if it requires database permissions, execution time, or output format. The 10-query limit is mentioned, but other constraints like rate limits or side effects are not addressed.
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, front-loaded sentence with zero waste. It efficiently conveys the core purpose and key constraint (up to 10 queries) without unnecessary elaboration, making it highly scannable and actionable.
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 tool with 3 parameters, 100% schema coverage, and no output schema, the description is minimally complete. It states the purpose clearly but lacks behavioral context (e.g., analysis method implications, output details). Given the complexity of index recommendation, more guidance on usage and results would improve completeness.
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 parameters. The description adds no additional meaning beyond implying 'up to 10' queries, which is already covered by the schema's array type. Baseline 3 is appropriate as the schema handles parameter semantics adequately.
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 ('analyze'), the resource ('SQL queries'), and the outcome ('recommend optimal indexes'). It distinguishes from siblings like 'analyze_db_health' (general health) and 'explain_query' (execution plan) by focusing on index recommendations for multiple queries.
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 'list of (up to 10) SQL queries,' suggesting it's for batch analysis, but doesn't explicitly state when to use this vs. alternatives like 'analyze_workload_indexes' or 'explain_query.' No guidance on prerequisites or exclusions is provided.
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 of behavioral disclosure. It mentions that the tool 'shows how the database will execute' and provides 'detailed cost estimates', which gives some behavioral context. However, it doesn't disclose important traits like whether this is a read-only operation, potential performance impact (especially with analyze=true), rate limits, or authentication requirements. The description adds basic context but misses key behavioral 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 perfectly concise at two sentences with zero wasted words. The first sentence states the core purpose, and the second sentence adds important behavioral context about what the explanation includes. Every sentence earns its place by providing distinct value, and the information is front-loaded with the most important purpose statement first.
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 tool with 3 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It clearly states what the tool does but doesn't address important contextual aspects like what format the explanation returns, whether it's safe to run on production databases, or how it differs from similar tools. The description is complete enough for basic understanding but leaves gaps for practical implementation.
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 all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions 'execution plan' and 'cost estimates' which relate to the output rather than input parameters. The baseline score of 3 is appropriate when the 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 tool's purpose with specific verbs ('explains', 'showing', 'provides') and resources ('execution plan for a SQL query', 'detailed cost estimates'). It distinguishes itself from siblings like execute_sql (which runs queries) and analyze_query_indexes (which focuses on indexes) by emphasizing explanation and planning rather than execution or optimization analysis.
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 (understanding query performance before execution) but doesn't explicitly state when to use this tool versus alternatives. For example, it doesn't clarify when to choose explain_query over analyze_query_indexes for index analysis or when to use it alongside execute_sql. The guidance is present but not explicit about alternatives or exclusions.
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:

[![bach--postgres-mcp MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bach--postgres-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bach--postgres-mcp)

Score Badge

Copy to your README.md:

[![bach--postgres-mcp MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bach--postgres-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bach--postgres-mcp)

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/BACH-AI-Tools/bach--postgres-mcp'

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