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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effects. The description adds that it returns an execution plan and restricts input to SELECT or WITH queries, which is beyond the annotations. However, it does not describe edge behaviors like failure mode or cluster-specific aspects, though those are minor given the safety profile.

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?

A single sentence that front-loads the core action (return execution plan) and supplies the only necessary constraint (SELECT/WITH). There is no filler or redundant information, making it highly scannable and complete.

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 tool is simple (one required parameter), has an output schema, and is fully covered by annotations (read-only, idempotent, non-destructive). The description provides all essential context for invoking it: what it returns, for what kind of input, and the execution plan format. Nothing obscure remains unexplained.

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 schema description coverage at 0%, the description must compensate. It does so by qualifying that the 'sql' parameter must be a 'SELECT or WITH query' for Impala, which is meaningful semantic guidance beyond the bare schema field type. It could be more explicit about the exact grammar or quoting requirements, but it sufficiently clarifies the expected input.

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 states a specific verb ('Return') and a specific resource ('Impala execution plan (EXPLAIN)'), and narrows the scope to 'SELECT or WITH query'. This clearly distinguishes it from siblings like 'query' (executes a query) and 'get_ddl' (returns DDL), so an agent can tell what the tool does without opening schemas.

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 when to use the tool (when you want an Impala execution plan rather than execution), but it never explicitly says 'use this instead of query when...' or names any sibling alternatives. There are no exclusions or conditions beyond the SELECT/WITH scope, so the guidance is implied rather than explicit.

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 declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description carries a lighter burden. It adds useful context about what the snapshot contains and notes the SHOW HOSTS source, but does not disclose additional behavioral traits such as latency, staleness, or session dependence.

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 a single, compact sentence that front-loads the core concept (cluster snapshot) and then lists specific contents. Every part contributes information 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 zero-parameter signature, rich annotations, and presence of an output schema, the description is sufficiently complete. It tells an agent what data to expect, though it could slightly expand on how the snapshot relates to the active session or cluster state.

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 tool has zero parameters, so there is nothing for the description to clarify beyond the schema. The baseline of 4 applies because no parameter documentation is needed.

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 identifies the tool as a cluster snapshot and enumerates its contents: Impala version, current database, database list, and impalad hosts. This distinguishes it from more narrowly scoped siblings like get_db_list, though it does not explicitly name a sibling or use a strong verb.

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 phrase "Cluster snapshot" implies use when an agent needs a high-level cluster overview rather than a specific resource detail. However, there is no explicit when-to-use or when-not-to-use guidance or mention of alternatives.

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 declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds context about what statistics are included and the SQL command, but it does not disclose any additional behavioral traits such as permission requirements, limitations, or performance characteristics.

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 a single, front-loaded sentence with no filler. Every part adds value: the resource type, the specific statistics returned, and the underlying command.

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 simple read-only tool with two self-explanatory parameters, an output schema, and strong annotations, the description is largely complete. It could be slightly richer by explicitly stating that statistics are reported per column or by noting any table prerequisites, but the current definition is sufficient for correct selection and invocation.

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 0%, and the description does not explain db_name or table_name, their format, or their relationship to the results. The parameter names are self-explanatory enough to avoid a score of 1, but the description adds no parameter-level meaning to compensate for the missing schema descriptions.

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 identifies the resource (column-level statistics) and the specific content returned (distinct values, nulls, max/avg size), and it names the underlying command (SHOW COLUMN STATS). The phrase 'column-level' differentiates this from table-level siblings such as get_table_size, get_table_schema, and get_table_preview.

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 when column-level statistics such as distinct counts, null counts, or size metrics are needed, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling alternatives 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the result is scoped to what the configured Impala user can see, and the optional pattern follows SQL LIKE semantics. This clarifies permission-related behavior and filter behavior not captured elsewhere.

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?

