Postgres MCP Pro

Server Quality Checklist

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

Latest release: v0.4.2
Disambiguation4/5
Most tools target clearly distinct concerns: schema listing, object details, SQL execution, explain plans, active queries, locks, sizes, and index analysis. The main potential confusion is between analyze_db_health and get_database_info, which both provide broad database-level overviews and could lead an agent to pick the wrong one.
Naming Consistency5/5
All tool names follow a consistent lowercase verb_noun pattern (list_schemas, get_object_details, execute_sql, analyze_index_performance, etc.). The naming convention is uniform and predictable, making it easy to infer what each tool does.
Tool Count4/5
15 tools is at the upper end of the ideal range but still reasonable for a Postgres server covering introspection, SQL execution, performance analysis, and health checks. The inclusion of manage_encryption_key and list_tools adds some scope beyond the core database domain, making the set feel slightly over-packed.
Completeness4/5
The tool surface covers schema discovery, object details, arbitrary SQL execution, query explanation, performance diagnostics, active queries, locks, table sizes, and database info. Notable gaps include no query cancellation/termination, no vacuum/analyze maintenance tool, and no explicit database-level listing, though execute_sql can work around some of these.
Average 3.7/5 across 15 of 15 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to communicate safety or side effects, and the description does not compensate. It simply says 'Execute a SQL query' without disclosing that the tool can potentially modify or destroy data, how it behaves with transactions, or what the response looks like.
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 compact and front-loaded with the core action followed by a minimal parameter list. Every sentence adds value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw SQL execution tool with no annotations and no output schema, the description is under-specified. It lacks essential context about destructive potential, return format, error behavior, and execution constraints. Agents need more guidance before safely invoking it.
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?
Although schema description coverage is 0%, the docstring explains both parameters: 'sql' is the statement to execute and 'database_url' is optional with fallback to DATABASE_URL from .env. This adds meaningful context, especially the default behavior for database_url.
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 states the primary action clearly: 'Execute a SQL query.' This distinguishes it from sibling analysis tools like explain_query and list_schemas, though it does not explicitly clarify that it can run arbitrary read/write/DDL SQL rather than only read-only queries.
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 explain_query or get_table_sizes. There are no exclusions, prerequisites, or warnings about when direct SQL execution is or is not appropriate.
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 the full burden of behavioral disclosure. It does not explicitly state that the tool does not execute or validate SQL, nor describe side effects (or their absence), output format, or error behavior. 'Format/beautify' implies a safe read-only operation, but this is not stated.
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 very short and front-loaded: it states the purpose in the first sentence, then documents the parameter. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is mostly usable, but the absence of an output schema and annotations means it should at least state that the result is formatted SQL text and that the query is not executed. Those details are missing, leaving some ambiguity for an agent.
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 provides only a type and title for 'sql', while the description adds the meaningful clarification that it expects 'Raw SQL text to format.' This is enough semantic value for a single parameter, though it could be richer with an example or dialect note.
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 uses a specific verb ('Format/beautify') and a clear resource ('SQL query'), making the primary purpose immediately understandable. It does not explicitly contrast with sibling tools such as execute_sql or explain_query, but the intent is still unambiguous.
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 about when to use this tool versus execute_sql, explain_query, or other siblings. There is no mention of exclusions, prerequisites, or the fact that this tool should be used only when the user wants readability rather than execution or analysis.
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 behavioral disclosure burden. It does disclose an important behavior: health_type is currently ignored and the report always includes all checks. However, it does not state whether the operation is read-only, what the report contains, or any side effects, leaving meaningful 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 short and front-loaded, with the core statement first and parameter details in a compact Args block. Every sentence contributes useful information, and there is no redundant filler.
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 only two optional parameters, the input documentation is nearly complete. However, there is no output schema and no description of what the returned health report contains, which checks are run, or how the result is structured. The description is adequate but leaves the tool's behavior and return value under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully document the parameters, and it does. health_type is explicitly marked as unused and defaulting to 'all', while database_url is documented as optional with a .env fallback. Both parameters receive semantic meaning beyond the bare schema titles and defaults.
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 identifies the resource as 'database health' but uses the noun phrase 'overview' rather than a specific verb like 'run' or 'analyze'. It does not differentiate itself from sibling tools such as get_database_info or analyze_index_performance, leaving the agent to infer what makes this tool distinct.
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 explains that health_type is accepted for compatibility and that the report always includes all checks, but it gives no guidance on when to choose this tool over alternatives like analyze_index_performance or get_table_sizes. No exclusions or alternative-selection criteria are provided.
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 must carry the full burden of disclosure. It does mention the database_url fallback behavior, but it does not state whether the operation is read-only, whether special permissions are needed, or what side effects might occur. For a database-accessing tool, 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 front-loaded purpose sentence followed by a clean parameter block. There is no redundancy, and every sentence contributes necessary 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?
Given no output schema or annotations, the description covers invocation but not the return contract or failure behavior. An agent knows what the tool does and how to pass arguments, but not what the response structure looks like or when to prefer this tool over siblings, leaving a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero property descriptions, yet the description's Args section fully documents all three parameters: schema_name with default 'public', sort_by listing valid values 'total', 'table', or 'indexes', and database_url with its optional env fallback. This provides complete invocation semantics beyond the bare 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 opens with 'Show table sizes including indexes and total,' which names a specific verb and resource. It is clear about the tool's scope, though it does not explicitly differentiate from siblings like get_object_details or analyze_index_performance.
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?
There is no guidance about when to use this tool versus alternatives such as analyze_index_performance or get_object_details. The description provides no use cases, prerequisites, or exclusions, leaving the agent to infer applicability.
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?
No annotations are present, so the description carries the behavioral disclosure burden. It does clarify that database_url is optional and falls back to DATABASE_URL from .env, and it states the kind of output. However, it does not mention potential permission requirements, whether the list is scoped to the current database/user, or any performance implications.
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: one sentence for the core purpose and a brief parameter note. There is no filler or redundancy, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description gives enough to invoke it correctly: what it does, what it returns, and how to provide the connection. However, with no annotations or output schema, it leaves minor ambiguity about the exact fields returned and any access prerequisites.
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 only provides the parameter name, nullability, and default null. The description adds meaningful context by stating the parameter is optional and that omitting it uses DATABASE_URL from .env. This compensates well for the 0% schema description 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 uses a specific verb ('List') on a well-defined resource ('currently running queries') and includes the output attribute 'duration'. It is implicitly distinguishable from siblings like get_top_queries, which suggests historical or aggregated query data, though it does not explicitly name any alternatives.
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?
There is no guidance about when to use this tool versus alternatives such as get_top_queries, get_database_locks, or analyze_db_health. The description states only what the tool does, not the conditions that make it the right choice.
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. 'Show' implies a read-only operation, but the description does not explicitly disclose safety, required permissions, potential performance impact, or what happens on failure. It adds no behavioral context beyond the core function.
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 compact and front-loaded: the core purpose appears in the first sentence, followed by a concise Args section. Every part earns its place, and the formatting is easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essentials: what it shows and how to pass an optional URL. However, it omits usage context, return shape, and any behavioral caveats, leaving a noticeable gap for an agent deciding whether this is the right tool.
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 zero description coverage, so the description must carry parameter meaning. It does: database_url is explained as optional and falls back to DATABASE_URL from .env. This adds meaningful context beyond the raw schema, though URL format or connection behavior is not detailed.
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 states a specific action ('Show') on a specific resource ('current database locks and blocking queries'), making the tool's purpose immediately clear. It also distinguishes it from sibling tools like get_active_queries by focusing on locks and blocking, not just running queries.
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 given about when to use this tool instead of alternatives such as get_active_queries or analyze_db_health. There are no exclusions, prerequisites, or context cues beyond the basic function.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only explains configuration defaults such as the public schema and DATABASE_URL fallback, but does not say whether the operation is read-only, what it returns, or whether it has side effects or performance implications.
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 purpose is front-loaded in a single clear sentence, followed by concise argument descriptions. There is no filler or unnecessary repetition of structured schema data.
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?
The arguments are well documented, but there is no output schema and no description of what the tool returns or what a successful response looks like. For an analysis tool, the missing output and behavioral details create a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by clearly explaining both parameters: schema_name is the schema to analyze with a default of 'public', and database_url is optional and falls back to DATABASE_URL from .env. This adds meaning beyond the schema's bare titles and defaults.
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 states a specific action and resource: 'Analyze index usage and find unused/duplicate indexes.' It is clear and distinguishes the tool's focus from most siblings, although it does not explicitly differentiate it from analyze_db_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for analyzing index usage and finding unused or duplicate indexes, which implies when it should be used. It does not mention when not to use it or name alternative tools, so it lacks explicit routing guidance.
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 implies a non-mutating read operation through the word 'Get', but it does not explicitly disclose read-only behavior, permission requirements, failure modes, or return characteristics.
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 minimal and well-organized: a single-sentence purpose followed by a clear argument list. There is no filler or redundant restatement of the tool name.
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?
The definition is adequate for a simple introspection tool: all parameters are documented and the purpose is clear. However, with no annotations and no output schema, it omits the return format (e.g., column names, types) and any permission or error behavior, so an agent must still infer some important details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions (0% coverage), but the description fully compensates with an Args block explaining schema_name, object_name, and database_url. It also clarifies that database_url is optional and falls back to DATABASE_URL from .env, which is valuable beyond the schema's default null.
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 uses a specific verb ('Get') and a concrete resource ('columns of a table or view'), which clearly states what the tool does. It also distinguishes the tool from sibling operations like list_objects or execute_sql by narrowing the scope to table/view columns.
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 its siblings, and it names no alternatives or exclusion cases. It only documents arguments, leaving the agent to infer appropriate usage context.
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, the description carries the behavioral burden. 'List' implies a read-only operation, and the note about database_url defaulting to DATABASE_URL from .env adds useful behavioral context. However, it does not describe return format, error behavior, or any permissions/requirements.
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 compact and front-loaded with the purpose, followed by a short parameter list. Every sentence adds value, and the formatting is easy to scan.
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?
The parameter semantics are well covered, and the description is sufficient for making a basic call. However, with no output schema and no annotations, the lack of any mention of return values or additional behavioral outcomes leaves a notable gap for an agent deciding whether this tool fully satisfies a request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 explain all parameters, and it does. It clarifies schema_name, enumerates object_type options with a default, and explains database_url's optionality and environment fallback, going well beyond the bare 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 first sentence clearly names the action (list) and resource (tables/views/sequences in a schema), making the tool's core function obvious. It is distinct from siblings like list_schemas, but it does not explicitly call out 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?
No guidance is given on when to prefer this tool over alternatives such as get_object_details or execute_sql. The description states what it does but not the conditions or use cases that should trigger selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states the action and the optional database URL fallback, but does not mention whether the operation is read-only, what output shape to expect, whether system schemas are included, or what happens on invalid credentials or URLs.
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 two concise sentences with no filler. The purpose is front-loaded and the parameter documentation is direct and easy to parse.
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?
The tool is simple with one optional parameter and no output schema, so the description is mostly adequate. However, it lacks return-format details, permission or safety notes, and any pointer to sibling tools, leaving some contextual gaps that an agent would have to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by documenting database_url as optional and explaining the fallback to DATABASE_URL from .env. This adds meaningful behavior beyond the schema's bare nullable string with default null.
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 has a specific verb and resource: 'List all schemas in the database.' This clearly distinguishes it from sibling tools like list_objects, which covers objects rather than schemas, and from execute_sql or get_database_info, which serve different purposes.
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 instead of alternatives such as list_objects or get_database_info. It implies general schema discovery but does not state exclusions, prerequisites, or when a different sibling would be more appropriate.
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, the description carries the full burden and does well by disclosing that analyze=true really runs the query and can execute DML, plus the default from EXPLAIN_ANALYZE in .env. It does not describe other potential behaviors like error handling or whether the plan is returned as text/JSON, but the critical side-effect risk is clearly communicated.
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 well-structured with a one-line summary followed by a clearly formatted Args block. The analyze warning is verbose but necessary. Every line contributes useful information, though the docstring could be slightly tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers what an agent needs to invoke the tool safely: required sql, optional analyze with its side-effect warning, and optional database_url. It does not specify the return format of the execution plan, but 'Get query execution plan' gives enough context for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully explain parameters. It covers all three: sql, analyze (including default behavior and a warning), and database_url (including the .env fallback). This adds substantial meaning beyond the raw 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 opens with 'Get query execution plan,' which names a specific verb and resource clearly. It implicitly differentiates from siblings like execute_sql by focusing on plans rather than query execution, but it does not explicitly name any sibling contrast.
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 gives strong parameter-level usage guidance, especially the WARNING about analyze=true actually executing INSERT/UPDATE/DELETE. However, it does not explicitly state when to prefer this tool over execute_sql or other database analysis siblings, leaving selection partly to inference.
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?
No annotations are provided, so the description carries the transparency burden. The read-only 'Get' verb and the listed return categories make the behavior reasonably clear, and the args note explains the DATABASE_URL/.env fallback. It stops short of describing response format, permissions, or error behavior, but for a simple informational tool this is a minor 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 front-loaded with a clear purpose, uses a compact listing of information categories, and includes a short Args note. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description is mostly complete: it states what information is returned and how the parameter behaves. It lacks an explicit note about response format or error conditions, but these are not critical for invoking this tool correctly.
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 zero description coverage, so the description must compensate. It does so meaningfully by stating that database_url is optional and that omitting it falls back to DATABASE_URL from .env. This adds real value beyond the schema's bare type/default info, though URL format details are not specified.
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 states a clear verb ('Get') and resource ('database information'), and enumerates the content categories: version, size, extensions, server settings. This makes it distinct from the more specific sibling tools like get_table_sizes 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 word 'general' implies an overview use case, but the description gives no explicit when-to-use/when-not-to-use guidance and does not name alternatives among the many sibling tools. Usage differentiation is left to inference.
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, the description carries the full behavioral burden and does this well: it discloses that sort_by is ignored, that sorting is always by total_exec_time, and that defaults come from environment variables. It also warns about the extension prerequisite. It does not describe error behavior if the extension is missing or the exact output shape, but it reveals the most important behavioral quirks.
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 compact and front-loaded: the first line states the core purpose and prerequisite, followed by a clean parameter list. Every sentence adds useful information, including the sort_by caveat and environment defaults. There is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with no annotations and no output schema, the description covers invocation essentials: extension requirement, parameter semantics, defaults, and the ignored sort parameter. It could be slightly more complete by mentioning return shape or error conditions, but what is present is enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 explain every parameter, and it does: limit's optionality and environment default, sort_by's compatibility-only status and actual ignored behavior, and database_url's fallback to DATABASE_URL. This adds substantial meaning beyond the raw schema property names and defaults.
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 function: return top queries by resource usage and explicitly calls out the required pg_stat_statements extension. It distinguishes the tool from siblings like get_active_queries by focusing on resource usage rather than active queries. It lacks an explicit verb such as 'get' or 'list', but the title and phrasing make the purpose unambiguous.
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 the tool is usable by noting that pg_stat_statements must be installed and that sort_by is accepted only for legacy compatibility. It does not explicitly name alternatives or state when NOT to use this tool, so it stops short of a 5. The context is sufficient for an agent to choose it appropriately over unrelated siblings.
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?
No annotations are provided, so the description carries the full burden. It discloses the return format (JSON array/string), the per-tool fields (name, description, parameters), and the key behavioral trait that no database connection is required. For a read-only listing tool, this is adequate 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?
Every sentence contributes: the primary purpose, the return type, the runtime discovery context, and a concrete example of the output. The format is front-loaded with the action and resource, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description provides everything an agent needs: what it does, what it returns, and when to use it. No obvious gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object, so there is nothing for the description to add. The baseline for 0 parameters is 4, and the description appropriately focuses on behavior and return format instead.
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 starts with a specific verb and resource: 'List all available MCP tools of this server with their descriptions.' It clearly distinguishes this from sibling tools like list_schemas and list_objects, which list database entities rather than the server's own tool inventory.
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 states a clear context for use: 'Does NOT require a database connection — useful for discovering capabilities at runtime.' This implies when to choose it, especially when the database is unavailable. It does not explicitly contrast with alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden and does so exceptionally well. It explicitly states which actions make no changes (status), which transition certs to ROTATING with a grace period, which permanently break decryption (revoke), and even flags validate as a currently no-op placeholder. It also discloses the passphrase environment variable dependency and audit-log 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 long but every sentence earns its place: an overview, an action-by-action breakdown, parameter definitions, return-value summary, and concrete examples. The organizational structure with Args, Returns, and Examples makes complex multi-action behavior easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with six actions, six parameters, no output schema, and no annotations, the description covers all necessary context: action semantics, ordering requirements, return shapes, environment variable usage, and examples. An agent can select the correct action and invoke it with appropriate parameters without needing additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 the six parameters, and it does. Every parameter (action, ttl_days, subject, use_passphrase, kid, reason) is explained with meaning, defaults, and context, including which actions each parameter applies to.
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 manages Data Encryption Certificates (Fernet keys) for stored secrets and enumerates six distinct actions (status, generate, rotate, rekey, revoke, validate), each with a specific verb and effect. This makes it unambiguous and easily distinguishable from the sibling database inspection tools.
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 strong usage guidance for each action, including the intended workflow order (e.g., 'run after rotation' for rekey, and revoke for compromised certificates). It does not explicitly name alternative tools to use instead, but this tool is a unique encryption-management utility among the siblings, so the action-level guidance serves as sufficient usage direction.
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/sparta2025/postgres-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sparta2025/postgres-mcp)

Score Badge

Copy to your README.md:

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

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