postgres-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping purposes, such as query, explain_query, get_slow_queries, and statements_enhanced all dealing with query execution and analysis. Similarly, connection_pool, connection_leak, and get_connections all monitor connections, and multiple ORM performance tools blur boundaries despite detailed descriptions.
Naming Consistency2/5
Naming conventions are mixed: some follow verb_noun (list_objects, describe_table), others are noun_phrases (replication_status, extends_stats), and some use compound adjectives (autovacuum_advisor, statements_enhanced). Long, inconsistent ORM-related names further reduce predictability.
Tool Count2/5
40 tools is excessive for a PostgreSQL monitoring server. Many niche tools (huge_pages, extended_stats, generated_columns) are very specific and could be consolidated into broader diagnostic tools, making the set feel overweighted and harder to navigate.
Completeness3/5
The tool set covers a wide range of database monitoring and health checks, including queries, schema inspection, index analysis, and replication. However, it lacks administrative actions like vacuum, index creation/dropping, or even EXPLAIN ANALYZE, leaving operational gaps for a server that purports to manage PostgreSQL.
Average 3/5 across 40 of 40 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 transparency burden. It fails to disclose that EXPLAIN without ANALYZE does not execute the query, while ANALYZE does, nor does it mention any side effects or read-only nature. This is a significant gap for a tool that can execute queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no fluff, making it concise in word count. However, it is under-specified for a tool with six parameters and nontrivial behavior, so it is not appropriately sized for the tool's complexity.
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 absence of annotations and output schema, and the presence of six parameters including analyze (which executes the query), the description is incomplete. It does not explain return formats, how analyze or buffers affect behavior, or integration with sibling database tools.
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%, so the description should compensate. It does not mention any of the six parameters (sql, costs, format, analyze, buffers, database_name) or their meanings. The description adds zero semantic value beyond the schema's structured field definitions.
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 the specific verb 'Get' and resource 'query execution plan', with the parenthetical '(EXPLAIN)' clarifying the database operation. It is clear and distinguishes from siblings like query or describe_table, though it lacks detail on its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as query or get_slow_queries. There is no mention of prerequisites, scenarios, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions parallel workers and WAL tracking but doesn't disclose what the output includes, whether it's read-only, or any performance implications. This is insufficient for an agent to understand side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, which is efficient, but it lacks detail that could be added with a few more sentences. It's not padded, but it's also not fully specified; it reads more like a title than a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that analyzes pg_stat_statements with two optional parameters and no output schema, the description is insufficient. It doesn't explain the meaning of 'enhanced', the expected output format, or how to use the parameters. The agent would need to guess or rely on the schema, which is incomplete given the lack of param semantics.
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%, and the description doesn't mention either the 'limit' or 'database_name' parameters. The schema provides types and constraints, but the description adds no semantic meaning, leaving the agent to infer what these parameters do in context.
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 identifies the resource (pg_stat_statements) and the action (analysis), and mentions specific features (parallel workers, WAL tracking) that distinguish it from siblings like get_slow_queries and wal_monitor. However, it doesn't explicitly state what the tool returns or how 'enhanced' differs from a standard analysis.
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 on when to use this tool versus alternatives. The description doesn't mention exclusions, prerequisites, or comparative scenarios with sibling tools like get_slow_queries or wal_monitor.
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 present, the description carries the full burden of explaining side effects or safety. It only restates the high-level purpose without disclosing whether this is a read-only diagnostic, what data it accesses, whether it is potentially expensive, or what the return format is. This is a significant gap for a tool that likely queries system catalogs.
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 concise sentence with no unnecessary words. It is appropriately brief for a diagnostic tool name, though its brevity comes at the cost of missing critical details. Still, as a structure, it is well-formed and front-loaded.
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 there is no output schema, no annotations, and only one optional parameter, the description needs to explain return values and behavioral context. It does neither. While the purpose is clear, an agent cannot fully assess when to invoke this tool or what response to expect, making it incomplete for a diagnostic tool with no other structured documentation.
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?
The schema has one optional parameter (database_name) with a pattern, but the description does not mention it at all. With 0% schema description coverage, the agent gets no help understanding how or why to pass database_name, or what effect it has on the analysis. The description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects connection leaks and analyzes acquisition patterns, which is specific and distinguishes it from siblings like get_connections (which likely just lists connections) or connection_pool (which manages pools). It is not a tautology and gives a concrete sense of the tool's function, though it could be more precise about what 'analyze patterns' entails.
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. There is no mention of prerequisites, typical scenarios, or exclusions. The description implies it is for diagnosing connection leaks, but it does not explicitly say when to choose it over tools like get_connections or transaction_monitor.
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. It only says 'Recommend' without disclosing read-only status, side effects, required permissions, or output format. The tool's actual behavior beyond the verb remains opaque.
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, non-redundant sentence. It is efficiently worded and front-loaded, though it lacks any additional structure or detail. It is concise but not overly terse to the point of meaninglessness.
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?
With no output schema and no parameter explanation, the description gives insufficient context. An agent cannot tell what input to provide or what kind of output to expect from a 'recommendation,' making the tool difficult to use correctly in practice.
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%, and the description does not mention the 'schema' or 'database_name' parameters at all. The agent has no clue how these affect the recommendation or how to use them, leaving the parameters functionally 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 states a specific action ('Recommend partitioning strategies') and a clear resource scope ('time-series entity tables'). It distinguishes itself from sibling tools like 'list_partitions' which actually lists partitions, while this one provides recommendations.
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. There is no mention of prerequisites, exclusions, or scenarios where this should be preferred over other partition-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only restates the function. It does not disclose whether the analysis is read-only, what lock sources it inspects (e.g., pg_locks), whether privileges are needed, or what the output format is—a significant gap for a diagnostic 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 single sentence 'Analyze deadlock patterns and lock wait information' is concise and front-loaded with no filler. It loses a point because the available space could have carried more decision-relevant detail without becoming verbose.
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?
Though the schema is minimal (one optional parameter), the tool has no output schema or annotations, so the description alone must convey what to expect from a call. It omits output shape, safety profile, and parameter purpose, making it incomplete for a diagnostic 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 needed to explain the optional database_name parameter, but it never mentions it. The schema's pattern and maxLength define format only; the agent cannot discern whether the parameter filters scope or targets a specific database.
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 the specific verb 'Analyze' with a clear resource ('deadlock patterns and lock wait information'), making the core function identifiable. It doesn't explicitly distinguish from diagnostic siblings like transaction_monitor or diagnose_database, so it falls short of a 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?
No guidance is provided on when to use this tool versus alternatives. The description is purely functional—it names no trigger conditions, alternatives, or exclusions, leaving the agent to infer usage from the name alone among many diagnostic 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Validate' without explaining whether it is read-only, what happens when differences are found, what the output is, or any side effects. 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 sentence with no redundant words. It front-loads the core action and resources, making it concise and structurally clean. However, the brevity contributes to other dimension deficiencies.
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?
The tool has no output schema, no annotations, and a one-line description. It omits essential context such as expected output, parameter necessity (both optional), and how it relates to similar sibling tools. This is inadequate for effective tool selection and 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%, so the description must compensate by explaining the 'schema' and 'database_name' parameters. It does not mention them at all, leaving the agent to infer their meaning solely from parameter names and the vague description.
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 with a specific verb 'Validate' and identifies the resources 'database schema' and 'JPA/Hibernate entity mappings'. This is unambiguous, but it does not explicitly differentiate itself from the closely named sibling tool 'jpa_schema_validation', so it falls short of a 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?
There is no guidance on when to use this tool versus alternatives. The description gives no preconditions, no exclusions, and does not mention any sibling tools. Given the many JPA/ORM-related siblings, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the tool lists and monitors, implying read-only behavior, but does not explicitly state whether it modifies anything, what privileges are needed, or what 'monitor partition pruning efficiency' entails. This is incomplete for a tool that may rely on system statistics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. The PostgreSQL 12+ version qualification adds useful context without verbosity. It is extremely concise and easy to scan.
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 output schema and no annotations, the description should explain return values, required permissions, and the meaning of 'partition pruning efficiency.' It does none of this. The tool is clearly about partition monitoring, but the description alone is insufficient for an agent to know what to expect when invoking it.
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?
The schema has 0% description coverage and the tool description provides no parameter-level guidance. The parameters table, schema, and database_name are named but their roles, defaults, and interaction (e.g., whether they are all optional and what happens if omitted) are entirely undocumented. The description does not compensate for this gap.
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 lists partitioned tables and monitors partition pruning efficiency, which is specific and distinguishes it from sibling tools like list_objects or list_indexes. However, it is slightly ambiguous whether 'list partitioned tables' means all partitioned tables in scope or the partitions of a given table.
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 when-to-use or when-not-to-use guidance is provided. The PostgreSQL 12+ version note gives context but does not explain when to choose this over alternatives like describe_table, list_indexes, or timeseries_partition. Usage is only implied by the tool's name and purpose.
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. The verb 'Monitor' implies a read-only operation, but the description does not disclose what data is returned, whether any system state is affected, or what permissions are needed. It is vague about the actual behavior beyond a superficial high-level statement.
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 one concise sentence with no fluff, making it easy to parse quickly. It is appropriately short for a simple tool, though it lacks detail that would be valuable.
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?
The tool has no annotations, no output schema, and only one simple parameter, so the description must carry more weight. As written, it does not explain what output to expect, what 'performance' metrics are included, or any context about parallel query workers. The description is inadequate for an agent to fully understand the tool's behavior.
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 defines a single parameter 'database_name' with a pattern and maxLength, but the description does not explain how this parameter affects the monitoring behavior. Schema description coverage is 0%, so the description was expected to compensate, but it does not mention the parameter at all.
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 the specific verb 'Monitor' and identifies the resource as 'parallel query worker usage and performance', which clearly states its purpose. However, it does not differentiate it from sibling monitoring tools like progress_report or wal_monitor.
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 over sibling tools, nor does it mention any prerequisites or exclusions. This is a significant gap given the large set of sibling monitoring tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It only says 'Analyze', which implies a read-only operation, but it does not explicitly state whether it requires special permissions, whether it executes any queries, or what the output format is. This lack of transparency could lead to incorrect assumptions about side effects or access requirements.
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 concise sentence that directly conveys the tool's purpose. It avoids unnecessary detail and is easy to parse. However, it could be slightly more structured by front-loading the key action and adding a brief note on parameters, but it remains appropriately brief.
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 absence of an output schema and annotations, the description should explain what the agent can expect from the tool's return value. It mentions 'cache hit ratio and query patterns' but does not clarify the format, granularity, or whether it returns a report or raw data. For a diagnostic tool, this incompleteness hampers effective 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?
The schema includes one optional parameter 'database_name' but provides no description of its purpose or how it affects the analysis. The tool description also fails to mention the parameter, leaving the agent to infer its meaning from the name alone. With 0% schema description coverage, the description should have compensated by explaining the parameter's role, but it did not.
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 with a specific verb ('Analyze') and a defined resource ('prepared statement cache hit ratio and query patterns'). It distinguishes itself from generic query tools by focusing on prepared statement cache metrics, though it does not explicitly contrast with sibling tools like statements_enhanced.
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 on when to use this tool versus alternatives. It does not mention whether to use it for performance diagnostics, cache tuning, or how it relates to other diagnostic tools such as get_slow_queries or statements_enhanced. The absence of usage context makes it hard for an agent to select it appropriately.
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 must carry the full burden of behavioral disclosure. It indicates a read-only monitoring action, but does not explain what data is returned, whether it affects the system, or any permission requirements. The term 'monitor' hints at non-destructive behavior, but this is not explicit.
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, succinct sentence with no filler words. It front-loads the primary action and resource, making it easy to parse. While under-specified, conciseness itself is excellent.
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?
The tool is simple (one optional parameter, no output schema), but the description is still incomplete for an agent selecting among many monitoring tools. It lacks information about the return format, specific metrics, and how it differs from other performance monitors like transaction_monitor or orm_performance.
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 one parameter, database_name, with no description (0% coverage). The parameter name is somewhat self-explanatory, but the description adds no context about what this parameter does, whether it is optional, or how it filters batch operation data. The agent receives minimal guidance beyond the schema's pattern constraint.
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 'Monitor' and names the resource 'JDBC batch operation performance and efficiency', clearly indicating the tool's purpose. It doesn't explicitly distinguish from sibling monitoring tools like transaction_monitor or prepared_statement, but the resource is unique enough to imply a different focus.
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 the many sibling monitoring tools. It doesn't mention contexts, prerequisites, or alternative tools, leaving the agent to guess when this is the appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the use of pg_stat_statements, which hints at read-only analysis, but does not disclose whether there are side effects, permission requirements, return result format, or any other operational behaviors. The description is too brief to convey the tool's runtime 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 a single concise sentence that is front-loaded with the main purpose. It contains no fluff or redundant information, 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 that there are 6 optional parameters, no output schema, and no annotations, the description is incomplete for a diagnostic tool. It lacks information about the returned data shape, when to prefer this over sibling tools, and any operational caveats. The single sentence is not enough to fully contextualize the tool's usage.
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 6 parameters with 0% coverage in the description. The description only mentions 'filtering and sorting' without explaining which parameters map to these actions or defining their semantics. While the schema itself provides names and types, the description adds minimal value beyond that, leaving the agent to infer the purpose of fields like min_calls or include_query_text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes slow queries via pg_stat_statements, using the specific verb 'analyze' and naming the data source. It also mentions filtering and sorting, which gives a precise scope. However, it does not explicitly differentiate from sibling tools like statements_enhanced or explain_query, though the pg_stat_statements reference adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does without any context on prerequisites, typical scenarios, or exclusions (e.g., when to use explain_query instead). This leaves the agent without decision criteria.
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 must carry the full burden of behavioral disclosure. It says 'establish and monitor', implying mutability, but does not explain whether baselines are persisted, what side effects occur, or whether any permissions are required. This is a significant gap for a tool that may create state.
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?
A single sentence with no filler, front-loaded with the core action. It is concise and easy to parse, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks critical context about what a baseline contains, how it is stored, the return format, and how it relates to sibling tools. Given no output schema and no annotations, more detail is needed for reliable use, especially among many ORM-related tools.
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 a single database_name parameter, but the description does not mention it at all. With 0% schema description coverage, the description fails to compensate by explaining how the parameter affects the baseline operation, leaving the agent to infer that it specifies the target database.
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 phrase 'Establish and monitor' and identifies the resource as 'performance baselines for ORM CRUD operations'. It distinguishes from the more general sibling orm_performance by emphasizing 'baselines', though it could be clearer on what a baseline entails.
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 alternatives like orm_performance or orm_index_coverage. It does not state use cases, prerequisites, or exclusions, leaving the agent to guess which tool fits a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It lists what is monitored but does not state whether it's read-only, required permissions, side effects, or whether it returns current snapshots or historical trends. This is insufficient for a monitoring 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?
A single concise sentence that front-loads the verb and lists key monitored aspects. Every word adds meaning with no repetition or 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?
The description is minimal: no output schema, no annotations, and no context about return values or prerequisites. For a tool with only one optional parameter, it still leaves out critical behavioral and usage context needed by an agent.
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?
There is one optional parameter, database_name, with a pattern but no schema description (0% coverage). The tool description does not mention the parameter at all, so it fails to clarify how database_name filters or affects the monitoring scope.
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 identifies a monitoring tool for WAL size, growth, archive status, and replication slots. It names specific resources and metrics, making it distinct from generic siblings, though it doesn't explicitly differentiate from replication_status.
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 use this tool versus alternatives like replication_status or backup_monitor. There are no usage scenarios, prerequisites, or exclusions, so an agent receives no decision support.
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. 'Execute SQL' implies the ability to run arbitrary SQL, potentially including data modification, but the description does not state whether this is read-only or allows writes, what permissions are required, how results are returned, or any pagination behavior beyond the schema. This is significant under-disclosure for a tool with no annotations.
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, focused sentence with no fluff or redundant wording. It is front-loaded with the core verb and resource. While it is concise, it could benefit from a bit more structure (e.g., separating purpose from usage guidance), but as-is it is an efficient use of words.
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 has 5 parameters, no annotations, and no output schema, the description is too minimal to provide complete context. It does not describe return values, side effects, result limits, or how to use the database_name parameter. For a raw SQL execution tool, critical safety and usage details are missing.
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 description mentions 'pagination and parameterization' which gives semantic meaning to the offset, pageSize, and parameters fields, but it does not explain each parameter beyond that. With 0% schema description coverage, the description must compensate more thoroughly; database_name is not mentioned at all. It adds some value but is not sufficient for a 5-parameter tool.
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: 'Execute SQL with pagination and parameterization'. This uses a specific verb ('Execute') and resource ('SQL'), and the mention of pagination/parameterization hints at capabilities that distinguish it from sibling tools like describe_table or explain_query. However, it does not explicitly differentiate from other query-like tools or name 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 on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or preferred scenarios, such as 'for read-only queries use X instead'. Given the large set of sibling tools, the absence of any usage context is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It lists actions but does not state whether the tool is read-only, requires special permissions, or impacts the system. The short phrase lacks depth about side effects or return 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 a single concise phrase with no redundant words. It front-loads the primary action (List) while adding two secondary actions compactly, though it could be more 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 output schema and annotations, the description should provide more context about expected results, compatibility checks, and dependency semantics. It is too brief to fully prepare an agent for invocation.
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 coverage is 0% and the description does not mention the single optional parameter database_name. The empty schema description leaves the purpose of this parameter entirely unexplained, so the agent cannot infer its semantics.
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 identifies the resource (extensions) and three specific verbs (List, check, view) that define the tool's actions. It distinguishes from sibling tools like list_objects or query by focusing solely on extensions management.
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 extension-related tasks but does not explicitly state when to use this tool versus alternatives. No exclusion criteria or alternative tool names are mentioned, leaving the context implicit.
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?
The description implies a read-only operation but does not disclose behaviors such as whether system schemas are included by default or how the database_name parameter affects results. With no annotations, this partial transparency leaves gaps for the agent.
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, grammatically complete sentence with no redundant words. It is concise and easy to parse, though it sacrifices helpful detail for brevity.
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 two parameters and no annotations or output schema, the description is too sparse. It does not clarify parameter defaults, whether system schemas are included, or the return format, leaving significant ambiguity for a tool with schema coverage at 0%.
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%, and the description does not explain either parameter (database_name or includeSystemSchemas). The mention of 'database' is generic and does not convey semantics, so the description fails 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all schemas in the database' uses a specific verb and resource, clearly stating the tool's function. It distinguishes itself from sibling tools like list_objects and list_indexes by naming the exact resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is purely functional and does not provide context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'monitor' and 'detect exhaustion risks', which suggests a read-only operation, but it does not state whether it mutates data, requires specific permissions, or what the output format is. The absence of these details is a notable gap for a monitoring 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 a single, front-loaded sentence with no wasted words. It communicates the core purpose efficiently, though it lacks any structural breakdown (e.g., parameter details, examples) that would make it more useful. It is concise but at the expense of completeness.
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 monitoring tool with no annotations and no output schema, the description is overly minimal. It does not explain what 'exhaustion risks' means, what results look like, or how the parameters affect the scan. Sibling tools share context, but this tool still lacks essential operational details.
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% and the description does not explain the two parameters (schema, database_name) at all. It fails to clarify what these parameters filter or control, leaving the agent without meaningful guidance despite the parameters being optional. A 0-param baseline of 4 does not apply here; the two undocumented parameters require compensation that is absent.
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: 'Monitor sequences for JPA @GeneratedValue and detect exhaustion risks'. It uses a specific verb (monitor) and resource (sequences for JPA @GeneratedValue), and this is distinct from sibling monitoring tools like wal_monitor or transaction_monitor.
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 the tool is relevant for JPA sequence management, but provides no explicit guidance on when to use it versus alternatives. There is no mention of when not to use it or references to sibling tools, leaving usage context inferred rather than 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, the description must convey behavioral traits. It only says 'Monitor', which implies read-only, but does not disclose whether special privileges are needed, what the output format is, or any limitations. The tool's actual behavior (e.g., polling, time ranges) is unspecified, leaving significant ambiguity.
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 sentence of 8 words, front-loaded with the key purpose. It contains no filler or redundant information, achieving maximum efficiency.
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 simple tool with one optional parameter and no output schema, the description explains the main focus but omits crucial context: the parameter's purpose, expected return format, and how it differs from similar monitoring tools. It is too minimal to fully prepare an agent for 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 includes database_name with 0% description coverage, and the tool description does not mention or explain this parameter. While the parameter name is self-explanatory, its role in the monitoring context (e.g., how it filters backup progress or recovery timelines) is undefined, so the description fails to compensate for the low schema coverage.
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 monitors 'pg_basebackup progress' and 'PITR recovery timeline', using a specific verb ('Monitor') and distinct resources. This differentiates it from siblings like progress_report, wal_monitor, and replication_status, which focus on other aspects.
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 explicit guidance on when to use this tool versus alternatives like progress_report or replication_status. It implies usage through its stated purpose but lacks any exclusion criteria or mention of alternative tools, leaving the agent to infer the appropriate 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 full burden. It clearly indicates a read-only monitoring operation and specifies the HikariCP-specific scope. However, it does not state safety guarantees, required permissions, or failure modes for non-HikariCP pools, so some behavioral context is still missing.
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, tightly packed sentence that lists the key responsibilities without filler or redundancy. It is front-loaded with the main action and scope.
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 with no output schema, the description provides the core purpose but lacks parameter context, usage alternatives, and return details. The overlap with `connection_leak` and other siblings further limits how completely an agent can act on this description alone.
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 tool description does not mention `database_name` at all. The parameter name is self-explanatory as a database identifier, but the description adds no semantic value about what the parameter controls or how it affects the monitoring scope.
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 clear verb ('Monitor') and resource ('HikariCP connection pool metrics') and lists specific outcomes: detect leaks and track wait times. It is distinct enough from most siblings but overlaps with `connection_leak`, which also focuses on leak detection, creating mild ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as `connection_leak` or `get_connections`. The description simply states what it does without mentioning when to choose it over a dedicated leak-detection tool or other monitoring tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool 'gets' information but does not explicitly confirm read-only behavior, mention permission requirements, or describe the output format. It also omits any side effects or limitations.
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, focused sentence that avoids unnecessary details and clearly states the tool's purpose. It is front-loaded and every word adds value.
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 should provide more context about parameters, usage, and return values. While it mentions the content of the structure (columns, constraints, size statistics), it does not cover when to use this tool versus siblings or how the optional database_name affects behavior.
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?
The input schema lists three parameters (table, schema, database_name) with no descriptions within the schema. The tool description does not mention any of these parameters, providing no additional meaning beyond the parameter names. This is especially problematic since database_name is optional but never explained.
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 the specific verb 'Get' and identifies the resource as 'table structure' with explicit details on columns, constraints, and size statistics. This clearly distinguishes it from sibling tools like list_indexes or query, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving table metadata, but provides no explicit guidance on when to choose it over alternatives such as list_indexes or extended_stats. No exclusions or prerequisites are mentioned, leaving the usage context somewhat implicit.
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 must carry the full burden of behavioral disclosure. It merely lists the components (cache, connections, vacuum, indexes, sequences) without stating whether the operation is read-only, requires special permissions, runs any internal queries, or could have side effects. This is a significant gap for a diagnostic 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 extremely concise, consisting of a single, front-loaded phrase that efficiently conveys the tool's scope. It contains zero filler words and every component listed adds value. While it is under-specified, that is a completeness issue, not a conciseness issue.
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 has 3 optional parameters, no output schema, no annotations, and many specialized sibling tools, the description is incomplete. It does not explain return values, parameter usage, or how this composite tool differs from the individual specialized tools. The description provides only a high-level overview, leaving the agent to guess at critical operational details.
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%, and the description does not mention any of the three parameters (database_name, include_queries, include_connections) or their meaning. The description's list of components does not map to the parameters; for instance, 'include_queries' and 'include_connections' are not alluded to. The description completely fails to compensate for the lack of 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 identifies the tool as a 'Composite database health check' and enumerates the specific areas it covers (cache, connections, vacuum, indexes, sequences). This specific verb+resource+scope distinguishes it from the many specialized sibling tools (e.g., get_connections, sequence_monitor, index_dedup) by emphasizing its comprehensive nature.
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 phrase 'composite health check' implies this tool is for an overall assessment rather than a single-focused check, but no explicit guidance is given about when to use this tool vs. alternatives. There is no mention of exclusions or recommendations, so usage is only implied.
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 does not explicitly state whether this is a read-only operation, what side effects (if any) the 'recommendations' have, or any permission requirements. The word 'list' implies read-only but it 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 a single sentence, front-loaded with the action, and contains no filler words.
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 presence of three optional parameters, no output schema, and no annotations, the description is too minimal. It does not explain the nature of the recommendations, how parameters affect results, or what a response looks like, leaving the agent under-informed.
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%, and the description does not mention any of the three parameters (table, schema, database_name). It provides no additional meaning beyond the parameter names and constraints already present in the input 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 uses a specific verb 'List' with resource 'extended statistics' and adds 'provide recommendations for multi-column correlations', clearly identifying the tool's function. It distinguishes from sibling tools like list_indexes and list_partitions by focusing on extended statistics and correlation analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing multi-column correlations but does not explicitly state when to use this tool over alternatives or any prerequisites. There are no exclusions or alternative references, so guidance is only implicit.
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 disclose behavior fully. It says 'monitor' and 'identify', suggesting read-only analysis, but it does not state whether this is safe, what data is returned, or if any permissions are needed. The behavioral transparency is minimal.
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 concise sentence that front-loads the core purpose. Every word adds value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only a one-line description, the tool lacks critical context. It does not explain what metrics are reported, how missing indexes are determined, or how the optional parameters affect the analysis. The description is too sparse for a complex diagnostic tool.
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?
The input schema has three parameters (table, schema, database_name) with no descriptions (0% schema description coverage). The tool description does not mention or explain any parameters, leaving the agent without guidance on what values to provide or how they constrain the query.
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 function: 'Monitor foreign key performance and identify missing indexes.' It uses specific verbs and resources, distinguishing it from sibling tools like list_indexes or index_dedup by focusing on foreign keys and missing indexes.
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 monitoring foreign key performance, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context is implied but not articulated.
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 does not disclose whether the tool is read-only, whether it requires special permissions, or what side effects it might have (even monitoring tools might modify internal state or require elevated privileges). The verb 'monitor' weakly implies passivity, but this is not explicit.
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 sentence, front-loaded with the verb and resource, with no filler words. Every word contributes to the core purpose. It is concise without being under-specified in terms of its main intent.
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?
Despite the simple shape (one optional param, no output schema), the description is incomplete for actual use. It lacks explanation of the parameter's role, what data or recommendations look like, and any prerequisites or side effects. For an agent to invoke it correctly alongside many sibling monitors, more context is needed.
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?
The schema has one optional param (database_name) with 0% schema description coverage, and the description does not mention the parameter at all. The agent gets no help understanding how database_name affects monitoring or recommendations, so the description adds no semantic value beyond the bare parameter name.
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 ('Monitor') and resource ('huge pages usage') and clearly states the output (configuration recommendations). This distinguishes it from sibling monitoring tools like wal_monitor or transaction_monitor, which target different resources.
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 a usage scenario (monitoring huge pages and getting recommendations) but provides no explicit guidance on when to use it over alternatives, no prerequisites, and no exclusion criteria. It's the minimum viable: implied usage without clear context.
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 to cover safety or side effects, and the description does not disclose whether the operation is read-only, requires specific connections, or what happens on mismatches. The term 'validate' implies a read operation, but this is not explicitly stated, and no behavioral context is added.
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 sentence that is front-loaded with the action and subject. It contains no filler or repetition, making it maximally concise for the information it conveys.
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?
The tool has no output schema, no annotations, and the description does not explain the validation result, error handling, or the connection context. It also does not clarify which database or schema is being referenced, leaving significant gaps for an agent trying to invoke 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?
The input schema provides parameter names and constraints, but the description does not explain the relationship between 'schema' and 'database_name' or how they are used in validation. With 0% schema coverage in the description, the agent gets no additional semantic guidance beyond the parameter names themselves.
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 'Validate' with a clear resource: 'Spring Data JPA annotations against database schema'. It clearly distinguishes from sibling tools like jpa_mapping or orm_performance by focusing on validation against the schema.
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 jpa_mapping or orm_index_coverage. It does not state any preconditions, exclusions, or recommended scenarios, leaving the agent to infer usage purely from the tool name.
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 full responsibility for behavioral disclosure. It states the analysis goals but does not reveal whether this is a read-only operation, whether it requires connection details, whether it changes any state, or what the return format 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 a single, well-structured sentence that front-loads the primary action and immediately lists specific outcomes. Every word contributes to understanding the tool's purpose without unnecessary 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?
The tool is relatively specialized yet lacks output schema and annotations. The description does not explain what results are returned, whether the optional database_name is needed, or what assumptions are made about the environment. This is insufficient for an agent to confidently invoke and interpret the tool.
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 one optional parameter (database_name) with 0% description coverage. The description does not mention this parameter or clarify its role in the analysis. The parameter name is somewhat self-explanatory, but the description adds no value beyond the 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 uses a specific verb ('Analyze') tied to a clear resource ('ORM query performance') and explicitly names the concrete outcomes: detecting N+1 problems and lazy loading issues. This distinguishes it well from sibling tools like general query analyzers or index-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like orm_index_coverage, orm_performance_baseline, or explain_query. The description implies it is for ORM-specific performance issues but does not state exclusions or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It does add that the search is 'across schemas', which is useful, but it does not explain pattern syntax (e.g., SQL LIKE vs regex), case sensitivity, whether the search is exact or partial, or return format/pagination. These are significant behavioral aspects not covered.
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, direct sentence that front-loads the primary action and scope. Every word contributes to meaning, with no filler or repetition. It is appropriately concise for the tool's purpose.
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 moderate complexity (5 parameters, no output schema, varied object types), the description is incomplete. It lacks details on pattern matching behavior, allowed object types, return structure, and relationship to the database_name parameter. The description does not provide enough context for an agent to use the tool effectively without additional assumptions.
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% over 5 parameters, and the description provides no explicit parameter information. It hints at pattern and schemas, but does not explain limit, object_types, or database_name. The description fails to compensate for the schema's lack of descriptions, leaving parameter semantics largely unexplained.
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 'Find' and names the exact resources ('tables, columns, functions, views') along with the search mechanism ('by name pattern') and scope ('across schemas'). This clearly distinguishes it from sibling tools like list_objects or list_schemas, which likely enumerate rather than search by pattern.
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 when to use the tool: when you need to locate objects by name pattern across schemas. However, it does not explicitly state when not to use it or mention alternatives such as list_objects or describe_table. The context of 'by name pattern' gives a clear use case, but no explicit exclusions or comparisons 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 present, so the description carries the full burden. It mentions 'List' (implying read-only) and PostgreSQL 12+, but lacks details about permissions, side effects, or output behavior. The dependency monitoring is vague.
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, compact sentence that front-loads the action and target. Every word earns its place, with no fluff or redundancy.
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 listing tool, the description is adequate but leaves gaps: it does not explain parameter usage, return format, or whether all filters are optional (they are). The version note is useful, but more context would improve selection confidence.
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 says nothing about the parameters (table, schema, database_name). Parameter names are self-explanatory, but the description adds no meaning about how they are used together or whether any are required.
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 specific action ('List') and resource ('generated columns'), and adds a distinguishing detail ('monitor their dependencies') plus PostgreSQL 12+ compatibility. This makes it easy to differentiate from sibling tools like list_indexes or describe_table.
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 gives no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It implies usage for generated columns but does not explicitly state when to prefer it over similar introspection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'List indexes for a table or schema' only conveys a basic read operation without details on output format, whether both table and schema are required, or any side effects. No safety or prerequisite information is provided.
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, front-loaded sentence with no filler words. It is efficient and easy to scan, though it omits details that might be expected for clarity. Structure is good, but the brevity borders on under-specification.
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?
The tool has three parameters, no annotations, and no output schema, so the description must be richer to be complete. It does not explain return values, parameter semantics, or when to use with schema vs table. This is inadequate for guiding an agent to invoke the tool 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%, so the description must compensate. It adds the notion that indexes are listed 'for a table or schema', which hints at the roles of `table` and `schema`, but it does not clarify the relationship between these parameters or the purpose of `database_name`. This is insufficient for the three-parameter 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 'List indexes for a table or schema' clearly states the action (list) and the resource (indexes) with scope options (table or schema). This distinguishes it from sibling tools like list_objects and list_schemas, which target different resources.
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 when indexes need to be listed, but provides no explicit guidance on when to use this tool over alternatives such as index_dedup or orm_index_coverage. No exclusionary criteria or alternative tools 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?
No annotations are provided, so the description carries the full transparency burden. The verb 'Show' indicates a read-only operation and the mention of warnings adds some insight, but it does not disclose permissions, blocking behavior, or how warnings are determined. This is partial but not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states what the tool does without any filler or repetition. Every word contributes to the core meaning, making it 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 must compensate by covering parameters and usage context. It only provides a high-level summary, leaving out critical details about parameters and when to use this tool, making it incomplete for effective invocation.
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%, and the description gives no explanation for any of the three parameters (group_by, database_name, include_queries). Since the schema itself only provides types/enums without descriptive labels, the tool would be difficult to invoke correctly.
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 specifies the tool's function with a strong verb ('Show') and a precise resource ('active database connections'), including specific outputs like utilization and idle-in-transaction warnings. This sets it apart from sibling tools such as connection_leak or transaction_monitor.
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 inspecting current connection state but provides no explicit guidance on when to prefer it over alternatives like connection_leak or transaction_monitor. There are no stated exclusions or comparative context, so usage is only implicit.
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 for behavioral transparency. It indicates the tool analyzes and recommends, but it does not disclose whether it modifies anything, whether it requires special permissions, what side effects it might have (e.g., running heavy queries), or what the return value looks like. This level of detail is insufficient for an agent to fully understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's core purpose. It contains no filler or redundant information, making it optimally structured and front-loaded.
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?
The tool has 3 optional parameters and no output schema, so the description needs to explain the return value and any prerequisites. It only states the high-level action, leaving out what the analysis produces (e.g., a list of recommended indexes, DDL statements) and whether the tool can operate without specifying a table. The description is too minimal to be considered complete.
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 does not mention any of the parameters (table, schema, database_name). While the parameter names are self-explanatory, the description fails to explain how these parameters affect the analysis or whether they are required. It does not 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.
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: 'Analyze JSONB columns and recommend GIN indexes for better performance.' It uses a specific verb ('analyze'), specifies the resource ('JSONB columns'), and the outcome ('recommend GIN indexes'), which distinguishes it from sibling tools like list_indexes or index_dedup.
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 analyzing JSONB columns to get GIN index recommendations, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention any alternatives. The context is clear but lacks exclusions or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It suggests a read-only analysis ('Analyze... recommend') but doesn't explicitly confirm it won't modify data, nor does it describe output format, side effects, or access requirements. This is a notable 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, well-structured sentence that front-loads the core action and outcome. Every word contributes to understanding the tool's purpose, with no filler or repetition.
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 absence of annotations, output schema, and parameter descriptions, the description is too thin. It doesn't explain what the analysis returns, what the parameters do, or whether any prerequisites exist (e.g., needing ORM entities in the schema). More context is needed for a complete understanding.
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 explain the parameters. It doesn't address 'schema' or 'database_name' beyond their names, which are only partially self-explanatory. The tool description provides no additional meaning about what values should be passed or how they influence the analysis.
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 ('Analyze'), targets a clear resource ('index coverage for ORM @Query annotations'), and states the outcome ('recommend missing indexes'). This clearly distinguishes it from siblings like list_indexes or index_dedup.
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 the tool is for analyzing ORM query index coverage, but it doesn't explicitly state when to use this over alternatives like list_indexes or orm_performance. No exclusions or alternative tools are mentioned, so the guidance is only implicit.
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 indicates a read-only monitoring operation but omits details such as whether the user needs special privileges, whether only currently running operations are shown, or what progress metrics (e.g., percentages, command type) are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the exact operation types without any filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should explain what the tool returns, but it does not. It also does not clarify the role of database_name, leaving the agent to infer whether the report is global or filtered and what the result structure looks like.
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 one optional parameter, database_name, but the description does not mention it. With 0% schema description coverage, the tool description adds no meaning beyond what the parameter name itself suggests, failing to explain how this parameter affects the progress report.
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 function with a specific verb ('Monitor') and resource ('progress of VACUUM, ANALYZE, CLUSTER, and CREATE INDEX operations'). This explicitly distinguishes it from sibling monitoring tools like autovacuum_advisor or transaction_monitor.
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 when to use the tool (when monitoring maintenance operation progress), but it does not provide explicit guidance on when not to use it, prerequisites, or alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions monitoring and detection but does not state whether it is read-only, what data it returns, whether it requires special permissions, or if it provides a snapshot versus continuous monitoring. This is a significant transparency 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 sentence with no fluff. It efficiently conveys the core action without unnecessary words, 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 output schema and annotations, the description should compensate by explaining expected results and parameter usage. It does neither, leaving the agent uncertain about what the tool returns and how database_name influences the outcome. This is incomplete for even a simple tool.
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 single parameter database_name is not mentioned in the description, and the schema provides only validation constraints (pattern, maxLength). With 0% schema description coverage, the description was expected to explain how the parameter affects behavior (e.g., filtering by database, default when omitted), but it does not.
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 monitors active transactions, isolation levels, and detects long-running transactions. This distinguishes it from sibling tools like get_slow_queries (queries) and deadlock_analysis (deadlocks), making the purpose specific and unambiguous.
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 use for transaction health monitoring but provides no explicit guidance on when to use this tool versus alternatives like get_connections or deadlock_analysis. It lacks 'use this when...' or 'instead of...' statements, so usage context is only implied.
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. While 'Identify' suggests a read-only operation, it does not explicitly state that, nor does it disclose any side effects, performance implications, or what output to expect. Only the PostgreSQL 13+ prerequisite is mentioned.
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 concise sentence, front-loaded with the main action and resource. No wasted 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?
Given the tool's apparent simplicity and the absence of an output schema, the description still leaves gaps: it does not describe the result format, nor does it clarify parameter usage. It is serviceable but not complete for an agent to know exactly what to expect.
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 does not explain what the parameters (table, schema, database_name) do or how they affect the results. The parameter names are self-explanatory, but the tool does not clarify whether they are filters, required, or how they interact (e.g., if table is specified without 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: identifying B-tree indexes that can benefit from deduplication. It distinguishes itself from siblings like list_indexes by specifying the exact analysis (deduplication benefit) and the PostgreSQL version requirement.
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 using it when you want to find deduplication opportunities for B-tree indexes, but it lacks explicit guidance on when not to use it or alternatives. No mention of 'use list_indexes for simple listing' or other exclusions.
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 burden of explaining side effects. 'Analyze' suggests read-only, but 'recommend' is ambiguous: does it only produce recommendations or also create indexes? It does not disclose permissions needed or whether any changes are made.
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, focused sentence that is front-loaded with the action and resource. No redundant information or 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?
The tool has no output schema, so the description should outline what the return value looks like. It says 'recommend GIN indexes' but does not specify the format (e.g., list, DDL, report) or any required database privileges. Given the tool's specialized scope, more detail about the output would improve completeness.
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 coverage is 0%, so the description must compensate. It does not explain the purpose of the 'schema' and 'database_name' parameters, nor how they affect the analysis. The parameter names are somewhat self-explanatory, but the description adds no detail beyond the 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 uses a specific verb ('Analyze') and identifies a clear resource and outcome: JSONB columns with @Convert entity attributes, recommending GIN indexes. This differentiates it from sibling tools like jsonb_analysis by focusing on JPA @Convert mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context via 'for @Convert entity attributes' but does not explicitly state when to use this over alternatives like jsonb_analysis or jpa_mapping. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for disclosing behavior. 'List' implies a read-only operation, but there is no mention of whether schema existence is checked, permissions required, or what the output format is. No side effects or edge cases are disclosed, leaving significant behavioral uncertainty.
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, concise sentence that immediately conveys the core functionality. It is front-loaded with the verb and resource, with no superfluous words. Perfectly sized for a straightforward listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is notably incomplete. It does not describe what the returned data contains (e.g., just names or full metadata), how errors are handled, or the role of database_name. For a tool with three parameters and no structured metadata, it should provide more 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?
The description adds some meaning beyond the schema: it mentions the types of objects (matching the enum for 'type') and the schema context, which clarifies the purpose of the 'schema' parameter. However, the 'database_name' parameter is not mentioned, and the enum values are already present in the schema. With 0% schema coverage, the description partially compensates but not fully.
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 ('List') and specifies the resource ('tables, views, or functions in a schema'), clearly distinguishing it from sibling tools like list_schemas or list_indexes. The scope (in a schema) and the object types are explicitly stated, leaving no ambiguity about what the tool does.
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: when you need to enumerate tables, views, or functions within a schema. However, it does not explicitly state when to prefer this tool over alternatives (e.g., search_objects or describe_table), nor does it mention any exclusions or prerequisites. The context is clear but lacks explicit 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 of behavioral disclosure. It describes the purpose but does not disclose whether the tool is read-only, requires specific permissions, or has side effects. For a tracking/validation tool, the read-only nature is not explicit, leaving the agent uncertain about safety.
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, focused sentence that front-loads the core function and lists concrete capabilities. No unnecessary words or repetition.
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 has one optional parameter and no output schema, so the description should provide more context about expected behavior and results. It explains the high-level purpose but omits details like what 'track' returns, whether it only reads history, or how drift detection works. This is a moderate gap for such a simple tool.
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 description does not mention the 'database_name' parameter at all. The schema defines it with a pattern and maxLength, but the description adds no meaning about how it affects migration tracking. With 0% schema description coverage, the description should compensate, but it does not.
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 function with specific verbs: 'Track Flyway/Liquibase migrations, detect schema drift, and validate checksums.' It identifies the resource (migrations) and distinctive capabilities, distinguishing it from sibling tools like query or describe_table.
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 migration tracking and drift detection but does not explicitly state when to use this tool versus alternatives like jpa_schema_validation or other validation tools. No alternatives or exclusions are mentioned, so guidance is only implied.
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's use of 'recommend' hints that the tool does not apply changes, but it does not explicitly state read-only behavior, input requirements, or output format. This leaves uncertainty about whether it modifies settings or just reports.
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 concise sentence that front-loads the primary action. Every word is purposeful, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, yet the description does not explain what the analysis returns, whether it requires a live database, or what 'tuning settings' means. This is underspecified for an agent to invoke confidently.
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 description does not mention the table, schema, or database_name parameters, all of which are optional. With 0% schema coverage, the description fails to clarify how these parameters scope the analysis, so an agent gets no added meaning beyond parameter names.
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 the verb 'analyze' with resources 'autovacuum effectiveness' and 'tuning settings', clearly identifying the tool's function. It distinguishes itself from siblings like query or list_objects by focusing on autovacuum tuning.
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?
No explicit guidance is provided about when to use this tool versus alternatives. The description implies usage for autovacuum tuning scenarios, but does not mention prerequisites or cases where other diagnostic tools 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.
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 what is monitored (publications, subscriptions, lag) and the PG version requirement, but does not explicitly state whether the tool is read-only, what permissions are needed, or what exact output format is returned. This is a moderate gap for a monitoring 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 packs in the core purpose, resource, and specific details (publications, subscriptions, lag, PostgreSQL 13+). It is concise, front-loaded, and contains no wasted 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?
Given the simplicity of the tool (one optional parameter, no annotations, no output schema), the description provides the essential purpose but is incomplete regarding return values, parameter usage, and behavioral safety (e.g., read-only nature). This leaves some ambiguity for an agent deciding how to invoke and interpret the tool.
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?
The schema description coverage is 0% for the single parameter (database_name), and the description does not mention it at all. There is no added meaning beyond the parameter name and schema constraints, so the description fails 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.
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 a specific verb ('Monitor') and a specific resource ('logical replication'), listing concrete aspects (publications, subscriptions, lag). It also specifies the PostgreSQL version range, which distinguishes it from related tools like wal_monitor or progress_report.
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 by naming logical replication and its metrics, which implies when to use it (e.g., when checking logical replication health) without explicitly naming alternatives. It does not explicitly exclude physical replication tools, but the scope is sufficiently clear for typical use.
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-server MCP server](https://glama.ai/mcp/servers/irsyadjpp/postgres-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/irsyadjpp/postgres-mcp-server)

Score Badge

Copy to your README.md:

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

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