PostgreSQL MCP Server

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 'execute-query' and 'query-table' that could cause confusion. 'execute-query' handles general SQL operations, while 'query-table' is specifically for querying tables with filtering, but both can be used for SELECT queries, potentially leading to misselection. Other tools like 'insert-data', 'update-data', and 'delete-data' are clearly differentiated by their CRUD operations.
Naming Consistency5/5
Tool names follow a consistent verb-noun pattern with hyphens throughout, such as 'execute-query', 'get-schema', and 'update-data'. All tools adhere to this naming convention, making them predictable and easy to understand. There are no deviations or mixed styles like camelCase or snake_case, ensuring high readability.
Tool Count5/5
With 8 tools, the count is well-scoped for a PostgreSQL server, covering essential database operations like connection management, CRUD, schema inspection, and query execution. Each tool serves a clear purpose without redundancy, and the number is neither too thin nor overwhelming, fitting typical server needs in the 3-15 tool range.
Completeness4/5
The tool set provides comprehensive coverage for core PostgreSQL operations, including connection status, schema retrieval, CRUD operations, and query execution. Minor gaps exist, such as the lack of tools for managing database objects (e.g., creating/dropping tables or indexes) or handling transactions, but agents can work around these using 'execute-query' for most missing functions.
Average 3.2/5 across 8 of 8 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 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

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 filtering capabilities (WHERE conditions with exact matches, arrays, and LIKE patterns) but omits critical behavioral details: whether this is a read-only operation, potential rate limits, error handling, or what the return format looks like (especially without an output schema). For a query tool with 5 parameters and no annotations, 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, well-structured sentence that efficiently lists key features without redundancy. It's front-loaded with the core purpose and follows with supporting details. Every word earns its place, making it highly 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 the complexity (5 parameters with nested objects, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., read-only nature, error responses), full parameter semantics, and output format. For a query tool that likely returns data, the absence of output schema or description of return values is a significant gap.
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 schema provides no parameter documentation. The description adds some value by mentioning filtering, pagination, and sorting, which map to 'where', 'pagination', and 'sort' parameters, and specifies support for exact matches, arrays (IN), and LIKE patterns for 'where'. However, it doesn't explain 'table' or 'columns' parameters, leaving 2 of 5 parameters undocumented, failing to compensate for the low 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: 'Query data from a specific table with filtering, pagination, and sorting.' It specifies the verb ('query'), resource ('data from a specific table'), and key capabilities. However, it doesn't explicitly differentiate from sibling tools like 'execute-query' or 'get-table-info', 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 siblings like 'execute-query' (likely for raw SQL) and 'get-table-info' (likely for metadata), the agent has no indication of the appropriate context for this structured query tool. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 safety checks and parameter binding to prevent SQL injection, which are useful behavioral traits. However, it lacks details on permissions, rate limits, error handling, or what 'safety checks' entail, leaving gaps for a mutation-capable tool.
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 concise with two sentences that are front-loaded and avoid redundancy. Each sentence adds value: the first states the core functionality, and the second expands on supported operations and safety features.
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 (supports mutations, 3 parameters with 0% schema coverage, no output schema, and no annotations), the description is incomplete. It lacks details on return values, error conditions, transactional behavior, and when to use versus siblings, making it inadequate for safe agent operation.
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 minimal parameter semantics. It mentions 'parameterized SQL query' and 'parameter binding' hinting at 'query' and 'params', but doesn't explain 'explain' or provide syntax/format details. With 3 parameters undocumented, this is insufficient.
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: 'Execute a parameterized SQL query with safety checks' specifies the verb (execute) and resource (SQL query), and mentions support for SELECT, INSERT, UPDATE, DELETE operations. It distinguishes from siblings like 'query-table' by being more general, though not explicitly contrasting them.
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 'query-table', 'insert-data', 'update-data', or 'delete-data'. It mentions support for various SQL operations but doesn't specify contexts, prerequisites, or exclusions for choosing among siblings.
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 conflict resolution options and returning data, which adds some context beyond basic insertion. However, it lacks critical details such as required permissions, potential side effects (e.g., data integrity impacts), error handling beyond conflicts, or performance considerations like rate limits, making it insufficient for a mutation tool.
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 ('Insert new records into a table') and efficiently lists key features without redundancy. Every phrase adds value, such as clarifying record types and conflict handling, making it appropriately sized 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 tool's complexity (5 parameters, mutation operation, no annotations, and no output schema), the description is incomplete. It covers basic functionality but lacks details on error cases, output format, dependencies (e.g., table existence), and comparisons with siblings like 'update-data'. For a data insertion tool with significant behavioral implications, this leaves the agent under-informed.
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 0%, so the description must compensate for undocumented parameters. It mentions 'single or multiple records' (hinting at the 'data' parameter), 'conflict resolution (ignore/update)' (hinting at 'on_conflict'), and 'returning inserted data' (hinting at 'returning'), covering 3 of 5 parameters. However, it omits 'table' and 'conflict_columns', and doesn't provide detailed semantics like format or constraints, leaving gaps in 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 action ('Insert new records') and target resource ('into a table'), which is specific and unambiguous. It distinguishes from siblings like 'delete-data' and 'update-data' by focusing on insertion rather than modification or removal. However, it doesn't explicitly differentiate from 'execute-query' which might also insert data, leaving slight room for improvement.
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 mentions 'Supports single or multiple records, conflict resolution (ignore/update), and returning inserted data,' which implies usage scenarios but doesn't provide explicit guidance on when to use this tool versus alternatives like 'update-data' or 'execute-query'. No context about prerequisites, exclusions, or sibling tool comparisons is included, leaving the agent with minimal direction.
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 describes what information is retrieved but lacks details on behavioral traits such as whether this is a read-only operation (implied by 'Get' but not stated), potential performance impacts, error conditions, or the format of the returned data. The description is minimal and doesn't compensate for the absence of annotations.
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 concise and well-structured with two sentences: the first states the purpose and key parameters, and the second provides usage context. Every sentence adds value without redundancy, 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 (4 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter meanings, behavioral aspects like safety or output format, or how it relates to sibling tools. For a tool that retrieves database schema—a potentially complex operation—this leaves significant gaps for an AI agent to understand and use it correctly.
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%, meaning none of the 4 parameters are documented in the schema. The description mentions 'optionally constraints' which hints at the 'include_constraints' parameter, but it doesn't explain the other parameters (schema_name, table_pattern, include_columns) or their purposes. This adds minimal value beyond the schema, failing to compensate for the low 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 database schema information including tables, columns, data types, and optionally constraints.' It specifies the verb ('Get') and resource ('database schema information') with concrete examples of what information is retrieved. However, it doesn't explicitly differentiate from sibling tools like 'get-table-info' or 'query-table', which might also provide schema-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Useful for understanding database structure.' This implies when to use it (for structural understanding) but doesn't explicitly state when not to use it or mention alternatives among the sibling tools. For example, it doesn't clarify how this differs from 'get-table-info' or when to prefer one over the other.
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 describes what information is returned but doesn't mention critical behavioral aspects like whether this is a read-only operation, potential performance impact, authentication requirements, error conditions, or response format. For a metadata retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 front-loads the core purpose and lists key information elements. Every phrase contributes meaning without redundancy. However, it could be slightly more structured by separating the core function from optional features for better clarity.
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 table metadata tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It covers the basic purpose and hints at one parameter but lacks details on behavior, return values, error handling, and complete parameter documentation. This leaves the agent with significant uncertainty about tool 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?
With 0% schema description coverage, the schema provides no parameter documentation. The description mentions 'optionally statistics like row count and size' which hints at the 'include_statistics' parameter's purpose, but doesn't explain the 'table' or 'schema_name' parameters. It adds some value for one parameter but doesn't fully compensate for the coverage gap, leaving two parameters 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 ('Get') and resource ('detailed information about a specific table'), specifying what information is included (columns, constraints, indexes, statistics). It distinguishes from siblings like 'get-schema' by focusing on a single table's details rather than overall schema. However, it doesn't explicitly differentiate from 'query-table' which might also provide table information.
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 obtaining comprehensive table metadata, including optional statistics. It suggests when to use it (for detailed table analysis) but doesn't explicitly state when NOT to use it or provide clear alternatives among siblings like 'get-schema' for broader schema overview or 'query-table' for data retrieval. No prerequisites or exclusions 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 full burden but offers limited behavioral insight. It mentions safety requirements (WHERE conditions) and return behavior (returns updated records), but doesn't cover critical aspects like permissions needed, whether updates are reversible, rate limits, error handling, or transaction implications. For a mutation tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that get straight to the point: first states core functionality and safety requirement, second adds capabilities and return behavior. There's no wasted text, though it could be slightly more front-loaded by mentioning the return behavior earlier.
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 this is a mutation tool with 4 parameters (including complex nested objects), 0% schema coverage, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'data' should contain, how 'where' clauses are structured, what 'returning' controls, or provide examples. The agent would struggle to use this tool correctly without significant additional context.
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 0% schema description coverage, the description must compensate but only partially does so. It mentions 'WHERE conditions' (mapping to 'where' parameter) and 'returns updated records' (hinting at 'returning'), but doesn't explain 'table' or 'data' parameters at all. The description adds some meaning but doesn't fully address the four parameters, especially given the complex nested object structure indicated in context signals.
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 ('Update existing records') and resource ('in a table'), making the purpose immediately understandable. It distinguishes from siblings like 'insert-data' (creates new) and 'delete-data' (removes), but doesn't explicitly contrast with 'query-table' or 'execute-query' which might also modify data.
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 provides some guidance by stating 'Requires WHERE conditions for safety' and mentioning support for 'complex WHERE clauses', which implies when to use it (for updates with conditions). However, it doesn't explicitly say when NOT to use it or name alternatives like 'insert-data' for new records or 'execute-query' for other operations, leaving usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a destructive operation (implied by 'Delete'), requires safety measures ('WHERE conditions for safety'), and includes interactive elements ('confirmation prompt for large deletions'). It doesn't cover aspects like permissions or rate limits, but provides solid foundational 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 highly concise and front-loaded, with two sentences that directly convey purpose and key behaviors without any wasted words. Each sentence earns its place by providing essential information, making it efficient and well-structured.
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 complexity (destructive operation with 4 parameters, no output schema, and no annotations), the description is minimally adequate. It covers the core action and safety notes but lacks details on parameter usage, return values, or error handling. It meets basic needs but has clear gaps for a tool of this nature.
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 0%, so the description must compensate, but it only partially does so. It mentions 'WHERE conditions' (mapping to the 'where' parameter) and hints at 'confirmation prompt' (related to 'confirm_delete'), but doesn't explain 'table', 'returning', or the structure of 'where'. This adds some meaning but leaves significant gaps, aligning with the baseline for moderate 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 action ('Delete records') and target resource ('from a table'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'execute-query' or 'update-data' that might also modify data, though the verb 'Delete' is distinct enough for basic differentiation.
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 stating 'Requires WHERE conditions for safety' and 'Includes confirmation prompt for large deletions,' which suggests when to use it (for deletion with conditions) and hints at safety considerations. However, it doesn't explicitly compare to alternatives like 'update-data' or specify when not to use it, leaving some ambiguity.
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 can check status, view error details, and retry connections, which covers basic behavior. However, it doesn't mention important aspects like whether this requires special permissions, what format error details come in, or if there are rate limits on retry attempts.
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 sentence states the core functionality, and the second provides specific parameter guidance. No wasted words or redundant information.
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 diagnostic tool with no annotations and no output schema, the description provides adequate but minimal information. It covers what the tool does and parameter usage, but doesn't explain what the output looks like (status format, error detail structure) or potential side effects of retrying.
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 schema has 0% description coverage for its single parameter. The description compensates by explaining the 'retry' parameter's purpose ('attempt reconnection when database is unavailable') and when to use it ('Use retry: true'). This adds meaningful context beyond the bare schema.
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 ('check', 'view', 'retry') and resource ('database connection status'). It distinguishes from siblings like execute-query or get-schema by focusing on connection health rather than data operations.
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 the tool ('when database is unavailable') and mentions the retry parameter usage. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
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 MCP server](https://glama.ai/mcp/servers/cesarvarela/postgres-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cesarvarela/postgres-mcp)

Score Badge

Copy to your README.md:

[![postgres-mcp MCP server](https://glama.ai/mcp/servers/cesarvarela/postgres-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cesarvarela/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/cesarvarela/postgres-mcp'

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