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 known. The description adds no additional behavioral context (e.g., performance, limits, side effects of the persist parameter). It does not contradict annotations, but adds minimal extra value 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?

The description is concise: one sentence for purpose, one for usage guidance, and a bulleted list for arguments. Every sentence earns its place with no redundancy or fluff.

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 listing tool with no output schema, the description covers purpose, usage, parameters, and sibling differentiation. It is complete given the tool's complexity and the richness of annotations and schema.

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 coverage is 100% with each parameter already described. The description repeats parameter info in an 'Arguments' list but adds no new meaning. Per rubric, baseline is 3 when schema coverage is high; description does not compensate further.

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-resource combination: 'List the column names, data types, and basic attributes for a single Teradata table or view.' It clearly distinguishes its purpose from the sibling tool base_columnMetadata by specifying what the other tool covers (precise Teradata-specific type codes, character sets, etc.).

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 states when to use this tool ('use for straightforward questions like...') and when not to ('For precise Teradata-specific type codes... use base_columnMetadata instead'). This provides clear guidance on 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 and idempotentHint as true. The description adds substantial behavioral context: resolution paths for tables vs views, native cursor pattern, technical capabilities, and detailed large-scale usage guidance including self-interruption on payload/time budgets and automatic continuation. No contradictions with 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 headings and bullet points, making it easy to scan. However, it is quite lengthy and includes some repetition (e.g., resolution paths mentioned twice). For a complex tool, the length is somewhat justified, but trimming redundant details could improve conciseness.

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 (8 parameters, no output schema), the description covers all necessary aspects: purpose, usage guidance, parameter details, large-scale handling, continuation pattern, and return values. There are no obvious gaps, and the explanation of payload/time budgets and continuation is thorough.

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 provides a full 'Arguments' section explaining each parameter's purpose, default values, and usage examples. For instance, it explains the continuation pattern for object_name, the meaning of table_kind codes (T, O, V, Q), and the effects of max_payload_kb and max_execution_seconds. This adds significant meaning beyond the bare 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 clearly states the tool retrieves detailed technical column metadata for Teradata tables and views, listing specific attributes like type codes, character sets, precision, scale, nullability, and index classification. It explicitly differentiates from the sibling base_columnDescription by noting that tool is for simple column lists, while this one provides precise Teradata-specific information.

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 states when to use this tool ('when the user needs precise Teradata-specific column information') and when not to ('For a simple list of columns and types for a single object, use base_columnDescription instead'). It also provides detailed guidance for large-scale usage, including strategies for payload/time budgets, continuation patterns, and parameter adjustments.

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 and idempotentHint=true, so no contradiction. The description adds no extra behavioral traits beyond those annotations, such as side effects or authorization requirements. Meets minimum but doesn't add value.

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 two clear paragraphs: purpose/usage, then parameters. It is concise but could combine the parameter details into fewer 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?

Missing output schema, and the description only mentions return value when persist=True. For a list tool, the default output format (e.g., list of names) is not described, leaving some ambiguity.

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%, and the tool description repeats the exact same parameter descriptions. It does not add new meaning beyond what the input schema provides, so baseline score of 3 is appropriate.

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 'List all databases or schemas available in the Teradata system' with a specific verb and resource. It distinguishes from sibling tools like base_tableList by focusing on databases/schemas, not tables.

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?

Explicitly states when to call (only when user asks about databases/schemas) and when not to (not as preliminary step for table listing), with alternative guidance to ask user for the database name. This is exemplary usage direction.

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 and idempotentHint. The description adds value by explaining behavior on truncation (truncated flag, how to get more rows), the effect of persist (volatile table), and row limit details. It does not contradict 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 and front-loaded purpose. While it is relatively long, every sentence adds value. Minor redundancy (e.g., repeating truncation handling) could be trimmed, but overall it is efficient and organized.

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 (SQL execution) and that the schema has no descriptions and no output schema, the description covers all critical aspects: parameter semantics, return metadata (truncated, row_limit, volatile_table), and guidance for large result sets. It is complete for an AI agent to invoke 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?

Despite the schema having 0% description coverage, the description fully explains all three parameters: sql (required, full SQL text), persist (boolean, recommended for large results), and row_limit (default 1000, ceiling 50000). It adds essential meaning beyond the 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 clearly states it executes a user-provided SQL query against Teradata and returns results. It explicitly distinguishes from base_tablePreview by saying not to use for browsing/sampling rows, making the purpose unambiguous and well-differentiated.

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 states when to use (when user supplies explicit SQL statement or filter conditions) and when not to (use base_tablePreview for browsing/sampling). It also provides guidance on persist and row_limit parameters, giving clear context for tool selection.

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 states the tool saves a file on disk, which is a write operation, but annotations declare readOnlyHint=true and idempotentHint=true. This is a direct contradiction, severely misleading the agent about the tool's side effects.

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: it starts with purpose, then provides explicit usage guidelines, then lists arguments with descriptions, and ends with a mention of the return type. 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?

The description covers purpose, usage, and parameters adequately given the lack of output schema. However, the contradiction with annotations undermines completeness, as the agent cannot trust the behavioral description. Additionally, the return format is vaguely described.

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%, but the description provides clear explanations for all four parameters, including examples, defaults, and acceptable values for object_type. It adds significant meaning beyond the schema, though lacks details like format constraints.

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 extracts DDL for Teradata objects and saves it as a .sql file. It distinguishes from sibling base_tableDDL which displays DDL without saving. The verb 'save' and resource 'DDL' are specific.

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 tells the agent when to use this tool: only when the user wants to export, write, download, or persist DDL. It also specifies when NOT to use it and directs to base_tableDDL for display purposes. This is excellent 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 declare readOnlyHint and idempotentHint, which the description does not contradict. The description adds context about the persist parameter materializing a volatile table, which clarifies a behavioral nuance beyond 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?

Description is extremely concise: two sentences for purpose and usage, then a bulleted parameter list. Every sentence is informative with no redundancy. Front-loaded with main purpose.

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?