A single sentence that front-loads the action and resource, states the scope, and incorporates the parameter usage. Every word earns its place; there is no redundancy or filler.

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 simple read-only listing tool with one optional parameter, the description covers what the tool does, its scope, and the filter semantics. An output schema exists to define return values, and annotations cover safety and idempotency. Nothing essential is missing for an agent to invoke this tool correctly.

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 0%, so the description must carry the burden for the 'pattern' parameter. It does: it explains the parameter is an optional SQL LIKE pattern, which communicates wildcard semantics implicitly. It doesn't provide concrete examples or mention case sensitivity, but the core meaning is sufficiently conveyed for an agent familiar with SQL.

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 states a specific verb ('List'), a specific resource ('databases'), and a clear scope ('visible to the configured Impala user'). It also mentions an optional filter, making the tool's exact function unambiguous and easily distinguishable from siblings like get_db_table_list or get_table_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 makes the use case clear: when you need to list all databases the current user can see. It does not explicitly name alternatives or exclusions, but the simple, well-defined scope gives the agent enough context to select this tool over table- or schema-focused 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?

With readOnlyHint and idempotentHint already declared, the description adds genuine behavioral context by stating the operation is 'sampled over up to max_tables tables,' implying bounded, approximate work rather than full scans. It also describes the aggregation (rows/files/bytes) so agents know the result is summary-level. It does not discuss auth or rates, but the annotations already cover the safety profile.

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?

A single, front-loaded sentence with no filler; it leads with the core action and packs the key qualifiers (counts, aggregates, sampling bound) efficiently.

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 is sufficient for selecting the tool and understanding the general result shape, especially given the read-only annotations and presence of an output schema. The main gap is the unstated behavior of include_table_stats and absence of any note on how defaults such as max_tables=50 apply, but these are minor for a metadata-summary 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 description coverage is 0%, so the description must carry parameter meaning; it does explain max_tables ('sampled over up to max_tables tables') and implicitly maps db_name to 'a database.' However, it never mentions include_table_stats, its effect, or defaults, leaving one of three parameters under-described.

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 uses the verb 'summarize' with resource 'database' and lists concrete outputs (table/view counts, aggregated rows/files/bytes, sampling bound). This distinguishes it from siblings like get_db_table_list and get_table_size without ambiguity.

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 a database-level overview use case but never explains when to choose it over siblings such as get_db_table_list or get_cluster_overview. There are no explicit when-to-use/when-not-to-use instructions or alternative tool names, so usage must be inferred from the name and content.

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 declare this as read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond those hints: it performs SHOW TABLES IN, uses the server default database when db_name is omitted, and applies SQL LIKE filtering via pattern. This gives the agent accurate expectations without contradicting any annotation.

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 two compact clauses with no filler. The core action is front-loaded, followed immediately by the two parameter behaviors that matter for invoking the tool correctly.

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 simple parameterless-required listing tool, the description covers the essentials: what is listed, which database is used by default, and how filtering works. An output schema is present, so return-value details do not need to be stated in the description.

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 0%, so the description must explain parameter meaning. It does so explicitly for both parameters: db_name selects the database and defaults to the server default database when omitted, while pattern filters using SQL LIKE semantics. This fully compensates for the lack of schema descriptions.

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 uses a specific verb and resource: 'List tables and views of a database', and reinforces it with the actual SQL command 'SHOW TABLES IN db'. This clearly distinguishes it from sibling tools like get_db_list (databases) and get_table_schema (individual table details).

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 gives clear context for when to use the tool: to list tables and views in a database. It also provides practical usage guidance for optional parameters (omit db_name to use the default database; pattern uses SQL LIKE). It does not explicitly name alternatives or exclusion cases, but the context is unambiguous.

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 annotations already establish read-only, idempotent, and non-destructive behavior. The description adds the SHOW CREATE TABLE implementation detail and the included content categories, which is useful but does not disclose permission requirements, error behavior, or output size limits. The strong annotations keep the burden low.

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?

One sentence leads with the action, names the output mechanism, and lists the scope boundaries. Every word earns its place and there is no 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?

