Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond this: it specifies the tool analyzes only user indexes (excluding system ones), requires the pgstattuple extension, and lists the types of statistics returned (leaf page density, fragmentation percentage, empty/deleted pages), which helps the agent understand the tool's scope and prerequisites without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: purpose, scope exclusion, statistics details, use cases, prerequisites, and additional support. It is appropriately sized and front-loaded with key information, though the note about GIN/Hash indexes at the end could be integrated more seamlessly, and some sentences are slightly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (5 parameters, no output schema), the description is mostly complete: it explains the tool's purpose, scope, statistics, use cases, and prerequisites. However, it lacks details on output format (e.g., what the return data looks like) and does not mention performance implications or limitations (e.g., impact on database during analysis), leaving minor gaps in contextual understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema fully documents all five parameters (index_name, table_name, schema_name, min_index_size_gb, min_bloat_percent). The description does not add any parameter-specific details beyond what the schema provides, such as explaining interactions between parameters or usage examples, so it meets the baseline of 3 without compensating for gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes index bloat using pgstatindex, specifies it focuses on user/client indexes while excluding system indexes, and distinguishes it from sibling tools like analyze_table_bloat and get_bloat_summary by its specific focus on index-level analysis rather than table-level or summary-level analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (to identify indexes needing REINDEX, with high fragmentation, or wasting storage) and mentions it supports GIN and Hash indexes via other functions. However, it does not explicitly state when not to use it or directly compare it to alternatives like find_unused_indexes or get_index_recommendations among the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond annotations. While annotations indicate idempotentHint=true and destructiveHint=false, the description clarifies that 'This actually executes the query!' and provides specific warnings about data modification queries. It also explains the tool's approach (EXPLAIN ANALYZE) and what analysis it provides, which annotations don't cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by implementation details, analysis components, and critical warnings. Every sentence adds value: the first states purpose, second explains method, third lists analysis areas, fourth provides crucial safety guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (executes queries, provides performance analysis) and rich annotations, the description is mostly complete. It explains what the tool does, how it works, what it analyzes, and critical safety considerations. The main gap is lack of output format details (no output schema exists), but the description compensates somewhat by listing analysis components.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already documents all 6 parameters thoroughly. The description doesn't add significant parameter-specific information beyond what's in the schema, though it implies the 'query' parameter is central and mentions 'analyze_only=false' (referring to the 'analyze' parameter). Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze a SQL query's execution plan and performance characteristics' with specific details about what it provides (execution plan analysis, timing breakdown, buffer usage, performance issues). It distinguishes from siblings like 'explain_with_indexes' by emphasizing actual execution with EXPLAIN ANALYZE and comprehensive performance analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'For SELECT queries this is safe, but be careful with INSERT/UPDATE/DELETE - use analyze_only=false for those.' This clearly indicates when to use caution and mentions an alternative approach (setting analyze=false) for non-SELECT queries, helping distinguish from read-only analysis tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond this: it warns about performance impact (full table scan on large tables), mentions the need for extension installation, and clarifies scope (excludes system tables). No contradictions with annotations exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, scope, statistics, use cases, prerequisites, and cautions). It's appropriately detailed for a complex tool, though slightly verbose. Every sentence adds value, such as explaining exclusion of system tables and performance considerations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no output schema) and rich annotations, the description is largely complete. It covers purpose, usage, behavioral traits, and context. However, it doesn't detail the output format or example results, which could be helpful since there's no output schema. This minor gap prevents a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema fully documents all 5 parameters. The description adds some semantic context by explaining the purpose of use_approx (for large tables) and the focus on user tables, but it doesn't provide additional parameter details beyond what's in the schema. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes table bloat using the pgstattuple extension, specifying it focuses on user/client tables while excluding system tables. It distinguishes itself from sibling tools like 'get_bloat_summary' or 'get_table_stats' by emphasizing tuple-level statistics and bloat analysis for maintenance decisions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool (for identifying tables needing VACUUM or VACUUM FULL due to bloat) and when to consider alternatives (using pgstattuple_approx for large tables via use_approx=true). It also mentions prerequisites (pgstattuple extension installation) and cautions about full table scans on large tables.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only, non-destructive, and idempotent operations, the description explains what wait events represent (Lock, IO, CPU, Client, Extension) and what insights can be gained (I/O bottlenecks, lock contention patterns, resource saturation). This helps the agent understand the tool's analytical focus and output interpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with the core purpose, adds an important note about scope, then provides explanatory context about wait events and insights. Every sentence adds value without redundancy. The bulleted lists efficiently convey information without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's analytical nature, the absence of an output schema, and comprehensive annotations, the description provides good contextual completeness. It explains what wait events are, what they indicate, and what insights can be derived. However, it doesn't describe the format or structure of the analysis results, which would be helpful since there's no output schema provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage for the single parameter 'active_only', the schema already fully documents this parameter. The description doesn't add any additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze PostgreSQL wait events to identify bottlenecks.' It specifies the resource (PostgreSQL wait events), the verb (analyze), and distinguishes it from siblings by focusing on client backend processes while excluding system background processes. This differentiation from tools like 'get_active_queries' or 'get_slow_queries' is explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: 'to help identify bottlenecks in your application queries.' It explicitly excludes system background processes, which helps differentiate it from general monitoring tools. However, it doesn't name specific alternatives among the sibling tools or provide explicit 'when-not-to-use' guidance beyond the exclusion mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, non-destructive, and idempotent behavior, which the description does not contradict. The description adds valuable context by specifying the exclusion of PostgreSQL system tables from analysis and detailing the aspects analyzed (e.g., lock contention, replication status), which goes beyond the annotations to clarify scope and focus.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, starting with the core purpose, followed by a note on scope, a bulleted list of analyzed aspects, and a summary of the output. Each sentence adds value without redundancy, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a health check tool with no output schema, the description provides a thorough overview of what is analyzed and the output format (health score with breakdown and recommendations). It compensates well for the lack of output schema, though it could benefit from more explicit usage guidelines relative to siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear documentation for both parameters ('include_recommendations' and 'verbose'). The description mentions that the tool 'returns a health score with detailed breakdown and recommendations,' which aligns with the parameters but does not add significant meaning beyond what the schema already provides, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a 'comprehensive database health check' on PostgreSQL, specifying it analyzes user/client tables while excluding system tables. It distinguishes itself from sibling tools like 'get_table_stats' or 'analyze_index_bloat' by covering multiple aspects (e.g., connection statistics, cache ratios, replication) rather than focusing on a single metric.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for overall database monitoring and health assessment, with the note about excluding system tables providing some context. However, it does not explicitly state when to use this tool versus alternatives like 'get_bloat_summary' or 'review_settings', nor does it mention prerequisites or exclusions beyond the table scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only, non-destructive, and idempotent operations, the description clarifies that this tool 'requires HypoPG extension for hypothetical testing' and that it 'returns both the original and hypothetical execution plans for comparison.' This provides important implementation details and output behavior that annotations don't cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured and concise - it starts with the core purpose, explains the unique value proposition, provides clear usage scenarios in bullet points, and ends with what the tool returns. Every sentence adds value with zero wasted words, and it's appropriately front-loaded with the most important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with rich annotations (readOnlyHint, idempotentHint, destructiveHint all specified) and complete schema coverage, the description provides excellent context about the tool's unique capabilities and constraints. The only minor gap is the lack of output schema, but the description does specify what the tool returns ('both the original and hypothetical execution plans'), which partially compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema, though it does provide context about the 'hypothetical_indexes' parameter's purpose ('to test without actually creating them'). This meets the baseline expectation when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('Run EXPLAIN on a query') and resources ('hypothetical indexes'), distinguishing it from siblings like analyze_query or get_index_recommendations. It explicitly mentions the unique capability of testing indexes without creating them, which sets it apart from other analysis tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('to compare execution plans', 'test if a proposed index would be used', 'estimate performance impact'), and it implicitly distinguishes from alternatives by mentioning the HypoPG extension requirement. The sibling tools list shows clear alternatives like analyze_query (without hypothetical testing) and manage_hypothetical_indexes (which likely creates actual indexes).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, non-destructive, and idempotent behavior, which the description does not contradict. The description adds valuable context beyond annotations: it specifies scope limitations (excludes system catalogs, focuses on custom tables), identifies what gets analyzed (zero/few scans, duplicates, overlaps), and lists benefits of acting on results (storage reduction, speed improvements). However, it lacks details on rate limits or exact output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized, with a clear purpose statement upfront, followed by a note on scope, a bulleted list of what it identifies, and a bulleted list of benefits. Every sentence adds value without redundancy, and it is front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 tool with 3 parameters), rich annotations (read-only, idempotent), and no output schema, the description is mostly complete: it covers purpose, scope, what it identifies, and benefits. However, it does not detail the output format or potential limitations (e.g., analysis time, database impact), leaving a minor gap for an agent to fully understand results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters (schema_name, min_size_mb, include_duplicates) with descriptions and defaults. The description does not add further meaning or syntax details for these parameters, such as how 'min_size_mb' affects analysis or examples of schema names. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('find', 'analyzes', 'identifies') and resources ('indexes'), distinguishing it from siblings like 'analyze_index_bloat' or 'get_index_recommendations' by focusing on unused/duplicate detection rather than bloat or recommendations. It explicitly lists what it identifies: indexes with few scans, duplicates, and overlapping indexes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use this tool: for analyzing user/client indexes on custom tables, excluding system catalogs. It implicitly suggests usage for performance optimization (e.g., 'Removing unused indexes can...'), but does not explicitly state when not to use it or name specific alternatives among siblings, such as 'analyze_index_bloat' for different analysis types.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it explains default filtering behavior (excludes system/background processes), specifies what types of queries are shown (active queries, idle transactions, blocked queries, connection states), and mentions the tool's analytical purpose for optimization and troubleshooting. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: the first sentence states the core purpose, followed by a 'Note:' section for important clarifications, a 'Shows:' bullet list for output details, and a 'Useful for:' section for usage context. Every sentence adds value without redundancy, and the bullet points enhance readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (4 parameters, no output schema), the description is largely complete. It explains the tool's purpose, usage guidelines, behavioral traits, and output scope. However, without an output schema, it doesn't detail the exact structure of returned data (e.g., fields, formats), which is a minor gap. The annotations provide safety context, and the description compensates well for the lack of output schema with the 'Shows:' section.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all 4 parameters well-documented in the schema itself. The description doesn't add significant parameter semantics beyond what's in the schema, though it implies the tool's default behavior aligns with parameter defaults (e.g., excluding system processes unless include_system=true). This meets the baseline of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get information about currently active queries and connections.' It specifies the resource (active queries and connections) and distinguishes from siblings like 'get_slow_queries' by focusing on currently running queries rather than historical slow ones. The 'Shows:' section further elaborates on what information is retrieved.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'Useful for: Identifying long-running queries, Finding queries that might need optimization, Detecting stuck transactions, Troubleshooting lock contention.' It also distinguishes from siblings by noting this tool focuses on active queries while tools like 'get_slow_queries' likely focus on historical performance. The 'Note:' section clarifies default exclusions (system processes) and when to include them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond annotations: it discloses the tool's scope limitation (excludes PostgreSQL system objects), technical implementation details (uses pgstattuple_approx and pgstatindex), and prerequisites (requires pgstattuple extension). While annotations cover safety aspects (readOnlyHint, destructiveHint), the description enriches understanding of what the tool actually does and its constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with the core purpose, provides important notes and scope limitations, lists what the tool provides, mentions implementation details, and ends with usage guidance. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the absence of an output schema, the description provides substantial context about what the tool returns (high-level overview with specific categories) and its behavioral characteristics. The annotations cover safety aspects well, and the description adds important operational context, though it could potentially provide more detail about output format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra semantic value for parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('get', 'analyzes', 'provides') and resources ('database bloat across tables and indexes'). It distinguishes from siblings by focusing specifically on comprehensive bloat analysis rather than granular analysis (like analyze_table_bloat or analyze_index_bloat) or other database functions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance with a 'Best for:' section that states 'Quick assessment of database bloat and maintenance priorities.' It also distinguishes from alternatives by noting it analyzes only user/client tables and indexes, excluding system objects, which helps differentiate it from other analysis tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating safe, non-destructive operations. The description adds valuable context beyond annotations: it explains the sophisticated 5-step algorithm, mentions HypoPG testing, and details what factors the recommendations consider (query frequency, improvement estimates, index size, avoiding redundancy).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: purpose statement, algorithm breakdown, scope limitations, and recommendation factors. While comprehensive, it could be slightly more concise by combining some of the numbered algorithm steps into fewer sentences without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (sophisticated algorithm, 5 parameters) and rich annotations, the description provides substantial context about behavior, scope, and methodology. However, without an output schema, it doesn't describe the format or structure of the recommendations returned, which is a minor gap for a recommendation-generating tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already documents all 5 parameters thoroughly. The description doesn't add significant parameter-specific information beyond what's in the schema, though it provides context about workload analysis and table focus that relates to parameters like 'workload_queries' and 'target_tables'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Get AI-powered index recommendations for your database' with specific details about analyzing query workload and recommending indexes to improve performance. It distinguishes from siblings like 'find_unused_indexes' or 'analyze_index_bloat' by focusing on generating new index recommendations rather than analyzing existing ones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool: for analyzing query workload and getting index recommendations. It mentions exclusions (system catalog tables) but doesn't explicitly state when to use alternatives like 'explain_with_indexes' or 'manage_hypothetical_indexes' for specific scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond what annotations provide. While annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds that it 'Requires the pg_stat_statements extension to be enabled' and specifies what types of queries are excluded (system catalog queries). It also details the specific metrics returned, providing important operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by prerequisites, scope limitations, and detailed output information. Every sentence adds value without redundancy. The bulleted list of returned metrics is particularly efficient for conveying complex information clearly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only analysis tool with good annotations but no output schema, the description provides comprehensive context about what the tool does, prerequisites, scope limitations, and detailed output format. The main gap is the lack of output schema, but the description compensates well by explicitly listing all returned metrics with their semantic meaning.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already fully documents all 4 parameters with descriptions, defaults, and constraints. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional semantic context about how parameters interact or affect results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Retrieve slow queries from PostgreSQL using pg_stat_statements' with specific details about what it returns ('top N slowest queries ordered by total execution time'). It distinguishes from siblings like 'get_active_queries' by focusing on historical performance data rather than currently running queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: analyzing slow queries with pg_stat_statements enabled, focusing on user/application queries while excluding system catalog queries. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools for different performance analysis needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond what annotations provide. While annotations already indicate it's read-only, non-destructive, and idempotent, the description adds important details: it analyzes only user-created tables (excluding system tables), focuses on application custom tables, and explains what kind of maintenance issues it helps identify. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with the core purpose, provides important exclusion notes, lists what information is returned, and ends with the practical value. Every sentence adds meaningful information with zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only analysis tool with good annotations and comprehensive input schema, the description provides excellent context about scope (user tables only), output content (specific statistics listed), and practical application (identifying maintenance needs). The main gap is the lack of output schema, but the description compensates by detailing what information is returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description doesn't add significant parameter-specific information beyond what's in the schema, though it does provide context about what tables are analyzed (user-created vs system tables) which relates to the schema_name parameter's usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get detailed statistics for user/client database tables' with specific details about what statistics are returned (table size, row counts, scan ratios, etc.). It distinguishes from sibling tools by focusing on table statistics rather than index analysis, query analysis, or other database health checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: 'This helps identify tables that may need maintenance (VACUUM, ANALYZE) or have performance issues.' It also notes what tables are excluded (system tables). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false, destructiveHint=false, etc., covering basic safety. The description adds valuable behavioral context beyond annotations: it explains that indexes are in-memory only (not persisted), lists specific actions like 'reset' that drop all indexes, and mentions testing scenarios without affecting real indexes. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (overview, actions list, use cases) and avoids redundancy. However, it's moderately lengthy due to enumerating 10 actions and use cases; some sentences could be more condensed while maintaining clarity, slightly affecting efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, multiple actions) and lack of output schema, the description provides comprehensive context on actions and use cases. It compensates well for missing output details by explaining what each action does, though it could briefly mention expected return types or error handling for full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing full parameter documentation. The description adds minimal parameter semantics beyond the schema, mainly by listing actions and their purposes without detailing parameter interactions or constraints. This meets the baseline for high schema coverage but doesn't enhance understanding significantly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages HypoPG hypothetical indexes for testing, specifying it creates in-memory indexes to test query plans without creating real ones. It distinguishes from siblings by focusing on hypothetical index management rather than analysis, recommendations, or real index operations found in tools like 'explain_with_indexes' or 'find_unused_indexes'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists 10 specific actions with their purposes and includes a 'This is useful for' section detailing scenarios like testing query improvements, comparing strategies, and simulating index removal. It provides clear when-to-use guidance by contrasting with real index operations and outlining practical testing contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context about what gets analyzed (specific setting categories) and the comparison methodology (against best practices and system resources), which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement followed by bullet points of analyzed categories and a final sentence explaining the comparison methodology. Every sentence adds value with zero wasted words, and information is appropriately front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (configuration analysis with 2 parameters), rich annotations covering safety and idempotency, and 100% schema coverage, the description is mostly complete. The main gap is the lack of output schema, so the description doesn't explain what the recommendations look like, but it adequately covers the tool's purpose and scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters. The description mentions 'key performance-related settings' and lists categories that map to the enum, but doesn't add significant meaning beyond what's already in the schema descriptions. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('review', 'analyzes', 'compares') and identifies the resource ('PostgreSQL configuration settings'). It distinguishes itself from sibling tools by focusing on configuration analysis rather than query analysis, index management, or performance monitoring.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (analyzing PostgreSQL configuration against best practices) but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The implicit differentiation from siblings is present but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.