MCP Postgres Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific database metadata or operations, with no overlap. For example, list_tables enumerates tables, describe_table provides table structure, and query executes SQL, making them easily distinguishable.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case, such as list_tables, describe_table, and get_constraints. This uniformity makes the tool set predictable and easy to navigate.
Tool Count5/5
With 10 tools, the server is well-scoped for database introspection and querying, covering essential metadata operations without being overwhelming. Each tool serves a clear, necessary function in the domain.
Completeness4/5
The tool set provides comprehensive coverage for database metadata exploration and query execution, including listing, describing, and analyzing tables, schemas, and functions. A minor gap is the lack of tools for modifying database structures (e.g., creating or altering tables), but core read operations are complete.
Average 2.9/5 across 10 of 10 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 status not available
This repository is licensed under ISC 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

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 states 'Get constraints for a table', implying a read-only operation, but doesn't clarify aspects like whether it requires authentication, what happens if the table doesn't exist, or if there are rate limits. While it doesn't contradict annotations (since none exist), it fails to provide essential behavioral context for a tool with parameters and potential database interactions.
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, 'Get constraints for a table', which is front-loaded and wastes no words. Every part of the sentence contributes to the core purpose, making it efficient and easy to parse, though this brevity comes at the cost of detail.
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 (2 required parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain what 'constraints' entail, how results are returned, or error handling, leaving significant gaps for the agent. While conciseness is high, the lack of contextual details makes it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters ('schema' and 'table') with 0% description coverage, meaning the schema provides no semantic details. The description 'Get constraints for a table' implies that 'table' is the target but doesn't explain the role of 'schema' (e.g., database schema name) or any constraints on these parameters. It adds minimal meaning beyond the schema, insufficient to compensate for the low coverage, resulting in poor parameter understanding.
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 'Get constraints for a table' states a clear verb ('Get') and resource ('constraints for a table'), which provides a basic understanding of the tool's function. However, it lacks specificity about what types of constraints are retrieved (e.g., primary keys, foreign keys, unique constraints) and doesn't differentiate from sibling tools like 'describe_table' or 'list_indexes', which might overlap in functionality. This makes the purpose somewhat vague but not misleading.
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 any prerequisites, such as needing specific permissions or database context, nor does it compare to sibling tools like 'describe_table' (which might include constraint info) or 'list_indexes' (which could relate to constraints). This absence leaves the agent without clear usage context, though it's not misleading.
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 'Get' which implies a read operation, but doesn't specify if it's safe, requires permissions, has side effects, or details output format. For a tool with 5 parameters and 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 extremely concise with a single, front-loaded sentence that directly states the tool's purpose. There is no wasted text, making it efficient and easy to parse.
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 (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain parameter meanings, return values, or behavioral traits, leaving the agent with insufficient information for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters like 'sql', 'analyze', 'buffers', 'costs', or 'format', failing to compensate for the lack of schema documentation.
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 'Get' and the resource 'query execution plan (EXPLAIN)', making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'query' tool, which might also involve query execution, so it doesn't reach the highest 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 like the 'query' tool or other siblings. It lacks context on use cases, prerequisites, or exclusions, leaving the agent without direction 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. It states what the tool does but doesn't reveal important traits like whether it's read-only, requires specific permissions, has rate limits, or what the output format looks like. For a tool with zero annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded, directly stating the tool's 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 complexity of a tool that retrieves statistical data, the lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what 'statistics and size information' includes, how results are returned, or any behavioral constraints, making 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so parameters 'schema' and 'table' are undocumented in the schema. The description adds no information about what these parameters mean, their expected values, or how they affect the operation. It fails to compensate for the schema's lack of documentation.
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 ('Get') and resource ('table statistics and size information'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'describe_table' or 'list_tables', which might also provide table-related information.
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 'describe_table' or 'list_tables'. It lacks context about specific use cases, prerequisites, or exclusions, leaving the agent to infer usage based on 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 provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe behavioral traits such as whether it's read-only, what permissions are required, how results are formatted, or if there are rate limits. This is a significant gap for a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—every word contributes to understanding the tool's purpose. It's appropriately sized and front-loaded, 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 (2 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, parameter usage, output format, and differentiation from siblings. For a database tool that likely returns structured data, this is inadequate to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'table or schema' which hints at the two parameters, but doesn't explain their semantics, relationships, or usage (e.g., that 'schema' is required and 'table' is optional for listing all indexes in a schema). This adds minimal value beyond 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 verb ('List') and resource ('indexes') with scope ('for a table or schema'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'describe_table' or 'get_constraints' which might also provide index information, so it doesn't reach the highest 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 like 'describe_table' or 'get_constraints', nor does it mention prerequisites or context for usage. The phrase 'for a table or schema' gives minimal context but no explicit usage rules.
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 only states the basic action. It lacks details on permissions required, output format (e.g., list structure, pagination), error handling, or whether it's read-only (implied but not confirmed). 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.
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 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 tool's simplicity (1 parameter, no output schema, no annotations), the description is minimal but inadequate. It doesn't cover parameter meaning, behavioral traits, or usage context, leaving the agent with insufficient information to use the tool effectively beyond its basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't mention the 'schema' parameter at all. It fails to explain what 'schema' means in this context (e.g., database schema name) or provide any semantic details beyond what the bare schema implies, leaving the parameter undocumented.
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 ('tables in a schema'), making the purpose unambiguous. However, it doesn't differentiate from siblings like 'list_schemas' or 'list_views' beyond the resource type, which slightly limits its 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?
The description provides no guidance on when to use this tool versus alternatives like 'list_schemas' or 'describe_table', nor does it mention prerequisites such as needing a valid schema name. Usage context is implied but not explicit.
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 only states the basic action. It lacks details on permissions, rate limits, pagination, or what 'list' entails (e.g., format, filtering). This is inadequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse 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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address behavioral traits, parameter meanings, or return values, making it insufficient for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain the 'schema' parameter's purpose, format, or constraints beyond what the schema provides, leaving semantics unclear.
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 'List views in a schema' clearly states the verb ('List') and resource ('views'), specifying the scope ('in a schema'). It distinguishes from siblings like list_tables or list_functions by focusing on views, though it doesn't explicitly differentiate them in the text.
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 prerequisites, exclusions, or comparisons to sibling tools like list_tables or query, leaving usage context implied at best.
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 the action ('Get the structure') but does not specify whether this is a read-only operation, what permissions are required, the format of the output, or any rate limits. This leaves significant gaps for a tool that interacts with a database.
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, clear sentence with zero waste. It is appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary details.
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 does not address behavioral aspects like safety, permissions, or output format, which are crucial for a database tool. The simplicity of the input schema does not compensate for these omissions.
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 0%, but the description does not add any meaning beyond what the input schema provides. It does not explain what 'schema' and 'table' parameters represent or their constraints. However, with only 2 parameters and no output schema, the baseline is 3 as the schema itself is minimal and straightforward.
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 ('Get') and resource ('structure of a database table'), making the purpose specific and understandable. However, it does not explicitly distinguish this tool from sibling tools like 'list_tables' or 'get_table_stats', which might also provide structural information, so it lacks full 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 such as 'list_tables' or 'get_constraints'. There is no mention of prerequisites, context, or exclusions, leaving usage entirely implied from the purpose 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not describe traits such as whether this is a read-only operation, what permissions are needed, how results are formatted, or if there are limitations like pagination. This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose, 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 lack of annotations and output schema, the description is incomplete. It does not address behavioral traits, parameter semantics, or result format, which are crucial for a tool with no structured data support. This leaves the agent with insufficient information for 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?
The schema description coverage is 0%, and the description does not add any parameter details beyond the schema name. It implies a 'schema' parameter but does not explain its meaning, format, or constraints. With one parameter and low coverage, the description provides minimal compensation, resulting in an adequate baseline score.
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 ('functions and procedures in a schema'), making the purpose understandable. However, it does not differentiate this tool from sibling tools like 'list_tables' or 'list_views' beyond the resource type, 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 does not mention prerequisites, exclusions, or comparisons to sibling tools like 'list_schemas' or 'describe_table', leaving the agent without context for 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 but offers minimal behavioral insight. It implies a read-only operation by using 'List', but doesn't disclose permissions needed, pagination behavior, rate limits, or what 'all schemas' entails (e.g., scope or limitations). 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 front-loads the core purpose with zero wasted words. It's appropriately sized for a simple tool, 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 no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what a 'schema' entails in this context, how results are returned, or handle the parameter, leaving significant gaps for the agent to operate effectively.
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 has 1 parameter with 0% description coverage, so the description must compensate but doesn't mention the parameter at all. It adds no meaning beyond the schema, but since there's only one parameter and the baseline for low coverage is higher with fewer params, a score of 3 reflects minimal adequacy without added value.
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 action ('List all') and resource ('schemas in the database'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_tables' or 'list_views', which would require specifying what distinguishes schemas from those resources, 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or comparisons to siblings like 'list_tables' or 'list_functions', leaving the agent to infer usage 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.
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 reveals important behavioral traits like pagination support, parameterization for security, and the 500-row page size limit, but doesn't cover other critical aspects like authentication requirements, rate limits, transaction behavior, or error handling.
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 with two sentences that each earn their place: the first establishes core functionality, the second adds important constraints. It's front-loaded with the primary purpose and wastes no words.
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 complex SQL execution tool with 4 parameters, no annotations, and no output schema, the description is incomplete. While it covers the basic purpose and some constraints, it lacks information about return values, error conditions, transaction scope, and other behavioral details needed for safe usage.
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 75% (3 of 4 parameters have descriptions), so the baseline is 3. The description adds some value by mentioning 'pagination support' (relevant to offset and pageSize) and 'parameterization for security' (relevant to parameters), but doesn't provide additional semantic context beyond what's in the schema descriptions.
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 ('Execute SQL queries') and resources ('SQL queries'), distinguishing it from sibling tools that focus on metadata retrieval (like list_tables, describe_table) rather than query execution. It explicitly mentions key capabilities like pagination and parameterization.
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 provides clear context for when to use this tool (for executing SQL queries with pagination and security features), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools. It implies usage for query execution versus metadata operations.
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:

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

Score Badge

Copy to your README.md:

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

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/MadeByNando/mcp-postgres-server'

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