For a read-only, idempotent tool with only two conventional string parameters and an output schema present, the description is sufficient to invoke the tool correctly. The full-DDL scope is clear, and the content list removes ambiguity about what 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?

Schema description coverage is 0%, so the description needed to clarify db_name and table_name, but it only describes the output content. The parameter names are conventional and inferable, yet the description itself adds no explicit semantic guidance for either 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 description opens with a specific verb ('Return') and names a concrete resource: the full CREATE TABLE statement via SHOW CREATE TABLE. It then enumerates the content scope (partitions, storage format, properties), which differentiates it from sibling tools like get_table_schema or get_partitions.

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 text implies this tool is for retrieving complete DDL for an existing table, but it does not explicitly say when to prefer get_ddl over get_table_schema, get_partitions, or get_table_comment. There are no exclusion criteria or alternative-routing statements, so usage guidance is only implicit.

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

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

The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the SHOW FUNCTIONS execution model and optional pattern filtering, but does not disclose any additional behavioral nuances such as default-database handling or result 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?

A single, efficient sentence that front-loads the action and resource, includes the SQL equivalent in parentheses, and mentions the optional filter. Every phrase earn its place.

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 tool is simple, the annotations cover safety, and the output schema exists, so the description need not describe return values. The only notable gap is the lack of explicit behavior for missing db_name or pattern defaults, which matters for fully correct invocation.

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 must compensate. It explains that the pattern is a LIKE pattern and that the operation targets a database, which maps to db_name and pattern. However, it does not clarify what happens when db_name is empty or how the default interacts with the parameters.

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 states a specific verb ('List') and a specific resource ('built-in and user-defined functions of a database'), and grounds it in the SQL equivalent (SHOW FUNCTIONS). This clearly distinguishes it from sibling tools about tables, schemas, and DDL.

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?

There is no guidance about when to use this tool versus alternatives, nor any mention of when not to use it. The description simply states what the tool does, leaving usage decisions to the agent.

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, idempotent, non-destructive behavior, and the description adds specific behavioral detail beyond that: it runs a SELECT 1 round-trip and reports server version. There is no contradiction and no misleading implication.

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 a single concise sentence with the primary purpose ('Check Impala connectivity') front-loaded, followed by the precise mechanism and returned information. 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 zero parameters, rich annotations, and an output schema, the description is complete for an agent to understand what this tool does and invoke it correctly. There is no missing behavioral or contextual information.

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 tool has zero parameters, so the baseline is high and the description need not explain parameters. The schema and annotation context cover this dimension fully.

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 names a specific action ('Check Impala connectivity') and a specific resource (Impala), with concrete details on what it does: SELECT 1 round-trip latency and server version. This clearly distinguishes it from sibling metadata/query 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 clearly conveys that this tool is for checking Impala connectivity, which implies when it should be used. It does not explicitly name alternatives or exclusions, but among the sibling tools, none overlap with a health check, so the usage context is adequately clear.

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 annotations already establish readOnly and idempotent behavior, and the description adds useful constraints: the operation is a SHOW-style listing, returns per-partition statistics, and only works on partitioned tables. This goes beyond the structured annotations without contradicting them.

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 a single front-loaded sentence with no filler. Every clause adds information: what is listed, what comes with it, what command backs it, and when it is valid.

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 simple metadata-listing tool with two self-evident parameters, an output schema, and safety annotations already present, the description is sufficient. It conveys the core behavioral constraint (partitioned tables) and return nature (per-partition statistics) without redundant detail.

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 was expected to compensate for parameter meaning, but it only mentions partitions and partitioned tables generically. db_name and table_name are left to the agent to infer from their names; no parameter-level guidance is provided.

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 uses a specific verb and resource ('List partitions') and further specifies 'with per-partition statistics', making the tool's function unambiguous. It also states the SHOW PARTITIONS underlying command, which distinguishes it from other table metadata tools like get_table_schema or get_column_stats.

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?

