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

Lists specific checks performed (nulls, duplicates, gaps, coverage, freshness), which adds behavioral context. However, lacks disclosure on side effects (read-only?), permissions, or rate limits. No annotations provided to compensate.

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?

Concise and well-structured: first lists high-level checks, then provides parameter details. Every sentence is informative 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?

Covers purpose and parameters well, but does not describe the output schema or how results are presented. Given output schema exists, this is a minor gap.

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 has 0% description coverage, but the description's 'Args:' section fully explains each parameter (table, database, check_date) with defaults and purpose, greatly enhancing clarity.

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?

Clearly states it runs data quality checks on a specific date, listing exact checks (nulls, duplicates, gaps, coverage). Distinguishes from sibling tools like ch_query or ch_disk_usage.

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?

Implicitly clear when to use (for data quality checks), but lacks explicit when-not or alternative tools. Still, the specialized nature makes usage obvious.

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?

No annotations are provided, so the description must fully disclose behavior. It lists specific outputs (total usage, per-table breakdown, etc.) and implies it is a read-only analysis (no side effects mentioned). However, it does not explicitly state that it does not modify data or require special permissions. The description is adequate but leaves some ambiguity.

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 very concise, with a clear separation between the action statement, return values, and parameters. Every sentence adds value, and the bullet list for returns is easy to parse. No unnecessary 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 (disk usage analysis with multiple outputs) and the presence of an output schema, the description covers the main points: total usage, per-table and per-partition breakdowns, TTL info, and recommendations. It does not explain edge cases or detailed interpretation of recommendations, but these may be handled by the output schema. Overall, it is sufficient for its purpose.

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?

The single parameter 'database' is fully described in the Args section, including its purpose and default value. This adds meaning beyond the input schema, which has no parameter descriptions (schema coverage 0%). The explanation is clear and 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 analyzes disk usage by table and partition with recommendations. It specifies a concrete verb ('analyze') and resource ('disk usage'), which distinguishes it from sibling tools like ch_data_quality or ch_query. However, it could be more explicit about the scope (e.g., 'of the ClickHouse database').

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 no guidance on when to use this tool vs. alternatives (e.g., ch_list_tables or ch_slow_queries). It does not mention prerequisites, configuration, or contexts where other tools would be preferred.

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?

No annotations are provided, so the description carries full burden. It describes the non-destructive analysis behavior (running explains) and enumerates specific outputs (partition pruning, sorting keys, suggestions). It does not mention prerequisites, rate limits, or error handling, but the tool is inherently safe.

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 has a logical structure: a concise opening, a bullet list of analysis features, a differentiating statement, and an Args section. While the bullet list adds clarity, it could be more streamlined. Overall, it is efficient and 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?

The description covers key outputs (partition pruning, sorting keys, optimization suggestions) for a tool of this complexity. The presence of an output schema reduces the need to explain return values. It omits failure scenarios but is otherwise complete for its intended use.

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 0% schema description coverage, the description compensates by explaining the 'sql' parameter as a SELECT query and 'database' with a default value and purpose ('cdc_pipeline'). This adds meaningful context beyond the schema's type and title.

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 a query's execution plan and suggests optimizations. It explicitly mentions running EXPLAIN PLAN and EXPLAIN PIPELINE, and differentiates from generic tools by providing advisory rather than execution.

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 explains what the tool does and contrasts with generic ClickHouse tools, implying use for optimization. However, it does not explicitly state when to use it versus siblings like ch_query or ch_slow_queries, nor does it provide when-not-to-use guidance.

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?

No annotations are provided, so the description carries full burden. It discloses the return fields (row count, disk size, descriptions) but does not mention any side effects, permissions, or performance considerations, which is a gap for a read-only list tool.

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 very concise: three sentences plus an Args line. No redundant information, and the purpose is 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?

The description covers the output fields well and provides context for usage. With an output schema present (not shown), the description completes the picture. However, it lacks mention of pagination or limits if there are many tables.

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?

The input schema has 0% description coverage, but the description provides the parameter name and default value ('database: Database to list (default: cdc_pipeline)'). This adds basic meaning beyond the schema, though it could include more details like valid database names or format.

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 lists all tables with metadata and built-in descriptions, and positions it as a starting point. This distinguishes it from sibling ch_table_schema which likely focuses on a single table's schema.

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 advises to use this as a starting point to understand available data, implying it should be used before querying specific tables. However, it lacks explicit exclusions or comparison with alternatives like ch_table_schema.

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?