While annotations and schema cover safety and parameters, the description lacks detail on the output format (e.g., list of table pairs, scores). For a tool with no output schema, more return value description would be helpful.

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 100% with descriptions for each parameter. The description's 'Arguments' section essentially repeats the schema descriptions without adding new meaning, so baseline score of 3 applies.

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?

Description clearly states the tool identifies tables that co-occur in SQL queries, revealing JOIN relationships and affinity patterns. It differentiates from sibling base_tableUsage by specifying this tool is for co-occurrence, not access frequency.

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?

Explicit usage guidance: use when user asks about tables queried together, related tables, or common workflow tables. Provides clear alternative: use base_tableUsage for access frequency or query counts.

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 readOnly and idempotent. Description adds behavior of the persist parameter (materializes as volatile table, returns table name), which is beyond what annotations capture. No contradictions.

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 purpose first, then usage guidelines, then argument list. Every sentence adds necessary information. Not 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?

Despite no output schema, description explains what DDL is returned and the effect of persist. For a retrieval tool, this is sufficient. Guidance on parameter requirements completes the context.

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 baseline is 3. Description adds value by explaining persist more clearly and including usage guidance for table_name and database_name (don't guess).

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 it returns the CREATE TABLE DDL for a Teradata table, including column types, constraints, primary indexes, and keys. It distinguishes from sibling tools like base_columnDescription (column names/types) and base_saveDDL (saving to file).

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?

Explicitly states when to use (user wants CREATE statement/table definition) and when not to (saving DDL, column names). Includes critical instruction to ask for clarification if both table and database names are not provided.

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. The description adds that omitting database_name lists all databases, and the persist parameter materializes the result as a volatile table, returning the table name. This goes beyond 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 front-loaded with the primary purpose and includes a usage note. However, it repeats the parameter descriptions from the schema, which reduces conciseness slightly.

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 the main scenarios (with and without database_name) and explains the persist behavior. Lacks explicit mention of output format (e.g., list of table names with schema), but given no output schema, this is acceptable.

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 provides 100% coverage: both parameters have descriptions. The tool's description repeats these descriptions verbatim, adding no new semantic information beyond what is already in the 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 clearly states it lists tables and views within a Teradata database. It distinguishes the tool from siblings like base_databaseList (which lists databases) and base_tablePreview (which previews a specific table), though it does not explicitly name these alternatives.

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?

Provides explicit guidance: when the user wants a single database, the agent should ask for the database name instead of returning all tables. This prevents accidental broad results. It does not mention when to use alternative tools, but the context is 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?

Description discloses read-only sampling behavior and persist option for materialization, adding context beyond annotations (readOnlyHint, idempotentHint). Does not contradict 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?

Description is front-loaded with purpose, then usage, then parameters. Well-organized but slightly verbose; could be more concise while retaining key 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?

No output schema, but description covers use cases, arguments, and behavioral aspects. Lacks details on return format (e.g., JSON structure), but adequate for a preview 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 100% and description repeats but clarifies parameters (e.g., table_name, database_name, persist). Adds value by explaining purpose beyond schema definitions.

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 a quick sample of first few rows from a table/view without SQL. It distinguishes from sibling base_readQuery by specifying when not to use (WHERE clause, filter, SQL).

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?

Explicitly says when to use (explore/peek without conditions) and when not to use (user provides WHERE clause, filter, or SQL), and suggests alternative base_readQuery.

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 show readOnlyHint=true and idempotentHint=true. The description adds behavioral context beyond annotations, specifying that the tool reports access frequency and per-user patterns, and that setting persist=True materializes a volatile table and returns its name. No contradictions.

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 relatively concise: two sentences for the main purpose and usage, followed by parameter lines. It is front-loaded with the key idea. Slight room for improvement in structuring the parameter details more cleanly, but overall 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?

For a tool with 2 parameters and no output schema, the description covers the purpose, usage context, parameter behavior, and output (access frequency patterns, optionally a table name). It is complete for an agent to understand and invoke 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 100%, so the baseline is 3. The description repeats the schema's parameter explanations (database_name, persist) without adding new semantic meaning. It does not improve over the schema's own 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 states the tool reports 'access frequency and per-user query patterns for tables and views', which is a specific verb+resource. It distinguishes from sibling tool base_tableAffinity by explicitly stating the alternative use case.

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 when-to-use guidance: 'Use when the user asks how often tables are accessed, which tables are most popular, or which users are running queries against a database.' It also includes an explicit alternative (base_tableAffinity) when not to use 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?

Annotations already declare readOnlyHint and idempotentHint, confirming safe read behavior. The description adds context about the persist parameter (materializing as a volatile table) and clarifies the requirement to not pass an empty database name, which is useful 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 concise and well-structured: a primary purpose sentence, usage context, alternative tool references, and clear parameter documentation. No extraneous 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 simple read-only tool with two parameters and no output schema, the description covers purpose, usage guidelines, parameter requirements, and sibling differentiation comprehensively. No gaps are evident.

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 100%, so the schema fully documents both parameters. The description repeats the schema's parameter descriptions without adding new meaning or constraints beyond what is already in the 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 explicitly states 'Show disk space allocation for a specific named Teradata database', providing a specific verb and resource. It clearly distinguishes from sibling tools like dba_tableSpace and dba_systemSpace by mentioning when to use each alternative.

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: use when the user asks about space usage for a particular database, and for alternatives like table-level breakdowns (dba_tableSpace) or system-wide totals (dba_systemSpace). It also instructs to ask for clarification if no database name is provided, preventing misuse.

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 and idempotentHint. The description adds the behavioral detail about the persist parameter materializing results as a volatile table, which is useful context 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 two sentences plus a bullet for the argument, front-loading the purpose and clearly explaining the parameter. Every sentence is concise and purposeful.

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 simplicity of the tool (one boolean parameter, no output schema), the description fully covers what the tool does and the optional persist behavior. No gaps remain.

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 100% and the schema description for persist is nearly identical to the description's explanation. The description adds no significant new meaning, so baseline 3 is appropriate.

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 'Teradata database software version and release information', using a specific verb and resource. This distinguishes it from sibling tools that handle other database metadata.

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?

Explicitly states 'Use when the user asks what version of Teradata is running on the system', providing clear context. It does not list exclusions or alternatives, but given no sibling for version queries, this is sufficient.

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, indicating safe read-only behavior. The description adds that the 'persist' parameter materializes the result as a volatile table and returns the table name, which is non-obvious. No contradictions with 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 succinct: one sentence for purpose/usage, one sentence listing arguments with formats. No unnecessary words, and structure is front-loaded with the primary action.

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?

While the tool has no output schema, the description only mentions return format for the persist case. It does not explain what is returned by default (e.g., a list of features), which is a gap. Additionally, there is no mention of pagination or result limits.

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 100% and each parameter has a description matching the text. The description repeats the schema information without adding new meaning, so it meets the baseline for high coverage but does not exceed it.

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 explicitly states 'Report which Teradata product features were used during a specified date range,' which is a specific verb+resource combination. Among siblings, other dba tools have distinct purposes (e.g., dba_databaseSpace, dba_sessionInfo), so this tool is clearly differentiated.

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 contexts: 'when the user asks about feature adoption, which Teradata capabilities are being used, or how feature utilization has changed.' It does not explicitly mention when not to use it or name alternatives, but the guidance is sufficient for typical use cases.

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 that it shows throttling events with timestamps and magnitude, but does not disclose full output format. No contradictions.

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 front-loaded purpose, usage guidelines, alternative tool mention, and argument list. Every sentence is meaningful, 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?

For a tool with no output schema, the description explains the output as events with timing and magnitude, which is adequate but lacks specifics on returned fields. Overall, it is mostly complete for its low 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 covers all 3 parameters with 100% description coverage. The description restates the same information, adding no new meaning beyond the schema. Baseline score of 3 is appropriate.

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 reports Teradata workload management flow control events, specifying the verb 'Report' and resource. It also distinguishes itself from the sibling tool dba_userDelay by stating when to use each.

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?

Explicitly provides when to use the tool (system throttling, flow control delays) and when not to (individual user waits, recommending dba_userDelay). This is direct and 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?

Annotations already mark readOnlyHint and idempotentHint true, and the description adds behavioral detail about the persist parameter materializing a volatile table. No contradictions.

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?

Purpose and usage guideline are front-loaded. The parameter list is verbose but necessary given 9 parameters. Could be slightly more concise.

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 system-level scope, filtering options, and persist behavior. No output schema, so a brief mention of return structure would be helpful but not essential.

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 description's parameter listing adds little new meaning beyond readability. Baseline 3 is appropriate.

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 'Report' and resource 'system-wide resource consumption (CPU, IO, memory)' and clearly distinguishes from sibling dba_tableUsageImpact by noting it is 'not tied to a specific 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?

Explicitly says 'Use when the user asks for system-level resource breakdowns... not tied to a specific database. For per-database or per-user impact within a named database, use dba_tableUsageImpact instead.' This provides clear context and an alternative.

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 discloses that persist=True materializes the result as a volatile table and returns the table name, adding behavioral context beyond the readOnlyHint and idempotentHint annotations. No contradiction with 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 two concise paragraphs: first explaining purpose and usage context, then listing parameters. Every sentence adds value; 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?

Given two parameters, no output schema, and annotations, the description fully covers the tool's behavior: when to use, parameter semantics, and side effects of persist. An agent can invoke 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 coverage is 100% with descriptions for both parameters. The description adds operational context, e.g., explaining the effect of persist=True and the use of '*' for all users, going beyond the 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 clearly states it reports 'currently active session information' for a specific user or all users, which is a specific verb+resource combination. It distinguishes from sibling tools like dba_databaseSpace or dba_featureUsage by focusing on sessions.

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?

Explicitly says 'Use when the user asks about open connections, active sessions, or currently logged-in users.' Also provides guidance on default behavior with '*' and that no clarification is needed, making it easy for the agent to decide when to invoke.

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 and idempotentHint, so the description does not repeat that. It adds useful context: aggregation over all databases and the behavior of the 'persist' parameter (materializes as volatile table). The description is transparent 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 concise (two paragraphs) and front-loaded with the core purpose. The usage guidelines and argument are clearly separated. Minor repetition of 'across the entire Teradata system' and 'over all databases' but overall 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?

For a simple tool with one optional parameter and no output schema, the description provides sufficient context: what it shows, when to use it, and the effect of the parameter. It does not describe the return format, but the verb 'Show' implies a display or result, which is acceptable.

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?

There is only one parameter ('persist') and its description in the schema matches exactly the description in the text. Since schema_description_coverage is 100%, the description adds no new meaning beyond the schema, earning a baseline score of 3.

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 verb 'Show' and identifies the resource ('total disk space usage across the entire Teradata system, aggregated over all databases'). It also distinguishes from siblings by naming alternative tools for database-level or table-level queries, making the purpose 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?

Explicitly specifies when to use this tool ('warehouse-wide storage, total system capacity, or overall disk consumption across all databases') and provides clear alternatives ('dba_databaseSpace' for single database, 'dba_tableSpace' for table-level details), offering excellent 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 readOnlyHint and idempotentHint. Description adds behavioral details: results are sorted by size and the persist parameter materializes result as a volatile table, returning table name. No contradiction with 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?

Description is well-structured with a clear purpose sentence, usage guidelines, and bulleted arguments. However, the argument list duplicates schema descriptions, making it slightly redundant. Still efficient for 5 parameters.

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 no output schema, the description explains the tool's behavior (ranked space usage) and the persist parameter's effect. It lacks explicit detail on output fields, but the usage scenario is well-covered. Adequate for a query 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 100%, so baseline is 3. The description repeats the same parameter descriptions as the schema, adding no new meaning beyond what is already in the schema's property 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?

Clearly states the tool shows table-level disk space usage within a specific Teradata database, ranked by size. It specifies verb, resource, and context, and distinguishes from sibling tools like dba_databaseSpace and dba_systemSpace.

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?

Explicitly states when to use (user asks for largest tables in a named database) and when not to (empty database_name), provides instruction to ask for database, and names alternatives (dba_databaseSpace for whole database, dba_systemSpace for system-wide).

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 declare readOnlyHint=true and idempotentHint=true, but the description mentions that when persist=True, it 'materializes result as a volatile table and returns table name', which is a write operation. This contradicts the readOnlyHint, misleading the agent. The description itself is transparent, but the contradiction between description and annotations warrants a score of 1 per the scoring rule.

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 front-loaded with purpose and usage, followed by parameter definitions. However, the parameter section is redundant given the schema's full coverage. Every sentence is useful except the parameter list, which could be omitted. Still, it's not excessively long.

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 main purpose, usage, and the persist behavior. However, it does not describe the return format for the normal case (e.g., a list of SQL statements), which would be helpful. The default value for no_days (7) is only in the schema, not mentioned. Overall adequate but slightly incomplete.

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%, and the description's parameter section essentially repeats the schema's descriptions verbatim (e.g., 'Number of days to look back'). It adds no new meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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 'Retrieve SQL statements that have been executed against a specific named table', with a specific verb, resource, and scope. It also differentiates from sibling dba_userSqlList by specifying when to use each.

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?

Provides explicit guidance: only call when user explicitly names a table, otherwise ask for clarification. Also states not to use for user-specific history but to use dba_userSqlList instead.

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 description correctly inherits those traits. Beyond annotations, the description adds behavioral detail for the 'persist' parameter: 'materializes result as a volatile table and returns table name.' This is a valuable side-effect disclosure. However, it does not mention error handling (e.g., if database not found), which would strengthen 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 concise (6 informative sentences) and front-loaded: first sentence states purpose, then usage guidelines, condition, alternative, then parameter details. Every sentence adds value with 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?

Given no output schema, the description should explain the return format (e.g., what columns, how results are presented). It only says 'identify... which users and tables' without specifying structure. Parameter descriptions and usage guidelines are thorough, but the missing output description is a notable gap for a data-retrieval 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 100%, so baseline is 3. The description adds marginal value by emphasizing 'Required — do not pass empty string' for database_name and restating defaults. This extra clarification justifies a 4, but it largely mirrors the 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 clearly states the tool's function: 'Identify which users and tables are driving the most query and resource activity within a specific Teradata database.' It uses a specific verb ('identify'), resource ('users and tables'), and context (specific database). It also distinguishes from sibling tool dba_resusageSummary by directing system-wide queries elsewhere.

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?

Explicitly states when to use: 'when the user asks who is hitting a named database hardest...' and when not to: 'ONLY call when the user has specified a database name — if no database name appears in the message, ask for clarification.' Also provides a clear alternative: 'For system-wide CPU, IO, and memory metrics... use dba_resusageSummary instead.'

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 and idempotentHint true. Description adds no extra behavioral context beyond the basic purpose, such as permissions, rate limits, or side effects. No contradiction, but no added value.

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?

Description is concise with three clear parts: purpose, usage guidance, and argument list. No unnecessary words; front-loaded with the main action.

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?

Provides essential usage context and alternative tool. However, does not describe the default output format (e.g., table, text) beyond mentioning persist materializes a volatile table. Given no output schema, a bit more detail would improve 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%, so parameters are already well-documented. Description does not add new semantics beyond restating 'start_date' and 'end_date' context in the overall purpose. Baseline score of 3 is appropriate.

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?

Description clearly states the tool reports how long Teradata users waited in the query queue. It uses specific verb 'Report' and resource 'user wait times', and distinguishes from sibling tool dba_flowControl by contrasting use cases.

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?

Explicitly advises when to use this tool (user asks about wait times, queue delays) and when to instead use dba_flowControl (system-level throttling). Provides clear alternative.

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, setting a baseline. The description adds value by explaining the persist parameter materializes a volatile table and returns its name, which is a key behavioral detail 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 well-structured with a clear purpose, usage guidelines, and argument list. The argument list is somewhat redundant with the schema, but it is helpful to have in-line. Minor room for improvement by relying more on schema.

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 retrieval tool with good annotations, the description covers purpose, when to use, conditions, and parameters. It does not describe the output format (e.g., fields returned), but this is a minor gap given the tool name and context.

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 baseline is 3. The description's argument list mostly repeats schema details, but it adds context by grouping parameters and emphasizing the required nature of user_name.

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 'Retrieve SQL statements executed by a specific named user', using a specific verb and resource. It explicitly distinguishes from the sibling tool dba_tableSqlList by specifying when to use each.

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 when to use (user asks about a particular user's queries), when not to use (no user name mentioned), and an alternative (dba_tableSqlList for table-specific history). It also warns against empty user_name.

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 declare readOnlyHint=true and idempotentHint=true. The description adds context about performance (1 SQL round-trip instead of 4, in-memory edge sharing) and algorithmic complexity, which is beyond what annotations provide. No contradiction.

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, performance, use cases, parameters, return format, examples). It is slightly lengthy but every part adds value. Front-loaded with the main composite purpose.

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 (6 parameters, no output schema, composite of 4 analyses), the description is comprehensive. It explains the return structure with JSON example, details parameters, and provides multiple example calls. No gaps.

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%, so the description carries full burden. It provides detailed explanations for all 6 parameters, including critical notes (e.g., container_pattern must be string not array), default values, and references to other tools (graph_edgeContractDDL). Examples further clarify 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 explicitly states it is a composite graph analysis combining findRootObjects, connectedComponents, detectCycles, and bfsLevels in a single call. It distinguishes itself from sibling tools like graph_findRootObjects by explaining the efficiency gain of eliminating serial round-trips.

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 provides a dedicated 'Use this for' section listing specific scenarios (full migration readiness, pre-migration analysis, dashboard population, workflows requiring 3+ individual tools). This clearly guides when to use the composite tool versus the individual 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?

The annotations already declare readOnlyHint and idempotentHint. The description adds substantial behavioral context: pure-Python implementation, one SQL round-trip, BFS algorithm details, direction conventions, filter application order, and response structure. No contradictions.

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 long but well-structured with sections, bullet points, and examples. It is front-loaded with purpose and usage guidance. While slightly verbose, every sentence adds value, so conciseness is good.

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?

Despite no output schema, the description includes a full response structure with example fields and explanations. It covers technical implementation, filter order, and behavior for all parameters. For a complex tool with 6 parameters, this is exceptionally 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%, but the description compensates thoroughly. Each parameter is explained with examples, defaults, and detailed semantics (e.g., root_node_list exact FQ names only, direction meanings for max_depth_up/down). This provides full 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: 'Compute BFS shortest-path hop distances from one or more root nodes.' It uses a specific verb and resource, and explicitly distinguishes from the sibling tool graph_traceLineage with a comparative section.

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 a dedicated 'WHEN TO USE THIS TOOL vs graph_traceLineage' section, listing specific use cases and explicitly stating when not to use it. It also advises using graph_findRootObjects first, offering clear guidance on prerequisites.

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 and idempotentHint. The description adds significant behavioral context: 'Pure-Python implementation — no stored procedure required', 'Issues a single SQL SELECT... then performs Union-Find WCC partitioning entirely in the MCP server process.' It also explains what a connected component is, which exceeds annotation information.

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-organized with sections, but it is slightly verbose for the amount of information. Every sentence adds value, though some duplication could be trimmed.

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 (3 parameters, no output schema), the description provides a full return structure with fields for node_details, component_summaries, and summary_stats. It covers all necessary information for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description fully compensates by providing detailed semantics for each parameter: container_pattern format and examples, exclude_objects default and matching logic, edge_repository requirement and pattern. It also includes critical warnings about types (string vs array).

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 'Identify all Weakly Connected Components (WCC) in the dependency graph.' It uses a specific verb ('identify') and specific resource ('dependency graph'), and distinguishes itself from sibling graph tools like graph_bfsLevels and graph_detectCycles by focusing on WCC partitioning.

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 when to use this tool (e.g., 'Understanding graph structure and partitioning', 'Pre-filtering before cycle detection'). It provides clear context and alternatives by implying that other graph tools handle different aspects.

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=true and idempotentHint=true. The description adds significant context: 'Pure-Python implementation — no stored procedure required. Issues a single SQL SELECT... WCC partitioning followed by iterative DFS cycle detection entirely in the MCP server process.' This details internal behavior 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 well-structured with bullet points for use cases and arguments, and a clear output section. It is reasonably concise given the detail needed, though minor redundancy exists (e.g., repeating 'edge_repository' explanation).

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 three parameters and no output schema, the description provides complete coverage: purpose, implementation details, parameter semantics, and a full output schema description with fields and structure. It leaves no major gaps for an agent to misinterpret.

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%, requiring the description to fully explain parameters. It does so thoroughly: container_pattern with examples ('DFJ%', '%WBC%,%StGeo%'), exclude_objects with default, and edge_repository with an example and reference to graph_edgeContractDDL. Each parameter's purpose and format are clearly stated.

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 explicitly states 'Detect circular dependencies (cycles) in the dependency graph,' specifying the verb 'detect' and the resource 'dependency graph.' It distinguishes from sibling tools like graph_connectedComponents and graph_bfsLevels, which serve different graph analysis 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 lists multiple use cases (validating graph integrity, finding circular references, identifying stub-then-replace patterns, debugging topological sort hangs, pre-deployment checks) and explains arguments with examples. It lacks explicit exclusion criteria or alternative tool references, but the provided context is 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?

Annotations declare readOnlyHint=true and idempotentHint=true. The description reinforces by stating 'no database connection required', 'no SQL is executed', and that the conn parameter is accepted but not used. No contradictions, and adds detail about output types and returned fields.

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 sections and bullet points, but somewhat verbose with detailed column lists and full example comments. Every sentence adds value, but could be more concise 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?

The description fully covers the tool's behavior, parameter details, return structure (with output schema listed), and edge cases like the AI-Native shortcut. It is complete enough for an agent to invoke correctly without ambiguity.

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 100%, and the description adds substantial meaning: it explains the purpose of each parameter with examples (e.g., target_database is typically {ProductName}_Semantic), default values, and how output_type affects DDL generation. This goes far beyond the schema's property 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?

Clearly states the tool 'generates DDL for a Graph Edge Contract-conforming table or view', which is a specific verb-resource combination. It distinguishes from siblings by emphasizing no database connection needed and provides a shortcut for AI-Native Data Products, differentiating from other graph 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?

Explicitly says when to use ('generate DDL') and when not ('if working within an AI-Native Data Product, pass that view's name directly'). Also clarifies that the conn parameter is unused for compatibility, and provides a concrete example of alternative usage.

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. The description adds algorithmic detail (identifies objects that appear as sources but never as targets) and explains the query process. It does not mention auth or rate limits, but for a read-only analysis tool, the provided context is sufficient.

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 long and includes some redundancy (e.g., multiple repetitions of the string type requirement). While it is well-structured with sections, it could be more concise 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?

With 5 complex parameters and no output schema, the description covers usage extensively with examples, but lacks detailed specification of the return format beyond 'formatted response with root objects + metadata'. Still, it provides enough context for an agent to understand and invoke the tool correctly.

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

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

Since schema description coverage is 0%, the description carries full burden. It provides exhaustive documentation for all 5 parameters, including wildcard/CSV formatting, whitespace handling, code examples, and critical type warnings. This greatly surpasses minimal compensation.

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 root objects (no upstream dependencies) in specified containers, and explicitly situates it as a starting point for downstream impact analysis. It distinguishes from sibling tools like graph_traceLineage and graph_detectCycles by focusing on foundational data sources.

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 use cases (finding starting points for impact analysis, identifying base tables, etc.) and example queries. However, it does not explicitly state when NOT to use this tool or contrast it with alternatives like graph_traceLineage for downstream tracking.

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 idempotent and read-only, and the description adds valuable behavioral details: hybrid implementation, no stored procedure, only reachable subgraph crosses network, Python deduplication. No contradictions.

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 sections (description, examples, use cases, arguments, returns). It is somewhat lengthy but front-loaded with critical information. Minor redundancy could be trimmed.

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 (7 parameters, no output schema, 0% schema coverage), the description is remarkably complete. It even provides the return structure and edge row fields, leaving no ambiguity.

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?

Despite 0% schema description coverage, the tool description provides thorough explanations for all 7 parameters, including types, defaults, examples, and formats. This fully compensates for the schema gap.

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 object dependencies in Teradata, supporting wildcards and CSV patterns. It distinguishes from sibling tools by focusing on lineage/impact analysis, with specific use cases listed.

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 use cases (impact analysis, lineage tracing, etc.) and provides examples. While it doesn't explicitly say when not to use, the context is clear and helpful.

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 description's statement of reading directly from a table aligns and adds no contradiction. It adds a behavioral constraint (do not use base_readQuery) which provides additional guidance beyond 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?

Well-structured with clear purpose, usage notes, and parameter descriptions. Each sentence adds value. Slightly verbose with repeated parameter descriptions across description and schema, but overall 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?

Covers purpose, usage guidelines, parameter semantics, and returns. Since there is no output schema, the return type (dict) is mentioned. Could be more specific about return format, but sufficient for an agent to invoke 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 coverage is 100%, so baseline is 3. The description adds context by specifying that labels is typically date/time and columns are numeric, but much of the parameter info is repeated from the 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 clearly states it generates a line chart from a Teradata table, specifies the source type (table), and explicitly distinguishes from siblings (plot_pie_chart, plot_polar_chart, plot_radar_chart) and from base_readQuery.

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?

Provides explicit usage context: time-series, trend lines, sequential data. Includes clear 'do not use' conditions: proportional breakdowns (use pie/polar) and multi-dimensional spider comparisons (use radar). Also instructs not to pre-fetch with base_readQuery.

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 and idempotentHint are true. The description adds important context that the tool reads directly from Teradata without pre-fetching, reinforcing safety. However, it could briefly mention that no data modification occurs.

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 reasonably concise but repeats parameter details that are also in the schema. It could be slightly tighter, but the structure is effective with purpose, usage, and parameter explanation in one paragraph.

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 essential aspects for a simple 3-parameter tool: purpose, usage, and return type. It lacks details about the returned dict structure, but given no output schema and low complexity, this is acceptable.

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 100%, but the description adds meaning beyond the schema by explaining the role of each parameter (e.g., 'category column for labels', 'numeric value column'). This helps the agent understand how to map user requests to 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 clearly states that the tool generates a pie chart from a Teradata table, specifying the table name, labels column, and value column. It distinguishes itself from sibling tools like plot_polar_chart and plot_line_chart by explicitly naming them as alternatives for polar area charts and time-series trends.

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 states when to use the tool (for proportions, shares, breakdowns) and what not to do (do not pre-fetch data with base_readQuery). It also provides clear alternatives for related chart types, aiding correct tool selection.

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 declare readOnlyHint=true and idempotentHint=true. Description adds value by specifying that the tool reads directly from a Teradata table and instructs not to use base_readQuery first, implying the tool handles the query internally. No contradictions with 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 concise and well-structured: two sentences for the main purpose and usage, followed by a clear list of three parameters with their types and roles. No extraneous 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?

The tool lacks an output schema, and the description only states the return type as 'dict' without explaining what the dictionary contains (e.g., chart data, configuration, or a generated chart object). For a visualization tool, this is a significant gap, though the input side is well-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?

Schema coverage is 100%, and the parameter descriptions in the tool description are identical to those in the input schema. The description does not add new meaning beyond the schema; however, the main description provides context for each parameter's role in generating a polar chart, making it baseline adequate.

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 the tool generates a polar area chart from a Teradata table, specifying the required parameters (table_name, labels, column). Distinguishes from sibling tool plot_pie_chart, fulfilling the specific verb+resource criterion.

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?

Explicitly tells when to use this tool (when user asks for polar chart or polar area chart) and when not to (do not use base_readQuery first). Provides clear alternative (use plot_pie_chart for standard pie-style breakdowns).

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?

Adds important behavioral detail beyond readOnly and idempotent annotations: it reads directly from a table and advises not to pre-fetch with base_readQuery. No contradiction with 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?

Concise and well-structured. One short paragraph with key purpose, usage guidance, and parameter mapping. 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?

Lacks details on return value format (only says 'dict' in a comment). With no output schema, description could specify what the dict contains (e.g., chart object). Otherwise sufficient given annotations and sibling context.

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 100% and description repeats parameter info almost verbatim. Adds minor context in the main paragraph (e.g., 'one or more value columns'), but no additional semantics or constraints beyond the 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 clearly states it generates a radar chart from a Teradata table, specifies the verb 'generate' and resource, and differentiates from sibling tools like plot_line_chart by stating when to use alternatively.

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?

Provides explicit when-to-use (spider chart, radar chart, multi-dimensional comparison) and when-not-to-use (time-series/trend data, directing to plot_line_chart). Also warns against using base_readQuery first.

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 and idempotentHint. The description adds behavioral context about the persist parameter (materializes as volatile table and returns table name if True). No contradictions. Could clarify default return format (data vs table name).

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?

Three sentences for purpose and usage, plus a bullet list for parameters. No unnecessary words. Front-loaded with core action. Highly 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?

No output schema, but description indicates return of 'summary statistics' and optionally a table name. This is sufficient for an overview tool. Could detail what statistics are included, but not essential given sibling differentiation.

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 100%, so description's role is limited. The description restates parameter purposes in a bullet list, adding the persist behavior context but not much beyond the schema. Baseline 3 is appropriate.

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 it returns summary statistics for ALL columns in a table, distinguishing it from the sibling tool qlty_univariateStatistics for single columns. The verb 'get' and resource 'summary statistics for all columns' are specific.

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?

Explicitly advises when to use ('when user asks for overview, profile, or summary of every field') and when not to use ('for detailed statistics on a SINGLE specific column, use qlty_univariateStatistics instead'). This provides clear context for selection.

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 set readOnlyHint=true and idempotentHint=true, ensuring the agent knows it's safe and repeatable. The description adds behavioral details: the optional 'persist' parameter materializes a volatile table and returns its name. This goes beyond the annotations, but doesn't cover potential performance notes or the exact format of non-persisted 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 divided into a usage paragraph and an argument list. It's front-loaded with the core action. Each sentence provides necessary information without redundancy. Could be slightly tighter, but overall 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?

Given no output schema, the description should clarify the return format. It states 'Get unique values' and for persist 'returns table name', but doesn't specify the structure when persist is false (e.g., an array). This is a minor gap. Otherwise, for a 4-param tool with full schema coverage, it covers the essentials.

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 100% with descriptions for all 4 parameters. The description echoes and expands slightly, e.g., stating the requirement for column_name and the ask-for-clarification rule. This adds value beyond the schema, such as the persist behavior, but the schema already defines each parameter's role well.

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 purpose as 'Get the unique (distinct) values present in a specific column of a table.' It uses a specific verb ('Get') and resource ('unique values'), and the name 'distinctCategories' aligns. Among siblings like qlty_columnSummary (summarizes statistics), this tool's purpose is distinct and clear.

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 says when to use: 'Use when the user asks what unique values, categories, or entries exist.' It also provides a prerequisite instruction: 'if no column name is specified, ask for clarification.' This gives clear context, though it does not explicitly exclude other cases or mention 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 indicate read-only and idempotent behavior. Description adds that it returns a column-level summary and explains the persist parameter's effect, adding value beyond 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?

Description is concise, front-loaded with purpose, and well-structured with usage guidelines and parameter list. No unnecessary 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?

Given 3 parameters, no output schema, and rich annotations, the description provides complete guidance including usage context, parameter explanations, and return value nature. Adequate for an AI agent.

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 100% with descriptions for each parameter. The description repeats parameter info but does not add meaning beyond the schema, so baseline score of 3 is appropriate.

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 column names with NULL/missing values and returns a column-level summary. It distinguishes from the sibling tool qlty_rowsWithMissingValues.

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?

Explicitly tells when to use (user asks for columns with nulls) and when not to (actual data rows), providing a direct alternative (qlty_rowsWithMissingValues).

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. Description adds return info (list of column names) but no further behavioral traits. Adequate given annotation coverage.

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

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

Two short paragraphs: first defines tool and usage, second lists arguments. Front-loaded, no redundant 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?

Tool is simple (returns list of column names). Description covers purpose, usage, and parameters completely. No output schema needed.

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 100%, description repeats parameter details without adding new meaning beyond schema. Baseline 3 appropriate.

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?

States specific verb 'identify' and resource 'numeric columns in a table' with distinct focus on negative values. Differentiates from sibling tools like qlty_missingValues.

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?

Explicitly tells when to use: 'user asks about negative numbers, values below zero, or columns with anomalous negative entries.' Does not mention alternatives, but context is 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?

Adds context beyond readOnlyHint and idempotentHint annotations by describing return behavior (records themselves or table name with persist). No contradictions.

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 bullet points for arguments, front-loaded main purpose. Slightly repetitive in 'Do NOT' statements but overall clear 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?

Covers main aspects: returns rows or table name, not a column summary. Lacks explicit output format detail (e.g., which columns returned), but adequate given no output schema.

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 100% coverage with descriptions; description reiterates and adds clarity (e.g., optional database_name, persist effect), providing added 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?

Description clearly states it retrieves actual data rows where a specific column is NULL or missing, distinguishing it from qlty_missingValues which provides a column-level summary.

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?

Explicitly says when to use (when user wants to SEE or FETCH rows with missing values), when not to use (avoid base_readQuery), and distinguishes from sibling qlty_missingValues.

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 and idempotentHint, and description adds the persist behavior and return of table name, fully disclosing side effects.

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 sentences for purpose and usage, then argument list; no extra words, front-loaded with key action.

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 tool with 4 params and no output schema, the description covers functionality, usage context, and parameters completely.

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 100%, and description lists parameters but only repeats schema descriptions; no additional semantic value beyond the 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 clearly states the tool calculates mean and standard deviation for a single numeric column, and distinguishes it from sibling qlty_univariateStatistics by specifying the full statistical profile alternative.

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?

Explicitly states when to use (when user asks for standard deviation, spread, or mean+variability) and when not to (for fuller stats, use qlty_univariateStatistics).

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 and idempotentHint true. The description adds transparency by explaining the persist behavior. No contradictions.

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?

Very concise: two sentences for purpose and usage, then bullet-list arguments. Front-loaded with key action and distinctions.

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?

Fully covers purpose, usage, parameters, and output implications. No output schema but description sufficiently implies return values.

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 100%, so baseline 3. The description clarifies the purpose and output, which indirectly helps parameter understanding, but restates schema for arguments.

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 it calculates full univariate statistics for a single numeric column, listing specific statistics (min, max, mean, etc.). It distinguishes itself from siblings by specifying use cases.

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?

Explicitly tells when to use this tool vs alternatives: use for comprehensive stats of one column; for just mean and std use qlty_standardDeviation; for all columns use qlty_columnSummary.

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 describes creating a query table and storing data (writes), but annotations set readOnlyHint=true and idempotentHint=true. This contradiction requires a score of 1 per rules.

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 extremely verbose (over 500 words) with repetitive information (e.g., purpose stated multiple times). While it uses headings for structure, it lacks conciseness and could be significantly shortened.

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 workflow steps, configuration, technical details, and return format (chunks with text, score, metadata). However, it omits explanation of the 'k' parameter and conflicts with annotations, creating gaps in usability.

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% and the description does not explicitly describe the parameters 'question' and 'k'. It implies 'question' is the user query but adds no detail beyond the name; 'k' is not mentioned at all. The description fails to add meaning beyond the 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 clearly states the tool executes a complete RAG workflow to answer user questions based on document context, with specific verb and resource. It distinguishes itself from all sibling tools, which are unrelated to RAG.

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 says this tool should be used when user query is tagged with /rag, and that it is a complete end-to-end workflow needing no additional tools. However, it does not provide explicit when-not-to-use or alternatives, though siblings are different.

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 (readOnlyHint, idempotentHint) already indicate safe read behavior. The description adds that it lists permissions and requires a role name, but doesn't detail edge cases like non-existent roles or output format. Given annotation coverage, this is sufficient.

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?

Description is concise and well-structured: a clear opening sentence, usage guidance, and a bulleted parameter list. No unnecessary words, front-loaded key 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 simple read-only tool with full annotation coverage and no output schema, the description adequately covers purpose, usage, and parameters. Could briefly mention output format (e.g., list of permission strings), but not essential.

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 100%, so baseline is 3. The description repeats the schema's parameter descriptions verbatim without adding extra context or examples. No additional value beyond 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 clearly states the tool lists database-level permissions for a Teradata role, using a specific verb and resource, and distinguishes it from sibling tools like sec_userDbPermissions and sec_userRoles.

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?

Explicitly specifies when to use this tool (for role permissions), warns against confusion with user-level queries, and names alternative tools (sec_userDbPermissions, sec_userRoles). Also states the prerequisite of a role name.

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 and idempotentHint. The description adds context that it lists 'directly' granted permissions, distinguishing from inherited roles. It does not contradict annotations and provides additional behavioral insight, though could mention performance or required auth.

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 succinct and well-structured: a clear first sentence, followed by usage guidelines, then a bulleted parameter list. Every sentence adds value without redundancy, earning the highest score.

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 two parameters, no output schema, and annotations indicating idempotent/read-only, the description covers purpose, usage, and parameters adequately. However, it lacks details on the return format for the default non-persist case, leaving 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 description coverage is 100%, so baseline is 3. The description adds extra meaning: for user_name it notes 'Requires a user name' and for persist it explains 'materializes result as a volatile table and returns table name,' which goes beyond the 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 states the tool lists database-level access permissions for a specific Teradata user, using a specific verb and resource. It explicitly distinguishes from the sibling tool sec_userRoles, meeting the high bar for purpose clarity.

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: 'Use when the user asks what a named user can DO in each database' and 'Do NOT use to see what roles a user has — use sec_userRoles for that.' This clearly defines when to use and when not, with a named alternative.

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 and idempotent behavior. Description adds context about the persist parameter creating a volatile table and returning its name, which is a behavioral side effect.

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: purpose first, then usage guidelines, then parameter list. No filler, every sentence adds value.

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 tool with 2 params and no output schema, the description is complete: purpose, when to use, parameter details, and a note on persist behavior. No gaps.

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 covers both parameters with descriptions, and the description adds a user-friendly explanation, especially for persist. High schema coverage sets baseline at 3, but additional clarity warrants 4.

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 it lists roles for a specific Teradata user account, distinguishing from sibling tools for role permissions and user DB permissions.

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?

Explicitly specifies when to use (user asks about roles) and when not to use, with direct references to alternative tools (sec_rolePermissions, sec_userDbPermissions). Also states required input (user name).

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 read-only and idempotent behavior. The description reinforces this by stating it analyzes pre-computed statistics and describes the output format. It adds context about performance categorization and thresholds, which goes beyond 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 sections and bullet points, but it is lengthy. While detailed, some parts like the optimization decision framework could be condensed. It is adequate but not maximally concise.

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 (2 parameters, no output schema, annotations present), the description explains the tool's purpose, available metrics, usage workflow, and output format. It compensates for missing schema descriptions and provides sufficient context for an AI agent.

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 schema has 2 parameters with 0% description coverage. The description lists available sorting metrics for sort_by_metric and mentions using limit_results to focus on top clusters, providing necessary meaning for both 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 clearly states the tool analyzes pre-computed cluster statistics to identify optimization opportunities without re-running the pipeline. It lists specific analysis capabilities and differentiates itself from sibling tools like sql_Execute_Full_Pipeline by emphasizing iterative 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 a typical analysis workflow and optimization decision framework, guiding when to use the tool (e.g., for iterative analysis) and what steps to take. It implicitly contrasts with other tools but lacks explicit exclusion criteria for when not to use it.

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

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

The description describes creating tables and storing vector data (side effects), but annotations declare readOnlyHint: true, creating a contradiction. The description does not resolve this inconsistency, so it fails to provide transparent behavioral information.

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 and front-loaded content. However, it is quite lengthy; some redundancy in metrics explanation could be trimmed without losing value.

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 (multiple pipeline steps, many metrics), the description covers workflow, configuration, prerequisites, and use cases. However, it lacks an explicit description of the return value or output format, which 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?

The description explains the two parameters (optimal_k and max_queries) with context about defaults and configurability. This adds significant meaning beyond the schema, which has 0% 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 executes a full SQL query clustering pipeline for optimization. It uses specific verbs and resources, and distinguishes from sibling tools like sql_Analyze_Cluster_Stats by being the complete pipeline.

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: it includes an optimization workflow section listing subsequent tools to use, outlines use cases, and mentions prerequisites. This helps the agent decide when to invoke this tool versus alternatives.

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

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

Annotations declare readOnlyHint and idempotentHint as true, indicating safe read-only behavior. The description enhances transparency by detailing the performance categorization logic (CPU, skew categories) and the metrics available for sorting. It also describes the output composition (SQL text, metrics, categories). No contradictions with 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 long but well-structured with bold headers and bullet points. Each section serves a purpose: purpose, capabilities, strategies, metrics, categories, workflow, limits, output. A bit verbose but efficiently organized. Could be more concise in some sections, but nothing is wasted.

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 (3 parameters, no output schema, rich behavioral context), the description is thorough. It covers input parameter usage, output composition (SQL text, metrics, categories), and behavior (sorting, categorization). It also places the tool in a workflow with siblings. Without output schema, the description fully details return values.

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% (description does not document parameters in structured format), but the description extensively compensates. It explains the 'metric' parameter with available values and default, implies 'cluster_ids' by context, and covers 'limit_per_cluster' in the query limit strategy. The default values and sorting options are clearly documented, adding significant meaning beyond the 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 clearly states the tool retrieves actual SQL queries and performance metrics from specific clusters for pattern analysis. The bolded title and first paragraph establish the specific verb-resource pair (retrieve queries from clusters) and distinguish it from sibling tools like sql_Analyze_Cluster_Stats, which likely focuses on cluster-level statistics rather than individual query 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 provides explicit guidance on when to use this tool: after cluster identification from sql_Analyze_Cluster_Stats, as part of a typical optimization workflow. It also details query selection strategies by various metrics and a query limit strategy. It does not explicitly mention when not to use or name alternatives beyond the workflow context, but the context is clear enough.

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