MCP PostgreSQL Operations

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have clear descriptions but significant overlap exists in monitoring areas. For example, get_autovacuum_activity, get_autovacuum_status, get_vacuum_analyze_stats, and get_vacuum_effectiveness_analysis all focus on vacuum operations with subtle distinctions that could confuse agents. Similarly, multiple I/O and statistics tools (get_io_stats, get_table_io_stats, get_index_io_stats, get_database_stats) have overlapping purposes despite targeting different objects.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with 'get_' prefix, making them predictable and readable. The naming convention is uniformly applied across all 34 tools, with clear descriptive names that indicate their purpose (e.g., get_table_bloat_analysis, get_replication_status).
Tool Count2/5
34 tools is excessive for a PostgreSQL monitoring server, creating cognitive overload. While PostgreSQL has many monitoring aspects, the tool set feels bloated with redundant tools (e.g., four vacuum-related tools) and could be consolidated. A more focused set of 15-20 tools would better serve the domain.
Completeness4/5
The tool set provides comprehensive monitoring coverage for PostgreSQL administration, including connections, performance, replication, vacuum, bloat, and configuration. Minor gaps exist in areas like session management (e.g., no tool for session termination) and real-time query execution, but core monitoring workflows are well-covered.
Average 4.6/5 across 34 of 34 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on April 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 states this is a read operation ('Returns') which implies it's non-destructive, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error conditions, or what happens when parameters are invalid. The description is minimal and doesn't provide the behavioral context needed for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: a purpose statement followed by parameter documentation. It's front-loaded with the core functionality. Every sentence earns its place, though the parameter documentation could be slightly more integrated rather than a separate 'Args:' section.
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 has an output schema (which handles return values), 2 parameters with 0% schema coverage, no annotations, and moderate complexity, the description is minimally adequate. It covers purpose and parameters but lacks behavioral context and usage guidance. The existence of an output schema reduces the burden, but more context about the template structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters in the Args section. It clarifies that 'section' accepts section numbers or keywords, and 'mode' accepts 'full', 'headings', or None. This adds meaningful semantics beyond the bare schema, though it doesn't provide examples or explain what 'headings' mode returns versus 'full'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('MCP prompt template'), and specifies what can be returned (full, headings, or specific section). It distinguishes itself from sibling tools which are all PostgreSQL monitoring tools, making this a specialized template retrieval function. However, it doesn't explicitly contrast with any similar template-related tools since none exist among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or contrast with other tools (though sibling tools are unrelated PostgreSQL monitoring functions, so no direct alternatives exist). The parameter documentation implies usage scenarios but doesn't explicitly state when to choose specific parameter values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It effectively communicates that this is a read-only analysis tool (implied by 'retrieve', 'analyze', 'provide' and prohibited deletion/configuration cases). It describes the return format (table-format information sorted by size) and scope (all databases in PostgreSQL server). However, it doesn't mention potential limitations like performance impact on large servers or authentication requirements.
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 uses clear section headers ([Tool Purpose], [Exact Functionality], etc.) which provides good structure. However, some sections are redundant (the 'Returns' section largely repeats what's in 'Exact Functionality'). The description could be more concise by eliminating repetition while maintaining the valuable usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, but has an output schema, the description provides good context. It explains what the tool does, when to use it, what it returns, and what it doesn't do. The output schema existence means the description doesn't need to detail return value structure. For a read-only analysis tool with no parameters, this description covers the essential context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline would be 4. The description appropriately doesn't waste space discussing non-existent parameters. It focuses instead on what the tool does with its zero-parameter interface, which is the correct approach for a parameterless tool.
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 explicitly states the tool's purpose as analyzing size information and storage usage status of all databases in PostgreSQL server. It distinguishes itself from siblings like get_database_list (which lists databases without size info) and get_table_size_info (which focuses on tables rather than databases). The description uses specific verbs like 'retrieve', 'analyze', and 'provide' with clear resources (disk usage, storage usage, database list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Required Use Cases' section listing specific scenarios (user requests for database size, capacity management, resource usage identification) and 'Strictly Prohibited Use Cases' section clearly stating what this tool should NOT be used for (deletion, configuration changes, backup/restore). This gives clear when-to-use and when-not-to-use guidance, distinguishing it from potential alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining what the tool does (analyzes I/O statistics, identifies performance issues, helps optimization) and what it doesn't do (no optimization actions, configuration changes, or statistics reset). It could improve by mentioning if this is a read-only operation or has any side effects, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.) and front-loaded with purpose. While somewhat verbose, every sentence adds value (use cases, prohibitions, parameter explanations) and there's no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's analytical nature, 2 parameters, no annotations, but with an output schema (confirmed by context signals), the description is complete: it explains purpose, functionality, use cases, prohibitions, parameters, and return values. The output schema handles return format details, so the description appropriately focuses on context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining both parameters in the Args section: 'database_name: Database name to analyze (uses default database if omitted)' and 'schema_name: Schema name to filter (default: public)'. This adds meaning beyond the bare schema, though it doesn't provide format examples or constraints.
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 explicitly states the tool's purpose as 'Analyze I/O performance statistics for indexes (disk reads vs buffer cache hits)' with specific verbs ('analyze', 'show', 'identify', 'provide', 'help optimize') and clearly distinguishes it from siblings like get_table_io_stats (index vs table focus) and get_index_usage_stats (I/O performance vs usage patterns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with '[Required Use Cases]' listing four specific scenarios and '[Strictly Prohibited Use Cases]' listing three clear exclusions, giving comprehensive when-to-use and when-not-to-use instructions that help differentiate from potential alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as the tool's analytical nature (not for optimization actions), the types of statistics shown (heap, index, TOAST), and performance analysis capabilities. However, it doesn't mention potential limitations like data freshness, permissions required, or rate limits, which would be useful for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.), making it easy to parse. It's appropriately sized with no redundant information. However, some sections like '[Exact Functionality]' could be more concise, as bullet points like 'Calculate buffer hit ratios for performance analysis' and 'Identify tables with poor buffer cache performance' overlap slightly in intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (analytical tool with no annotations), the description is complete. It covers purpose, functionality, usage guidelines, parameters, and return values. With an output schema present, the description doesn't need to detail return values, and it adequately explains what the tool does and when to use it, making it sufficient for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the parameters in the 'Args' section: 'database_name: Database name to analyze (uses default database if omitted)' and 'schema_name: Schema name to filter (default: public)'. This adds meaning beyond the bare schema, clarifying defaults and usage. However, it doesn't provide additional context like valid values or constraints.
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 explicitly states the tool's purpose in the '[Tool Purpose]' section: 'Analyze I/O performance statistics for tables (disk reads vs buffer cache hits)'. It provides a specific verb ('Analyze') and resource ('I/O performance statistics for tables'), and distinguishes from siblings like 'get_index_io_stats' by focusing on tables rather than indexes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes '[Required Use Cases]' with specific scenarios (e.g., 'When user requests "table I/O stats"', 'When analyzing table-level I/O performance') and '[Strictly Prohibited Use Cases]' with clear exclusions (e.g., 'Requests for I/O optimization actions', 'Requests for buffer cache configuration changes'). This provides explicit guidance on when to use this tool versus alternatives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly describes what the tool returns (table-format information with specific columns) and its read-only nature (prohibited use cases exclude creation/deletion). However, it doesn't mention potential limitations like server load impact, timeout behavior, or authentication requirements.
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 uses clear section headers but contains some redundancy (e.g., 'Retrieve list of all databases' appears twice). The 'Returns' section repeats information already implied in the 'Exact Functionality' section. While well-structured, it could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, has an output schema (mentioned in context signals), and the description comprehensively covers purpose, usage guidelines, return format, and behavioral constraints, it provides complete context for a read-only listing tool. The existence of an output schema means the description doesn't need to detail return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the schema fully documents the empty input structure.
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 explicitly states the tool's purpose as 'Retrieve list of all databases and their basic information on PostgreSQL server' with specific details about what information is included (owner, encoding, size, connection limit). It clearly distinguishes from sibling tools like get_table_list or get_database_schema_info by focusing only on database-level metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (when user requests database list, needs to check existing databases, or needs size/owner info) and 'Strictly Prohibited Use Cases' (requests for tables/schemas inside databases, creation/deletion operations, or permission/security requests). This gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses behavioral traits: it's a read-only operation (implied by 'Get' and prohibited modification cases), returns comprehensive metrics (listed in detail), and includes scope limitations (database-wide vs. table-specific). However, it doesn't mention potential performance impact or authentication requirements.
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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.), but it's verbose with redundant information. For example, the 'Returns' section repeats what's in [Exact Functionality]. Some sentences could be more concise while maintaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (database statistics), the description is complete: it explains purpose, detailed functionality, specific use cases, prohibitions, and return values. With an output schema present, it doesn't need to detail return format, and the schema coverage is 100% for 0 parameters, so no gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on functionality and use cases. A baseline of 4 is applied since there are no parameters to document.
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 explicitly states the tool's purpose as 'Get comprehensive database-wide statistics and performance metrics' with a clear verb ('Get') and resource ('database-wide statistics and performance metrics'). It distinguishes from siblings like get_table_io_stats or get_index_io_stats by emphasizing 'database-wide' scope, making the distinction clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' with specific query examples ('database statistics', 'database performance', etc.) and analysis scenarios. It also includes 'Strictly Prohibited Use Cases' that clearly state when NOT to use this tool (e.g., for statistics reset or configuration changes), offering clear alternatives by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a monitoring/read-only tool (implied by 'monitor', 'show', 'display'), provides real-time status, and explicitly prohibits write/control operations. However, it doesn't mention potential rate limits, authentication needs, or what happens if no operations are running.
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 uses clear section headers ([Tool Purpose], [Exact Functionality], etc.) which aids structure, but it's verbose with some redundancy (e.g., 'Returns' section repeats functionality). Some sentences could be more concise while maintaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's monitoring purpose, single optional parameter, and presence of an output schema, the description is complete enough. It covers purpose, functionality, use cases, prohibitions, parameter meaning, and return value description. The output schema existence means the description doesn't need to detail return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the single parameter's semantics: 'Target database name (shows operations in all databases if omitted)'. This adds crucial context beyond the schema's basic type information, though it doesn't specify format constraints or examples.
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 explicitly states the tool's purpose as 'Monitor currently running VACUUM and ANALYZE operations in real-time' with specific verbs (monitor, show, display, identify, provide) and resources (VACUUM, ANALYZE, REINDEX operations). It clearly distinguishes from sibling tools like 'get_vacuum_analyze_stats' by focusing on real-time active operations rather than historical statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (e.g., when user requests running VACUUM, troubleshooting slow operations) and 'Strictly Prohibited Use Cases' (e.g., terminating processes, starting new operations). This gives clear guidance on when to use this tool versus alternatives, though it doesn't explicitly name sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing behavioral traits: it specifies the tool retrieves and analyzes information (read-only operation), provides sorted output, and explicitly prohibits destructive operations like deletion or structural changes. However, it doesn't mention potential rate limits, authentication needs, or performance impact.
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 well-structured with labeled sections (Tool Purpose, Exact Functionality, etc.), but it includes redundant elements like 'Args:' and 'Returns:' that repeat information from other sections. Some sentences could be more concise, but overall it's organized and front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has output schema), the description is complete: it covers purpose, functionality, usage guidelines, prohibitions, parameters, and return values. The output schema existence means the description doesn't need to detail return format, and it adequately addresses all necessary context for a read-only analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'schema_name' is the 'Schema name to analyze' with a default of 'public', and 'database_name' is 'Database name to analyze' with a default if omitted. This adds meaningful context beyond the bare schema, though it doesn't detail format constraints or validation rules.
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 explicitly states the tool's purpose as 'Analyze size information and index usage of all tables in specified schema' with specific verbs (retrieve, analyze, provide) and resources (tables, schema). It clearly distinguishes from siblings like get_table_list (lists tables) or get_table_io_stats (I/O statistics) by focusing on size and index analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'Required Use Cases' (e.g., when user requests 'table size', 'schema capacity') and 'Strictly Prohibited Use Cases' (e.g., table data deletion, index creation/deletion). This provides clear guidance on when to use this tool versus alternatives, including what it should not be used for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by specifying what information is returned (PID, username, database name, client address, status, current query) and clarifying it's a read-only monitoring tool (prohibited use cases exclude destructive operations). However, it doesn't mention potential limitations like data freshness, permission requirements, or rate limits, which would be helpful 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 uses clear section headers ([Tool Purpose], [Exact Functionality], etc.) and is front-loaded with purpose. While slightly verbose due to the structured format, every sentence adds value (e.g., prohibited use cases prevent misuse). Minor trimming of redundant phrasing could improve efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (monitoring active connections), no annotations, 0 parameters, and an output schema exists, the description is complete. It explains purpose, functionality, use cases, prohibitions, and return information, providing all necessary context for an agent to understand when and how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's functionality and use cases, which adds value beyond the empty 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 explicitly states the tool's purpose as 'Retrieve all active connections and session information on current PostgreSQL server' with specific verbs ('retrieve', 'display', 'include') and resources ('active connections', 'session information'). It clearly distinguishes from sibling tools by focusing on connection monitoring rather than table stats, replication, or other PostgreSQL metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (e.g., 'When user requests active connections', 'When server load or performance problem diagnosis is needed') and 'Strictly Prohibited Use Cases' (e.g., 'Requests for forceful connection termination', 'Requests for detailed query history of specific sessions'). This gives clear guidance on when to use this tool versus alternatives or when to avoid it entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing behavioral traits: it's a monitoring/analysis tool (not for control/modification), specifies time period defaults and limits (24h default, max 168h, limit 1-100), and mentions environmental dependency (POSTGRES_DB env var). It doesn't cover rate limits or auth needs, but provides substantial context.
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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.), but somewhat verbose with repetitive phrasing ('autovacuum' appears 15 times). Each sentence earns its place, but could be more concise while maintaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, analysis functionality), no annotations, and an output schema exists (so return values needn't be explained), the description is complete. It covers purpose, usage, exclusions, parameters, and behavioral context adequately for the agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all 4 parameters: database_name (target database with env var fallback), schema_name (scope with default behavior), hours_back (time period with default and max), and limit (range and default). It adds crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('monitor', 'track', 'analyze', 'show', 'calculate', 'identify') and resources ('autovacuum and autoanalyze activity patterns and execution history'). It distinguishes from sibling tools like 'get_autovacuum_status' by focusing on patterns and history rather than current status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Required Use Cases' (e.g., monitoring performance, troubleshooting scheduling) and 'Strictly Prohibited Use Cases' (e.g., process control, configuration modifications). It clearly defines when to use this tool versus alternatives for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior as a read-only operation (implied by 'Get information'), specifies it provides connection context, and clarifies it uses a default connection if no database_name is provided. However, it doesn't mention potential rate limits, error conditions, or authentication requirements, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.) and front-loaded key information. It's appropriately sized for the tool's complexity, with no redundant sentences. A minor point: the 'Args' and 'Returns' sections are somewhat redundant with the structured fields, but they're brief and integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter), no annotations, but with an output schema (which handles return values), the description is complete. It covers purpose, usage guidelines, behavioral aspects, and parameter semantics adequately, providing all necessary context for an AI agent to use the tool correctly without over-explaining.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter beyond the schema (which has 0% coverage). It explains that database_name is optional ('uses default connection if omitted') and specifies it's the 'Target database to get info for,' clarifying its role. This compensates well for the low schema coverage, though it doesn't detail format constraints (e.g., string requirements).
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 explicitly states the tool's purpose as 'Get information about the current database connection' with specific details about what information is retrieved (name, encoding, locale, size, connection context). It clearly distinguishes from siblings like get_database_list (which lists databases) or get_database_schema_info (which provides schema details) by focusing on the current connection's metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with '[Required Use Cases]' (e.g., when user asks about current database, clarifying context, troubleshooting) and '[Strictly Prohibited Use Cases]' (e.g., structure changes, authentication, configuration modifications). This clearly defines when to use this tool versus alternatives, including exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's read-only nature by prohibiting maintenance/cleanup operations and specifying it provides 'overview' and 'summary' data. However, it doesn't mention potential performance impacts, data freshness, or authentication requirements, leaving some behavioral aspects uncovered.
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 uses clear section headers ([Tool Purpose], [Exact Functionality], etc.) making it well-structured and easy to parse. While somewhat lengthy, each section adds value (purpose, functionality, usage guidelines, parameters, returns) without redundant information. The front-loaded purpose statement immediately clarifies the tool's intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (database analysis with 2 parameters), no annotations, but with an output schema mentioned, the description provides comprehensive coverage: clear purpose, detailed functionality, explicit usage guidelines, parameter explanations, and return value description. The output schema existence means the description doesn't need to detail return structure, making this complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters, the description compensates well by explaining both parameters: 'database_name' specifies the target database with fallback to environment variable, and 'limit' defines the maximum schemas to show with range and default. This adds meaningful context beyond the basic schema, though it doesn't detail format constraints for database_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 explicitly states the tool's purpose as 'Provide database-wide bloat overview and summary statistics' and details specific functionalities like summarizing bloat statistics, identifying high-bloat schemas/tables, calculating total bloat size, and showing aggregate dead tuple counts. This clearly distinguishes it from sibling tools like 'get_table_bloat_analysis' which focuses on individual tables rather than database-wide overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a '[Required Use Cases]' section listing specific scenarios (e.g., user requests for 'database bloat overview', planning maintenance, investigating performance issues) and a '[Strictly Prohibited Use Cases]' section explicitly stating when NOT to use it (e.g., automatic maintenance, bloat cleanup, restructuring). This provides clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by listing what information is retrieved (schemas, owners, permissions, statistics, objects) and clarifying it's for analysis/exploration only, not for data retrieval or DDL operations. However, it doesn't mention potential limitations like performance impact or authentication 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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.), making it easy to parse. While slightly verbose, each section adds value (e.g., prohibited use cases prevent misuse). Minor trimming could improve efficiency without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (schema analysis with multiple facets), no annotations, and an output schema present, the description is highly complete. It covers purpose, functionality, use cases, prohibitions, parameter semantics, and return value overview, providing all necessary context for an agent to use the tool correctly without needing to infer behavior from sparse structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context for both parameters: database_name is 'REQUIRED - specify which database to analyze' and schema_name 'if None, shows all schemas'. This clarifies usage beyond the basic schema types, though it doesn't detail format constraints or examples.
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 explicitly states the tool retrieves detailed information about database schemas and their contents, specifying verb ('retrieve') and resource ('database schemas'). It clearly distinguishes from sibling tools like get_table_schema_info by emphasizing schema-level analysis rather than table details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Required Use Cases' (e.g., when user requests 'database schema info') and 'Strictly Prohibited Use Cases' (e.g., requests for actual data inside tables). It names a specific alternative tool (get_table_schema_info) for table details, offering clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's functionality ('analyze usage frequency', 'identify unused indexes', 'provide scan count and tuple return statistics'), scope ('all indexes in database'), and limitations (prohibited use cases). However, it doesn't mention potential performance impact, permissions required, or data freshness, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.) and front-loaded key information. However, some sections like 'Exact Functionality' could be more concise, and the overall length is moderate but not minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing index usage), no annotations, and the presence of an output schema (which handles return values), the description is complete. It covers purpose, functionality, use cases, prohibitions, parameters, and returns, providing sufficient context for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaningful context for the single parameter by explaining 'database_name: Database name to analyze (uses default database if omitted)', clarifying the optional nature and default behavior. This goes beyond the basic schema information, though it doesn't detail format constraints or examples.
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 explicitly states the tool's purpose as 'Analyze usage rate and performance statistics of all indexes in database' with specific verbs ('analyze', 'identify', 'provide') and resources ('indexes', 'database'). It clearly distinguishes from siblings like 'get_index_io_stats' by focusing on usage frequency and efficiency rather than I/O statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Required Use Cases' (e.g., 'When user requests index usage rate', 'When database performance optimization is needed') and 'Strictly Prohibited Use Cases' (e.g., 'Requests for index creation or deletion', 'Requests for index reorganization'). This clearly defines when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining version-dependent behavior (PostgreSQL 16+ vs 12-15), what data is returned (buffer cache efficiency, I/O timing, patterns), and prohibited actions. However, it doesn't mention potential side effects, rate limits, or authentication 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 uses clear section headers ([Tool Purpose], [Exact Functionality], etc.) that make it scannable and front-loaded. While comprehensive, some sections could be more concise; every sentence earns its place by adding specific guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of version-dependent behavior, 2 parameters with no schema descriptions, and the presence of an output schema, the description is remarkably complete. It covers purpose, functionality, usage guidelines, prohibitions, parameters, and return values - providing everything needed for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters in the Args section: 'limit' with its range and default, and 'database_name' as optional target. This adds meaningful context beyond the bare schema, though it could elaborate on database_name implications.
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 explicitly states the tool's purpose as 'Analyze comprehensive I/O statistics across all database operations with version compatibility' in the [Tool Purpose] section. It clearly distinguishes from siblings like get_index_io_stats and get_table_io_stats by specifying it covers 'all database operations' rather than specific components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes both [Required Use Cases] with specific trigger phrases and scenarios, and [Strictly Prohibited Use Cases] that explicitly state when NOT to use this tool. This provides comprehensive guidance on when to select this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it's a read-only monitoring tool (implied by 'retrieve' and 'display'), requires the pg_stat_monitor extension to be installed (a prerequisite), and provides detailed performance information. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections ([Tool Purpose], [Exact Functionality], etc.) and front-loaded key information. Each sentence adds value, such as differentiating from pg_stat_statements and specifying use cases. However, it could be slightly more concise by integrating the 'Args' and 'Returns' details more seamlessly into the main text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (monitoring queries with 2 parameters), no annotations, and an output schema present, the description is complete. It covers purpose, functionality, use cases, prohibitions, parameter semantics, and return information. The output schema handles return values, so the description doesn't need to detail them further, making it adequately comprehensive for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for both parameters: 'limit' is described as 'Number of recent queries to retrieve (default: 20, max: 100)' and 'database_name' as 'Database name to analyze (uses default database if omitted)'. This provides clear context beyond the schema's basic titles, though it doesn't elaborate on format constraints or edge cases.
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 explicitly states the tool's purpose as 'Analyze recently executed queries and detailed monitoring information using pg_stat_monitor extension' with specific verbs ('analyze', 'retrieve', 'display', 'provide') and resources ('queries', 'monitoring information', 'client IP', 'time bucket information'). It clearly distinguishes from sibling tools like 'get_pg_stat_statements_top_queries' by noting it provides 'more detailed monitoring data than pg_stat_statements'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'Required Use Cases' (e.g., when user requests 'recent queries', 'detailed monitoring', 'pg_stat_monitor', etc.) and 'Strictly Prohibited Use Cases' (e.g., when pg_stat_monitor extension is not installed, requests for query execution or data modification). It provides clear when-to-use and when-not-to-use guidance with specific alternatives implied (e.g., avoiding data modification tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (retrieves table lists with metadata), what it doesn't do (prohibited use cases), and the default behavior when database_name is omitted (uses currently connected database). However, it doesn't mention performance characteristics, error conditions, or pagination 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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.) and front-loaded key information. While somewhat verbose with section headers, every sentence adds value and there's no redundant information. The structure helps with quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but has output schema), the description provides comprehensive coverage. It explains purpose, functionality, use cases, prohibitions, parameter semantics, and return format. The output schema exists, so the description doesn't need to detail return values, making this complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clearly explains the single parameter's purpose ('Database name to query') and default behavior ('uses currently connected database if omitted'), adding meaningful context beyond the bare schema. However, it doesn't specify format requirements or constraints for the database_name parameter.
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 explicitly states the tool's purpose as 'Retrieve list of all tables and their information from specified database' with specific details about what information is included (schema, owner, size, table types). It clearly distinguishes this from sibling tools like get_table_schema_info (detailed column info) and get_table_size_info (size only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (table list requests, understanding database structure, needing size/owner info) and 'Strictly Prohibited Use Cases' (data inside tables, structure changes, detailed column info). This gives clear guidance on when to use this tool versus alternatives like get_table_schema_info for column details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as the tool being read-only (implied by 'Retrieve' and prohibitions on data changes), the scope of information returned (column details, constraints, metadata), and exclusions like performance statistics. However, it lacks details on error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections ([Tool Purpose], [Exact Functionality], etc.), making it front-loaded and easy to scan. However, some redundancy exists (e.g., repeating parameter info in the Args section), slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no annotations) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage, parameters, and exclusions, providing sufficient context for an agent to invoke the tool correctly without needing additional explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter's role (e.g., 'database_name: Database name to query (REQUIRED - specify which database to analyze)') and default behaviors (e.g., 'if None, shows all tables'), though it doesn't fully detail constraints or formats beyond the schema's basic types.
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 explicitly states the tool's purpose with specific verbs ('Retrieve detailed schema information') and resources ('specific table or all tables in a database'), distinguishing it from siblings like get_table_list (which lists tables) or get_table_size_info (which focuses on size metrics). The structured sections reinforce this clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Required Use Cases' (e.g., 'When user requests "table schema"') and 'Strictly Prohibited Use Cases' (e.g., 'Requests for actual data inside tables'), including clear alternatives ('use other tools for that'). This directly addresses when to use this tool versus others in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly describes this as a read-only retrieval operation (not creation/deletion), specifies the return format as 'Table-format information', and outlines what information is included. It doesn't mention rate limits, authentication requirements, or pagination behavior, but provides substantial behavioral context.
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 uses clear section headers ([Tool Purpose], [Exact Functionality], etc.) making it easy to scan. While slightly verbose with bullet points, every section adds value and there's no redundant information. The structure helps the agent quickly understand different aspects of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema (which handles return value documentation), the description provides excellent context. It covers purpose, functionality, use cases, prohibitions, and return format. Given the tool's simplicity and the presence of output schema, this description is complete and well-balanced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the schema fully documents the absence of parameters.
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 explicitly states the tool's purpose as 'Retrieve list of all user accounts and permission information on PostgreSQL server' with specific details about what information is included (superuser status, permissions, creation/expiration dates). It clearly distinguishes this from sibling tools like get_database_list or get_table_list by focusing specifically on user accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (user list requests, permission management, security inspection, account status overview) and 'Strictly Prohibited Use Cases' (password information, user creation/deletion, session/activity history). This gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It effectively discloses behavioral traits: it's a read-only analysis tool (implied by 'retrieve', 'provide', 'analyze' without mutation terms), specifies what data it returns (execution times, counts, activity statistics), and clarifies limitations (e.g., no execution or configuration changes). However, it lacks details on rate limits, error handling, or authentication needs, which could be relevant for an 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 well-structured with labeled sections ([Tool Purpose], [Exact Functionality], etc.), making it easy to parse. It's appropriately sized—each sentence adds value, such as detailing functionality and use cases without redundancy. However, it could be slightly more concise by integrating some sections (e.g., merging 'Exact Functionality' with 'Returns').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (analysis of database maintenance stats), the description is complete: it covers purpose, functionality, usage guidelines, parameter semantics, and return values. With an output schema present, the description doesn't need to detail return format, and it adequately addresses gaps from missing annotations (e.g., behavioral transparency). This provides a comprehensive understanding for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no schema descriptions), but the description compensates by explaining the single parameter: 'database_name: Database name to analyze (uses default database if omitted)'. This adds crucial context beyond the schema's basic type/name, clarifying its optional nature and default behavior. Since there's only one parameter, this is sufficient for high utility.
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 explicitly states the tool's purpose as analyzing VACUUM and ANALYZE execution history and statistics per table, using specific verbs ('retrieve', 'provide', 'analyze') and clearly identifying the resource (database tables). It distinguishes itself from siblings like get_running_vacuum_operations (which monitors active operations) and get_vacuum_effectiveness_analysis (which focuses on effectiveness rather than history/statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Required Use Cases' (e.g., when users request 'VACUUM status' or need maintenance overview) and 'Strictly Prohibited Use Cases' (e.g., requests for VACUUM execution or configuration changes). It clearly differentiates when to use this tool versus alternatives, such as avoiding it for active operations or configuration tasks handled by other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is an analysis tool ('analyze', 'calculate', 'show') rather than an execution tool, and explicitly states it works 'without performance impact'. However, it doesn't mention authentication requirements, rate limits, or what specific statistics it accesses, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ([Tool Purpose], [Exact Functionality], [Required Use Cases], [Strictly Prohibited Use Cases], Args, Returns). Each section is focused and adds value. While somewhat detailed, every sentence serves a purpose in clarifying the tool's scope and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's analytical nature, 3 parameters, no annotations, but with an output schema (implied by 'Returns' statement), the description provides comprehensive context. It covers purpose, functionality, usage guidelines, prohibitions, parameter semantics, and return value description. The output schema existence means the description doesn't need to detail return structure, making this complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by providing clear parameter explanations in the Args section. It explains that database_name uses a default from environment variable if omitted, schema_name analyzes all user schemas if omitted, and limit has a range and default. This adds meaningful context beyond the basic schema, though it doesn't explain the format or constraints of database/schema 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 clearly states the tool's purpose as analyzing VACUUM effectiveness and maintenance patterns using existing statistics. It specifies the exact functionality including comparing manual vs autovacuum, analyzing frequency vs activity, identifying suboptimal patterns, calculating efficiency ratios, and showing coverage analysis. This distinguishes it from sibling tools like get_autovacuum_activity or get_vacuum_analyze_stats which focus on different aspects of vacuum operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (e.g., when user requests VACUUM effectiveness, planning schedules, identifying poor patterns) and 'Strictly Prohibited Use Cases' (e.g., requests for VACUUM execution, autovacuum configuration changes, maintenance operation control). This gives clear guidance on when to use this tool versus alternatives that might handle execution or configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by listing what it monitors (e.g., WAL location, archiving status, statistics) and explicitly prohibits write operations. However, it doesn't mention potential side effects like performance impact or data freshness, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Tool Purpose, Exact Functionality, etc.), making it easy to parse. It's appropriately sized for the complexity, but some redundancy exists (e.g., 'Returns' section repeats functionality). Every sentence adds value, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (monitoring WAL status), no annotations, an output schema exists, and 0 parameters, the description is complete. It covers purpose, functionality, use cases, prohibitions, and return values, providing sufficient context for an AI agent to understand and invoke the tool correctly without relying on structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics beyond the schema, but this is appropriate since there are no parameters. A baseline of 4 is applied as it adequately handles the parameter-less case without unnecessary details.
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 explicitly states the tool's purpose as 'Monitor WAL (Write Ahead Log) status and statistics' with a clear verb ('Monitor') and resource ('WAL status and statistics'). It distinguishes from sibling tools by focusing specifically on WAL monitoring rather than connections, tables, replication, or other database metrics, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Required Use Cases' (e.g., when user requests WAL status, diagnosing replication lag) and 'Strictly Prohibited Use Cases' (e.g., WAL configuration changes, manual WAL switching). This clearly defines when to use this tool versus alternatives, though it doesn't name specific sibling tools, the use cases implicitly differentiate it from other monitoring tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (read-only statistical analysis), what it includes (system tables optionally), and what it doesn't do (no modifications, maintenance, or optimizations). However, it doesn't mention potential performance impact, rate limits, or authentication 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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.) and every sentence adds value. However, it could be slightly more concise by combining some of the use case descriptions, and the 'Args' and 'Returns' sections somewhat duplicate information already covered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (comprehensive statistics analysis), no annotations, and the presence of an output schema, the description provides excellent context. It explains purpose, functionality, use cases, prohibitions, parameters, and return values, making it complete enough for an agent to understand when and how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters in detail: 'database_name: Database name to analyze (uses default database if omitted)' and 'include_system: Include system tables in results (default: False)'. This provides clear semantic meaning beyond what the bare schema offers.
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 as 'Get comprehensive statistics for all tables' with specific details about what statistics are included (access statistics, sequential/index scans, tuple operations, live/dead tuple estimates, maintenance history). It distinguishes itself from sibling tools by focusing on comprehensive statistics for all tables rather than specific aspects like bloat analysis, size info, or individual table stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (when user requests all tables stats, analyzing overall usage patterns, investigating maintenance needs, getting database activity overview) and 'Strictly Prohibited Use Cases' (requests for table maintenance operations, statistics reset/modification, optimization actions). This gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by specifying what the tool does (analysis only) and what it doesn't do (no changes, no manual execution). It discloses behavioral constraints like 'analyzes all user schemas if omitted' and default parameter behavior. However, it doesn't mention potential performance impact of the analysis or any rate limits.
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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.), front-loading the purpose, and every sentence earns its place by providing specific guidance or information. No redundant or vague statements are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analysis of autovacuum status with 4 parameters), no annotations, and the presence of an output schema (which handles return values), the description is complete. It covers purpose, functionality, usage guidelines, prohibitions, parameter semantics, and return overview, leaving no significant gaps for the agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all 4 parameters in the Args section, including default behaviors (e.g., 'uses default database from POSTGRES_DB env var if omitted'), filtering logic ('analyzes all user schemas if omitted'), and format details ('SQL LIKE pattern'). It adds meaningful context beyond the bare schema, though it could provide more examples for the table_pattern parameter.
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 explicitly states the tool's purpose as 'Analyze autovacuum configuration and current maintenance status for tables' with specific functionality details like analyzing trigger conditions, calculating dead tuple ratios, and identifying tables needing attention. It clearly distinguishes from sibling tools like 'get_autovacuum_activity' (which likely shows active operations) and 'get_vacuum_effectiveness_analysis' (which likely evaluates past vacuum performance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (e.g., when user requests autovacuum status, planning optimization, troubleshooting) and 'Strictly Prohibited Use Cases' (e.g., configuration changes, manual VACUUM execution, process restart). This gives clear guidance on when to use this tool versus alternatives like configuration modification tools or manual vacuum execution tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does well by describing key behavioral traits: it's a read-only analysis tool (implied by 'show', 'display', 'provide', 'analyze'), it automatically adapts to PostgreSQL version (15+ uses separate checkpointer view), and it returns performance statistics. However, it doesn't mention potential limitations like data freshness, permission requirements, or performance impact of running the tool. With no annotations, this is strong but not perfect.
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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], [Required Use Cases], [Strictly Prohibited Use Cases], Returns). Every sentence earns its place by providing specific guidance or information. Despite being comprehensive, it avoids redundancy and stays focused on helping the agent understand when and how to use this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 0 parameters, no annotations, but does have an output schema, the description provides excellent contextual completeness. It explains what the tool does, when to use it, when not to use it, and what it returns. The output schema will handle the return value details, so the description appropriately focuses on usage context rather than output structure. For a parameterless analysis tool, this description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline would be 4. The description appropriately doesn't waste space discussing parameters that don't exist. It focuses instead on what the tool analyzes and returns, which is the correct approach for a parameterless tool.
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 explicitly states the tool's purpose as 'Analyze background writer and checkpoint performance statistics with version compatibility' in the [Tool Purpose] section. It clearly distinguishes this from sibling tools by specifying it focuses on background writer/checkpoint statistics rather than connections, tables, replication, or other database metrics. The description provides specific verbs ('analyze', 'show', 'display', 'provide') and resources ('background writer', 'checkpoint performance statistics').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes both [Required Use Cases] and [Strictly Prohibited Use Cases] sections that provide explicit guidance. It specifies when to use this tool ('When user requests "checkpoint stats", "bgwriter performance", etc.', 'When analyzing I/O performance', 'When troubleshooting checkpoint-related performance issues') and when not to use it ('Requests for checkpoint execution or configuration changes', 'Requests for background writer parameter modifications', 'Requests for statistics reset'). This clearly distinguishes it from potential alternatives for configuration changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read-only monitoring tool (implied by 'list', 'show', 'diagnose'), shows only current state (not historical data), and returns table-format information. It doesn't mention rate limits, authentication needs, or performance impact, but covers the core functionality well given the annotation gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Tool Purpose, Exact Functionality, etc.), making it easy to scan. It's appropriately sized for a 6-parameter tool with no annotations, though some redundancy exists (e.g., 'Filter results by...' in Exact Functionality and again in Args). Every sentence adds value, but minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 0% schema coverage, no annotations) and the presence of an output schema (implied by 'Returns: Table-format information...'), the description is highly complete. It covers purpose, usage guidelines, behavioral context, parameter semantics, and return format, leaving no significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides a detailed 'Args' section that explains each parameter's purpose (e.g., 'Filter by granted status', 'Filter by specific username'), adding essential meaning beyond the bare schema. This is crucial for the 6 parameters with no 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 explicitly states the tool's purpose in the first line: 'Monitor current locks and potential deadlocks in PostgreSQL.' It provides specific verbs ('list', 'show', 'diagnose', 'filter') and clearly distinguishes this tool from siblings by focusing exclusively on lock monitoring, unlike other tools that handle connections, tables, replication, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes dedicated sections for 'Required Use Cases' (e.g., 'When user requests "lock monitoring", "deadlock check", etc.') and 'Strictly Prohibited Use Cases' (e.g., 'Requests for killing sessions or force-unlocking'), providing explicit guidance on when to use this tool versus alternatives or when to avoid it entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing behavioral traits: it's a read-only analysis tool (implied by 'retrieve' and 'display'), requires pg_stat_statements extension, and specifies what data is returned. It doesn't mention rate limits or authentication requirements, but covers core functionality adequately.
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 structured format with clear sections ([Tool Purpose], [Exact Functionality], etc.) is well-organized and front-loaded. Some sections could be more concise (e.g., 'Required Use Cases' lists could be tighter), but overall it's efficiently structured with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (performance analysis with prerequisites), no annotations, and an output schema exists, the description provides comprehensive context: purpose, functionality, use cases, prohibitions, parameter semantics, and return value explanation. It covers all necessary aspects for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides clear semantic meaning for both parameters: 'limit' specifies number of top queries with default and max values, 'database_name' explains it's optional and uses default if omitted. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose as analyzing top queries based on execution time using pg_stat_statements extension. It clearly distinguishes from siblings by focusing specifically on query performance analysis rather than general database monitoring, connections, or table statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (performance analysis, optimization requests) and 'Strictly Prohibited Use Cases' (when extension not installed, execution/modification requests). It clearly defines when to use this tool versus alternatives, including specific scenarios and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (retrieve and analyze configuration values), what information it displays (current value, description, changeability, restart requirements), and importantly specifies prohibited use cases that reveal behavioral constraints (no modifications, no restarts). The only minor gap is lack of explicit mention about permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ([Tool Purpose], [Exact Functionality], [Required Use Cases], [Strictly Prohibited Use Cases], Args, Returns) and every sentence earns its place. It could be slightly more concise by integrating the Args/Returns into the structured sections rather than as separate elements, but overall it's efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (configuration retrieval with filtering options), no annotations, and the presence of an output schema (which handles return value documentation), the description provides complete context. It covers purpose, functionality, use cases, prohibitions, parameter semantics, and return information - everything needed for an agent to understand and use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (no descriptions in the input schema), the description fully compensates by explaining both parameters in detail: 'config_name: Specific configuration parameter name to retrieve (shows all configs if omitted)' and 'filter_text: Text to filter configuration names or descriptions (optional)'. It provides clear semantics beyond just parameter names, including default behavior when omitted.
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 explicitly states the tool's purpose as 'Retrieve and analyze PostgreSQL server configuration parameter values' with specific verbs ('retrieve', 'analyze') and resource ('PostgreSQL server configuration parameters'). It clearly distinguishes from sibling tools like get_server_info or get_database_stats by focusing specifically on configuration parameters rather than general server information or database statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (when user requests PostgreSQL config, checking specific values, searching for configurations, performance tuning) and 'Strictly Prohibited Use Cases' (configuration changes, restart/reload requests, system-level changes). This gives clear guidance on when to use this tool versus alternatives, including what this tool should NOT be used for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It effectively communicates this is a monitoring/read-only tool (implied by 'Monitor', 'Show', 'Display', 'Provide') and specifies what information is returned. However, it doesn't mention potential limitations like data freshness, permission requirements, or rate limits.
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 uses clear section headers ([Tool Purpose], [Exact Functionality], etc.) to organize information efficiently. Every sentence adds value with no redundancy, and the structure helps the agent quickly understand purpose, functionality, usage guidelines, and returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a monitoring tool with 0 parameters, 100% schema coverage, and an output schema exists, the description provides excellent context. It covers purpose, exact functionality, when to use, when not to use, and what's returned - making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what the tool monitors and returns.
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 explicitly states 'Monitor PostgreSQL replication status and statistics' with specific functionality details like showing replication connections, lag information, WAL processes, and slot information. It clearly distinguishes this tool from sibling monitoring tools by focusing exclusively on replication aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (e.g., when user requests replication status, diagnosing issues) and 'Strictly Prohibited Use Cases' (e.g., configuration changes, slot creation/deletion, failover operations). This gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it retrieves server version, displays connection settings with password masking, verifies accessibility, and checks extension status. It also specifies the return format. However, it doesn't mention potential errors, timeouts, or authentication requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.), front-loaded with the core purpose, and every sentence adds value without redundancy. It efficiently communicates necessary information in a organized manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is complete: it explains purpose, functionality, usage guidelines, prohibitions, and return values. With an output schema handling return details, the description provides all necessary context for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters, focusing instead on functionality and use cases, which is correct for a parameterless tool.
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 explicitly states the tool's purpose as 'Check basic information and connection status of PostgreSQL server' with specific verbs ('retrieve', 'display', 'verify', 'check') and resources ('PostgreSQL server version', 'connection settings', 'server accessibility', 'extensions'). It clearly distinguishes from siblings by focusing on basic server info rather than monitoring, statistics, or configuration details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Required Use Cases' listing specific user requests and scenarios, and 'Strictly Prohibited Use Cases' detailing when NOT to use this tool (e.g., for data queries, performance stats, or admin tasks). It effectively distinguishes from sibling tools that handle those prohibited cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It effectively describes what the tool does (analysis, not modification), output characteristics (bloat ratios, sizes, maintenance recommendations), and operational constraints (filtering via SQL LIKE/ILIKE, sorting by severity). It doesn't mention rate limits, authentication needs, or performance characteristics, but provides substantial behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.) that make it easy to parse. While comprehensive, some sections could be more concise - the [Exact Functionality] uses 6 bullet points where 3-4 might suffice. However, every sentence adds value and the structure helps with quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's analytical complexity, 5 parameters with 0% schema coverage, no annotations, but with an output schema, the description is remarkably complete. It covers purpose, functionality, usage guidelines, parameter semantics, and return value description. The output schema existence means the description doesn't need to detail return structure, allowing it to focus on operational context, which it does thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 5 parameters, the description provides excellent parameter semantics. The Args section clearly explains each parameter's purpose, default values, constraints (e.g., '1-100' for limit), and usage examples (e.g., SQL LIKE pattern examples). This fully compensates for the lack of schema descriptions and adds meaningful context beyond what the bare schema provides.
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 explicitly states the tool's purpose as 'Analyze table bloat based on dead tuple statistics and size information' in the [Tool Purpose] section, which is a specific verb+resource combination. It clearly distinguishes this from sibling tools like get_database_bloat_overview (database-level vs table-level analysis) and get_vacuum_effectiveness_analysis (different analytical focus).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides comprehensive usage guidance with dedicated sections: [Required Use Cases] lists five specific scenarios when to use this tool, and [Strictly Prohibited Use Cases] explicitly states three scenarios when NOT to use it (e.g., 'Requests for automatic VACUUM execution'). This gives clear alternatives (use other tools for those prohibited actions) and context for appropriate application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (analyzes relationships, shows foreign keys, displays dependencies, analyzes inheritance, identifies orphaned tables) and clarifies it's a read-only analysis tool (prohibits 'relationship modifications or DDL operations'). However, it doesn't mention potential limitations like query performance impact or authentication 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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.) and front-loaded key information. While comprehensive, some sections could be more concise (e.g., the bullet points in [Exact Functionality] are slightly repetitive). Every sentence earns its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is complete. It covers purpose, functionality, usage guidelines, parameter semantics, and return value description ('Detailed relationship information including foreign keys, dependencies, and metadata'), leaving no significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description compensates fully by explaining each parameter's purpose in the 'Args' section: 'database_name: Database name to query (REQUIRED - specify which database to analyze)', 'table_name: Specific table name to analyze (if None, shows database-wide relationship overview)', etc. This adds crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose as 'Analyze table relationships including foreign keys, dependencies, and inheritance' with a clear verb ('analyze') and resource ('table relationships'). It distinguishes from siblings like 'get_table_schema_info' or 'get_table_list' by focusing specifically on relationship analysis rather than general schema or listing functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with '[Required Use Cases]' listing specific scenarios (e.g., 'When user requests "table relationships", "foreign keys", "dependencies", etc.') and '[Strictly Prohibited Use Cases]' clearly stating what not to use it for (e.g., 'Requests for actual data inside tables'). It also mentions alternatives ('use other tools for that') for performance statistics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by detailing what the tool does (performance analysis) and what it doesn't do (modification, reset, execution). It clarifies the tool is read-only and diagnostic, though it could add more on behavioral traits like data freshness 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 well-structured with clear sections ([Tool Purpose], [Exact Functionality], etc.), front-loaded key information, and every sentence adds value without redundancy. It's 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.
Completeness5/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, no annotations, and an output schema present, the description is complete. It covers purpose, functionality, usage guidelines, parameters, and returns, providing sufficient context for an agent to invoke it correctly without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates by explaining the 'database_name' parameter as 'Database name to analyze (uses default database if omitted)', adding meaning beyond the bare schema. However, it doesn't detail format constraints or examples.
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 explicitly states the tool's purpose as 'Analyze performance statistics for user-defined functions' and details specific functionalities like execution count, timing statistics, and bottleneck identification. It clearly distinguishes from siblings by focusing on user functions rather than tables, indexes, or database-level metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (e.g., when user requests 'function stats') and 'Strictly Prohibited Use Cases' (e.g., requests for function modification), offering clear guidance on when to use this tool versus alternatives. It helps differentiate from siblings by specifying its niche in function performance analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only analysis tool (not for resolution actions), specifies it's only meaningful on standby servers, and indicates it provides statistics rather than performing operations. However, it doesn't mention potential limitations like data freshness or access permissions.
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 uses clear section headers ([Tool Purpose], [Exact Functionality], etc.) to organize information efficiently. Every sentence adds value with no redundancy. The structure makes it easy to scan while maintaining comprehensive coverage of the tool's capabilities and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (conflict analysis in replica environments), the description provides complete context: purpose, functionality, usage guidelines, prohibitions, parameter semantics, and return value explanation. With an output schema present, the description appropriately focuses on behavioral context rather than return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter, but the description provides excellent parameter semantics in the 'Args' section. It explains that 'database_name' is optional (uses default if omitted) and clarifies its purpose as 'Database name to analyze'. This fully compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose as 'Analyze query conflicts in standby/replica database environments' with specific functionality details like showing conflict statistics by type and diagnosing replication-related performance issues. It clearly distinguishes from siblings by focusing specifically on conflict analysis rather than general monitoring or configuration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Required Use Cases' (e.g., when user requests 'replication conflicts', when analyzing replica server performance) and 'Strictly Prohibited Use Cases' (e.g., requests for conflict resolution actions, replication configuration changes). This gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP-PostgreSQL-Ops MCP server](https://glama.ai/mcp/servers/call518/MCP-PostgreSQL-Ops/badges/card.svg)](https://glama.ai/mcp/servers/call518/MCP-PostgreSQL-Ops)

Score Badge

Copy to your README.md:

[![MCP-PostgreSQL-Ops MCP server](https://glama.ai/mcp/servers/call518/MCP-PostgreSQL-Ops/badges/score.svg)](https://glama.ai/mcp/servers/call518/MCP-PostgreSQL-Ops)

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/call518/MCP-PostgreSQL-Ops'

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