No annotations are provided, so the description carries the full burden. It details the measured metrics (p50, p95, p99, max, freshness) and segments, but does not explicitly state that the tool is read-only. The behavioral impact is well-described, but a safety statement would improve transparency.

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 a summary sentence followed by detailed lists. It is concise and front-loaded, with no wasted words, though it could be slightly more compact.

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?

The description covers the key output metrics and segments. Since an output schema exists, the return values are defined there. It lacks mention of error conditions or limits, but is adequate for a monitoring 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?

Schema coverage is 0%, but the description compensates with clear explanations for both parameters, including examples and defaults. It adds significant meaning beyond the schema's property names.

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 'Analyze CDC pipeline latency by segment', providing a specific verb and resource. It lists the segments and metrics, distinguishing this tool from siblings like ch_data_quality and ch_query, which serve different purposes.

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

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

The description implies usage for latency monitoring but does not explicitly state when not to use it or provide alternatives. However, the clear scope and sibling context make it evident when to select this tool.

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?

With no annotations, the description carries full burden. It discloses automatic safety validation, LIMIT enforcement, partition pruning analysis, and a warning for inefficient queries. It also specifies default values for database and max_rows. Could mention error handling or performance implications.

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

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

The description is concise and well-structured: a brief purpose statement, a paragraph of key features, and a clear Args section. 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 output schema exists, the description adequately covers query execution, validation, and limits. It could be more complete by summarizing the response format, but the main aspects are covered.

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?

Parameter descriptions add value beyond the bare schema: 'SELECT query to execute' for sql, target database with default for database, and maximum rows with default and max for max_rows. This compensates for the 0% schema description 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 'Execute a read-only SQL query against ClickHouse', specifying the verb (execute), resource (ClickHouse), and nature (read-only). It distinguishes itself from potential write operations by emphasizing 'read-only' and 'SELECT 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 explicitly limits usage to SELECT queries with automatic safety validation blocking DDL/DML, and mentions LIMIT enforcement. It does not explicitly compare with sibling tools like ch_explain_query or ch_table_schema, but provides clear context on when to use this tool for general querying.

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?

With no annotations, the description indicates it scans system.query_log (a read operation) and generates diagnoses, but does not explicitly confirm it is read-only or discuss potential side effects, authorization, or performance impact. Adequate but incomplete.

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?

Well-structured with a clear title, diagnostic bullet list, and Args section. Slightly verbose; could trim redundant phrasing while preserving info.

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?

Covers main functionality and diagnostics, but omits edge cases, error handling, and output details (though output schema exists). Adequate for the tool complexity.

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?

Input schema has 0% description coverage, but the description's Args section adds meaning for all three parameters (hours, min_duration_ms, limit) with defaults and brief explanations. Lacks full detail on constraints or interactions.

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 finds slow queries with root cause diagnosis, listing specific diagnostic types (full scan, memory, aggregation, error detection). This distinguishes it from siblings like ch_query (general query) and ch_explain_query (plan 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 implies use for performance troubleshooting but does not explicitly state when to use it versus alternatives like ch_explain_query or ch_pipeline_latency. No exclusions or specific conditions are 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?

No annotations are provided, so the description carries the full burden. It clearly lists what the tool returns (column types, partition keys, row counts, disk usage, sample rows), implying it is a read-only operation. It does not mention any side effects or authorization requirements, which would be beneficial but is not critical for this read-like tool.

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 concise with three sentences plus an Arg list. It front-loads the main purpose, then lists specifics, and ends with the parameters. Every sentence adds value, and the structure is 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 that there is an output schema (indicated by context), the description sufficiently covers the tool's functionality and return values (e.g., column types, partition keys, sample rows). It includes enough detail for an agent to understand when and how to use it effectively.

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?

The input schema has no descriptions (0% coverage), but the description adds an 'Args' section explaining 'table: Table name' and 'database: Database name (default: cdc_pipeline)'. This provides meaning beyond the bare schema definitions and clarifies the default for the optional parameter.

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 tool is explicitly described as getting comprehensive table metadata, listing specific items like columns, engine, keys, and sample data. It is distinct from sibling tools like ch_list_tables (list tables) and ch_query (run queries), which deal with table listing and data retrieval respectively.

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 states it is 'Essential for understanding table structure before writing queries,' providing clear context for use. It also notes the default database. However, it does not explicitly mention when not to use it or point to alternatives for other schema-related tasks.

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