It gives clear usage context with 'Only valid for partitioned tables', telling the agent when the tool applies and implicitly not to use it for non-partitioned tables. It does not name alternative sibling tools, but the condition is explicit and actionable.

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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds the qualifier 'current', implying session state is live, but does not disclose any additional behavioral traits beyond what annotations provide.

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?

One short sentence with no filler; the action word 'List' leads, and the parenthetical 'SET' adds a useful synonym. Every word carries meaning.

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 has no parameters, has a full annotations block, and an output schema, the one-sentence description is sufficient. An agent has everything needed to invoke it; the output schema covers return value details.

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 tool has zero parameters, so the input schema fully covers parameter semantics. Per the baseline for parameterless tools, the description need not add parameter details.

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 states a specific action ('List') and resource ('current Impala session query options'), and clarifies it corresponds to the SET command. This clearly distinguishes it from sibling tools that operate on database objects, tables, or cluster health.

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 gives no explicit guidance on when to choose this tool over siblings, nor does it mention exclusions. The intended use is implied by the tool name and description, but there is no explicit routing or alternative comparison.

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 establish read-only/idempotent/non-destructive behavior. The description adds useful runtime context: the default backing log, the Impala 4.2+/CDP prerequisite, and the available filters. This is meaningful behavioral information beyond the annotations, though it stops short of detailing ordering or default result behavior.

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 two sentences, front-loads the core behavior and source, and has no filler or repeated schema 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 read-only retrieval tool with an output schema, the description covers the essential operational context: what data is queried, the source and version requirement, and the main filters. Minor gaps such as result ordering and filter semantics do not prevent a capable agent from invoking it correctly.

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 0%, so the description must compensate. It explains the purpose of time_range_hours and min_duration_ms as filters, but does not clarify the limit parameter, whether the filters can be combined, or whether thresholds are inclusive.

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 returns recent/slow queries from a specific Impala log, and the source (sys.impala_query_log) differentiates it from the sibling metadata tools. It lacks an explicit main verb, but the tool name plus resource makes the operation unambiguous.

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 the usage context—querying the Impala workload-management log for slow/recent queries—and names the relevant filter parameters. However, it does not state when to prefer this tool over siblings such as query or explain_query, nor give exclusions.

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 declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that the comment is parsed from SHOW CREATE TABLE, which is useful context beyond the annotations. It does not mention edge cases like missing comments or permission requirements, but the annotation safety profile lowers the burden.

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 a single, focused sentence with no filler. The core behavior and data source are front-loaded, making it easy to scan.

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 simple read-only getter with only two required parameters and an output schema, the description is largely complete. Annotations cover side-effect safety. Minor gaps remain around null-result behavior and error conditions, but they are not blocking for correct invocation.

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 0%, and the description does not explain db_name or table_name. The parameter names are self-explanatory, but the description fails to compensate for the missing schema descriptions, so it adds no meaning beyond the input schema.

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 uses a specific verb ('Return') and a precise resource ('table-level comment'), and clarifies the source ('parsed from SHOW CREATE TABLE'). It is clear, but it does not explicitly differentiate this tool from siblings like get_ddl or get_table_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 gives no guidance on when to use this tool versus alternatives such as get_ddl or get_table_schema. The phrase 'parsed from SHOW CREATE TABLE' hints at its niche, but there is no explicit when-to-use or 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?

Annotations already declare the operation read-only, safe, and idempotent. The description adds a concrete behavioral constraint (n<=1000) and clarifies that only leading rows via a SELECT projection are returned. This is meaningful extra context without contradicting 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 entire description is one focused sentence with the core action front-loaded and a compact parenthetical that defines the SQL behavior and maximum limit. No redundant wording.

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 low-complexity preview tool with an output schema and read-only annotations, the description covers the key operational detail (row cap) and object. It lacks only minor context such as unordered/arbitrary result ordering or explicit guidance to use 'query' for full SQL.

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 partially compensates by explaining table_name's role and the limit constraint (n<=1000). However, the required db_name parameter is not described, leaving the agent to infer it from the parameter name alone.

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 names a specific operation ('Preview the first rows of a table') and specifies its mechanism ('SELECT * ... LIMIT n'). This clearly identifies the resource and behavior, though it does not explicitly contrast the tool with the 'query' sibling.

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?

Usage context is implied by 'Preview' — an agent can infer this is for a quick read-only peek at table data. It does not state when to prefer 'query' or other siblings, nor give exclusions, so guidance remains implicit.

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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds that the output includes partition columns but does not mention error behavior, missing-table handling, or the shape of the returned schema beyond what the output schema already implies.

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 one efficient sentence that front-loads the purpose and uses the parenthetical 'DESCRIBE table' to disambiguate. Every part adds value, and there is no 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?

Given the simple two-parameter schema, a clearly named read operation, and an available output schema, the description supplies sufficient context for a basic call. It is complete enough for selecting the tool, though a small note about parameter semantics would move it to a 5.

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 provides 0% description coverage for db_name and table_name, and the description does not elaborate on these parameters. Their names are reasonably self-explanatory, but for a low-coverage schema, the description should define what db_name and table_name refer to (e.g., catalog/schema/table naming, expected format) and it does not.

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 states a clear verb+resource and enumerates the table metadata contents (column names, data types, comments, partition columns). This differentiates it implicitly from siblings like get_table_comment or get_partitions, though it never names them explicitly.

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?

There is no guidance on when to use this tool versus alternatives such as get_table_preview, get_ddl, or get_table_comment, nor any exclusions or prerequisites. The agent must infer usage from the plain-language description alone.

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 mark the tool as read-only and idempotent; the description adds a valuable behavioral caveat that values are -1 until COMPUTE STATS has been run. This goes beyond structured annotations and gives the agent important context for interpreting results.

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 two terse sentences with no filler. The core output is stated first, followed by a crucial caveat about COMPUTE STATS, making it highly scannable and efficient.

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 tool is simple (two string parameters) and has an output schema, so the description covers the key return values and the -1 caveat. However, it omits any usage context or parameter-level detail, making it minimally adequate rather than fully complete.

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 0% and the description does not explain db_name or table_name at all. The parameter names are self-explanatory, but the description still fails to add any semantic meaning or relationship between the parameters and the statistics being fetched.

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 identifies the tool as returning physical table statistics (row count, file count, total bytes) and cites the underlying command SHOW TABLE STATS. This unambiguously distinguishes it from schema/comment/preview tools, though it does not explicitly name any sibling.

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?

No explicit guidance is given about when to use this tool versus alternatives like get_table_schema or get_table_preview. The description only states what the tool returns, leaving usage context implicit.

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 and idempotentHint, but the description adds concrete behavioral detail: accepted statement families, 'return columns+rows', and the important ALLOW_WRITE_SQL=true caveat that the read-only guarantee is conditional on server configuration. It does not cover error handling or resource limits, but these are secondary given the output schema and 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?

Two dense sentences with the primary action and scope front-loaded, followed by the safety caveat. The parenthesized list of SQL forms is long but earns its place by defining valid input boundaries.

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 two-parameter query tool with rich annotations and an output schema, the description provides the essential behavioral contract including the write-safety caveat. The only notable omission is explicit semantics for max_rows, but the parameter is simple enough that an agent can likely infer it.

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 0%, so the description must carry parameter meaning; it usefully constrains the sql parameter to SELECT/SHOW/DESCRIBE/EXPLAIN/WITH...SELECT/bare SET. However, it never mentions max_rows, leaving the second parameter's row-limiting behavior to inference from its title and default value.

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 specifies a concrete verb and resource: 'Execute a read-only SQL statement ... against Apache Impala'. It enumerates accepted statement forms and states the return shape, clearly distinguishing this general query tool from the specialized get_* siblings and explain_query.

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 allowed SQL statement types and the DDL/DML block provide implicit usage boundaries, so an agent can infer it is meant for ad-hoc read-only queries. However, it never names alternatives or explicitly says when to prefer specialized siblings such as explain_query or get_table_preview.

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