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

The annotations already indicate readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety. However, the description adds valuable behavioral context about the 'persist' parameter, explaining it materializes the result as a volatile table and returns the table name. This informs the agent about a side effect beyond a simple read.

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 efficient, with the purpose stated in the first sentence, followed by usage guidance and a bulleted list of parameters. It is not overly verbose, though the parameter descriptions are repeated from the schema (which is acceptable). Could be slightly more concise by eliminating redundancy, but overall well-structured.

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

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

Given that the tool is simple (listing columns with attributes) and there is no output schema, the description adequately covers behavior. However, it does not specify the exact return format (e.g., a table-like result) or whether the output includes all rows or is truncated. For completeness, mention of the output nature would be helpful, but the current clarity is sufficient for typical use.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds extra context by explaining default values ('Defaults to '%' (all databases/all tables)') and the behavior of the 'persist' parameter, which is not fully detailed in the schema. This exceeds the baseline of 3 for full schema coverage.

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

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

The description clearly states the tool lists column names, data types, and basic attributes for a Teradata table/view, using specific verbs and resources. It also distinguishes from the sibling tool base_columnMetadata by indicating that for precise type codes, character sets, etc., that tool should be used instead.

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 ('for straightforward questions like what columns does this table have?') and when to use an alternative ('for precise Teradata-specific type codes... use base_columnMetadata instead'). This provides clear guidance for selecting the appropriate 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 only declare readOnlyHint and idempotentHint. Description adds extensive behavioral context: uses DBC.ColumnsVX and HELP COLUMN, supports bulk retrieval with payload/time budgets, continuation pattern, large-scale strategies, limitations on stored procedures, and parallelism details.

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 long but well-structured with clear sections, headings, and bullet points. Front-loaded with core purpose. Some redundancy (e.g., repeating type info), but overall appropriate for complexity.

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 8 parameters, no output schema, and annotation coverage, description is fully complete. It details input parameters, return values (4 computed fields), continuation pattern, table kind handling, and limitations. Leaves no significant 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 has 0% field descriptions, so description carries full burden. It provides detailed explanations for all 8 parameters including defaults, usage examples, and behavioral notes (e.g., continuation for object_name, table_kind filtering, field trimming).

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 detailed technical column metadata for Teradata tables/views, listing specific attributes (type codes, character sets, precision, nullability, index classification). Distinguishes from sibling base_columnDescription for basic column listing.

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 this tool (precise Teradata-specific information) and when not (use base_columnDescription for simple list). Provides resolution paths for tables/views and large-scale usage strategies with 6 numbered guidance points.

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. Description adds that materializing result creates a volatile table and returns its name, giving non-obvious behavioral context.

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

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

Concise with a clear opening sentence and structured parameter descriptions. No unnecessary words, and important guidelines are front-loaded.

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

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

Covers core functionality and usage constraints, but does not specify the output format (e.g., list of names or objects). Minor gap for a tool with 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 coverage is 100%, so baseline is 3. Description repeats schema parameter details but does not add new meaning beyond them.

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 databases/schemas in Teradata. It distinguishes from sibling tools like base_tableList by explicitly saying not to call it as a preliminary step for table listing.

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 (user asks about databases) and when not to use (not as preliminary step for tables), including alternative behavior suggestion.

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 context on truncation behavior, persist option, and metadata fields. However, it does not explicitly state the tool only executes read-only queries (SQL could include DML), but annotations cover this. Slight gap in emphasizing safety 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 sections for arguments, truncated handling, and returns. Every sentence adds value; no fluff. Front-loaded with core purpose and usage guidance.

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 all three parameters and return metadata fields (volatile_table, truncated, row_limit). Does not address error cases or invalid SQL, but given no output schema, it provides adequate completeness for the tool's 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?

Schema has 0% description coverage, but the description provides thorough explanations for all three parameters: sql (required full SQL text), persist (persist results as table), row_limit (default 1000, ceiling 50000). Adds significant meaning beyond 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 executes user-provided SQL queries against Teradata and returns results. It explicitly distinguishes from sibling tool base_tablePreview for browsing, and mentions alternatives, avoiding ambiguity.

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

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

Provides explicit when-to-use (user supplies explicit SQL or filter conditions) and when-not-to-use (do not use for browsing/sampling - use base_tablePreview). Includes guidance on handling truncated results with higher row_limit or persist=true.

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 it saves a file to disk, which is a write side effect, but annotations set readOnlyHint=true and idempotentHint=true, creating a contradiction. This undermines trust in the tool's behavior.

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

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

The description is efficient: one sentence for purpose, one for usage rules, then argument list, then return info. Front-loaded with critical information, no 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?

The description covers purpose, arguments, and return format, and distinguishes sibling. However, the annotation contradiction undermines completeness, as the agent cannot trust whether the tool is read-only or not. Without output schema, the return description is adequate but not detailed.

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 compensates well. It explains each parameter (database_name, table_name with comma-separated bulk, object_type with defaults, output_dir with default) beyond the schema's just type and defaults. However, it could add more detail on acceptable values for object_type.

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 and saves it as a .sql file, distinguishing it from base_tableDDL which only displays DDL. The verb 'save' and resource 'DDL' are specific, and the sibling differentiation is explicit.

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

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

The description explicitly says to use this tool when the user wants to export/write/download/persist DDL to a file, and not to display/view DDL (use base_tableDDL instead). It also provides argument details and defaults, giving clear context.

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 adds behavioral context such as revealing natural JOIN relationships and data affinity patterns, and explains the persist parameter's effect of materializing a volatile table. Annotations already declare readOnlyHint and idempotentHint, so the description complements them without 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 concise, front-loaded with the purpose, and includes usage guidelines and argument list in a clear structure. A small improvement could be organizing the argument list more formally.

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, but lacks details about the output format or example results. With no output schema, more descriptive output would enhance 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 the baseline is 3. The description repeats parameter names and purpose but adds no additional meaning beyond what the schema already provides.

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 identifies co-occurring tables in SQL queries, revealing JOIN relationships and affinity patterns. It uses a specific verb 'Identify' and distinguishes from sibling tool base_tableUsage.

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 (queries about tables queried together, related tables, common workflows) and when not to (access frequency, query counts, per-user stats), directing to base_tableUsage as 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 readOnly and idempotent. Description adds context about not guessing empty database name and explains the persist parameter. 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 is front-loaded and clearly stated. Subsequent sentences provide necessary usage guidance and alternatives. Slightly wordy but efficient overall.

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 simplicity (no output schema), the description covers purpose, usage, required parameters, and alternatives. The persist behavior is explained. Minimal 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 100% with descriptive parameter names and descriptions. The description repeats the same information, adding no new 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 returns the CREATE TABLE DDL for a Teradata table, listing specific content (column types, constraints, indexes, keys). It distinguishes from siblings like base_saveDDL and base_columnDescription.

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 guidance (user wants CREATE statement, table definition, or how table was built). Includes caveat to ask for clarification if parameters missing, and directs to alternative tools for saving DDL or column descriptions.

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 context about the persist parameter materializing as a volatile table. No additional behavioral details beyond that, which is sufficient given the safety profile.

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

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

Multi-line structure with clear main point and parameter details. Not overly verbose, though could be slightly more structured. Front-loaded with tool 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?

No output schema, so description should describe return format. It only mentions for persist case. For default list, no output description is provided, leaving the agent unaware of result structure (e.g., columns).

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

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

Input schema has 100% description coverage. Description largely repeats schema but adds the clarifying question guidance for database_name, enhancing semantic 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?

Verb 'List' + resource 'tables and views' + scope 'within a specific Teradata database or schema'. Distinct from sibling tools like base_databaseList (list databases) and base_tableDDL (get DDL).

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

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

Explicit guidance on when to pass database_name vs omit, with a caution to ask clarifying question to avoid querying all databases. Lacks comparison to sibling tools but provides clear context.

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. The description adds context about returning a sample and the persist option materializing a volatile table, but doesn't specify row count or exact behavior beyond that.

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 concise paragraphs: first explains purpose and usage guidelines, second lists arguments. No redundant or unnecessary words.

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

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

The description covers the main purpose, parameter behavior, and distinguishes from siblings. However, it lacks details like how many rows are returned ('first few') and whether there are limits or performance considerations, but overall sufficient for a simple 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%, so the description's argument list largely restates schema descriptions. It adds minor context (e.g., persist returns table name) but does not significantly enhance meaning beyond what's 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 returns a quick sample of first few rows from a Teradata table/view with no SQL required, and distinguishes from base_readQuery for filtered queries.

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

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

Explicitly says when to use (explore/peek without conditions) and when not to use (when WHERE clause, filter, or SQL is provided), and points to base_readQuery as the 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 provide readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat safety. It adds behavioral context about output: 'showing which objects are most actively queried and by whom' and explains the persist parameter behavior. This adds 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?

The description is concise and well-structured: purpose sentence, usage guidelines, alternative, then parameter list. No fluff, every sentence earns its place.

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

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

Despite no output schema, the description hints at the output format ('showing which objects...' and 'returns table name' for persist). It is fairly complete for a tool with clear annotations and parameters, though more detail on the output structure would help.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description repeats the parameter descriptions verbatim without adding new meaning beyond the schema, so baseline 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 starts with a specific verb+resource: 'Report access frequency and per-user query patterns for tables and views in a Teradata database'. It clearly states what the tool does and distinguishes itself from sibling base_tableAffinity by explicitly mentioning that 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: 'Use when the user asks how often tables are accessed, which tables are most popular, or which users are running queries against a database.' Also provides an explicit alternative: 'For discovering which tables appear together in the same queries, use base_tableAffinity 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 (readOnlyHint: true, idempotentHint: true) already indicate safe read operations. The description adds context about the persist parameter materializing results as a volatile table and returning the table name. It does not cover return format or error behavior, but the additions are valuable and consistent.

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 paragraphs: first gives purpose and usage guidance, second lists arguments with clear constraints. Every sentence adds value, no fluff. Front-loaded with the core 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?

For a simple 2-parameter tool with no output schema, the description covers all essential aspects: purpose, usage context, parameter semantics, behavioral notes, and sibling differentiation. It is fully complete for an agent to correctly invoke this 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%, so baseline is 3. The description adds meaning: database_name is required and must not be empty, and persist with True materializes as a volatile table and returns the table name. This goes beyond the schema's simple type/required annotations.

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 shows disk space allocation for a specific named Teradata database. It distinguishes itself from siblings dba_tableSpace (table-level) and dba_systemSpace (system-wide). The verb 'show' and resource 'disk space allocation for a specific named database' is precise.

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 about space for a specific database) and when not (table-level or system-wide). Also provides a crucial guideline: if no database name is provided, ask for clarification; do not call with an empty string.

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 that persist materializes into a volatile table, providing extra behavioral context 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?

Two sentences plus one argument description, all front-loaded. No wasted words; 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 tool with one parameter and no output schema, the description adequately covers purpose and usage. Minor omission: does not explain what 'release information' includes, but 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% and the description repeats the same information as the schema parameter description. No additional meaning added beyond what schema provides.

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 version and release information with a specific verb and resource. It distinguishes from siblings as no other dba tool focuses on version.

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: 'Use when the user asks what version of Teradata is running on the system.' No exclusions or alternatives provided, 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, read-only operation. The description adds behavioral details beyond annotations, such as the ability to persist results as a volatile table via the 'persist' parameter, and the date range constraint.

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 a clear purpose statement and usage guideline, followed by parameter definitions. It is front-loaded with the main purpose. Could be slightly more structured (e.g., separate sections), but it is efficient with 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?

The description explains what the tool does and its parameters, but does not describe the output format or content of the report (e.g., list of features, counts, etc.). With no output schema, additional detail on return value would improve completeness. The persist behavior is explained, but the default output is vague.

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 all parameters. The description repeats the parameter definitions, adding minimal value beyond a concise summary. It does not provide additional semantics or examples for parameters like start_date and end_date beyond format specification.

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 action ('Report') and the resource ('Teradata product features used during a specified date range'). It also lists specific use cases, effectively distinguishing it from sibling tools like other dba_ tools which focus on space, version, sessions, 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 the tool: 'Use when the user asks about feature adoption, which Teradata capabilities are being used, or how feature utilization has changed over a period.' It provides clear context, though it does not explicitly mention when not to use it or direct to 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=true, so the description adds context about the data reported (timing and magnitude of throttling) and optional persistence. 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 concise: two sentences for purpose and usage guidelines, then bullet-like argument list. No wasted words, well-structured.

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?

Lacking an output schema, the description does not specify the default output format (e.g., list of events). It mentions returning a table name when persist=True, but not the normal return. Slight 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 coverage is 100%, so baseline is 3. The description echoes the schema descriptions for parameters, adding no extra semantic depth beyond what the schema provides.

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 flow control events (system throttling/delaying queries) and distinguishes from sibling dba_userDelay which deals with individual user queue waits.

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 about system throttling, flow control delays, workload manager restrictions) and when not to (for individual user waits, use dba_userDelay 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 as true, indicating a safe, read-only operation. The description adds behavioral context by mentioning the persist parameter behavior (materializes result as volatile table and returns table 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 front-loaded with a clear purpose and usage guidance, followed by a well-organized list of arguments. Every sentence adds value, and the structure is efficient and easy to parse.

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

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

For a reporting tool with 9 optional parameters and no output schema, the description covers purpose, usage, and parameter details adequately. It explains the persist parameter's return behavior. However, it lacks details about the default output format or potential size, which 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%, so the input schema already documents all parameters with descriptions. The description repeats these descriptions in a list format but does not add significant new meaning beyond what the schema provides.

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 system-wide resource consumption (CPU, IO, memory) broken down by time period, application, workload type, or complexity class. It distinguishes itself from sibling dba_tableUsageImpact by specifying that it is not tied to a specific database, but for per-database or per-user impact.

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: 'system-level resource breakdowns, workload profiles, or consumption trends over a date range — not tied to a specific database.' It also provides an alternative sibling: 'For per-database or per-user impact within a named database, use dba_tableUsageImpact 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 include readOnlyHint and idempotentHint, and the description confirms the tool reports current session information without side effects. It adds context about the persist parameter materializing results as a volatile table, which is beyond annotations. 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 two focused paragraphs. The first defines purpose and usage, the second lists arguments. Every sentence adds value with no unnecessary words.

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

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

Given the simple tool with 2 fully documented parameters, annotations for safety, and no output schema, the description covers all necessary context: purpose, usage triggers, parameter details, and behavioral notes. 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%, so the schema already documents both parameters. The description adds minimal extra meaning (default behavior and persist effect), but mostly repeats schema. Baseline 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 'Report currently active session information for a specific user or all users.' It uses a specific verb (report) and resource (session information), and distinguishes from sibling tools like dba_databaseSpace and base_columnDescription 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?

The description explicitly says 'Use when the user asks about open connections, active sessions, or currently logged-in users' and provides guidance on using '*' for all users without clarification. However, it does not mention when not to use this tool or provide 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=true and idempotentHint=true, so the description need not repeat that. The description adds no additional behavioral context beyond the parameter effect (which is parameter semantics). A score of 3 is appropriate given the low burden but no extra disclosure.

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 (three sentences), front-loads the purpose, and uses clear structure. No unnecessary words.

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

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

The description covers purpose, usage guidelines, and parameter. However, it omits what the tool returns when persist=False (presumably direct results but not stated). Given the tool's simplicity and lack of output schema, this is a minor gap.

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

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

Schema coverage is 100% and the description's parameter explanation is identical to the schema's description. No added value beyond what the schema already provides. Baseline 3 for high coverage.

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

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

The description clearly states the tool shows total disk space usage across the entire Teradata system, aggregated over all databases. It differentiates from siblings by specifying use cases for system-wide vs. per-database vs. per-table queries.

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

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

Explicitly states when to use this tool (warehouse-wide storage questions) and when to use alternatives (dba_databaseSpace for single database, dba_tableSpace for table-level). No ambiguity.

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 detail on the persist parameter: 'materializes result as a volatile table and returns table name,' which is behavioral context beyond annotations. No additional traits like side effects or auth needs are discussed, but annotations already cover safety.

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: a concise purpose paragraph followed by a bulleted argument list. It is front-loaded with the main action. While slightly longer than necessary due to repeated parameter info, it remains readable 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?

Given no output schema, the description does not explain the return format (columns, structure) for the normal case. For persist, it notes returns table name. While annotations and schema cover safety and parameters, the missing output description leaves some ambiguity for the agent about what to expect from the response.

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 duplicates parameter docs in an Arguments section, reinforcing requirements like 'database_name - Required — do not pass empty string' and defaults. However, it adds no new semantic meaning beyond the schema; the persist description is identical.

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 table-level disk space usage within a specific Teradata database, ranked by size.' It distinguishes from sibling tools by mentioning 'Use when the user asks which tables are largest' and contrasts with 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?

Provides explicit when-to-use: 'Use when the user asks which tables are largest or consuming the most storage within a named database.' Also gives when-not-to-use: 'NEVER call this tool with an empty database_name' and instructs to ask for database if not provided. Alternatives are named: dba_databaseSpace and dba_systemSpace.

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. The description adds behavioral context about the 'persist' parameter materializing a volatile table and returning its name, which is useful beyond the annotations. However, it does not discuss authentication, rate limits, or other constraints.

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

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

The description is well-structured with a purpose paragraph and a parameter list. It is concise but covers essential points; could be slightly tighter but is effective.

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 no output schema, the description does not explain the return format (e.g., whether it includes timestamps, SQL text). While the purpose and usage are clear, a bit more detail on what the result contains would improve completeness. The parameters are fully 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 100%, so baseline is 3. The description repeats parameter names and gives brief explanations, which are nearly identical to the schema descriptions, adding minimal extra value.

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

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

The description clearly states the action ('Retrieve SQL statements') and resource ('against a specific named table'). It distinguishes from the sibling tool 'dba_userSqlList' by specifying that this tool is for table-specific history, not user-specific history.

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 guidance is given on when to use (user asks about queries on a particular table), when not to use (if table name not explicit, ask for clarification), and alternative tool (dba_userSqlList for user-specific SQL history).

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 that persist=True materializes as volatile table and returns table name. No contradictions present.

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 and usage guidelines but then repeats parameter descriptions already present in the schema. Could be more concise by omitting the parameter list.

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. Description only hints at return value for persist=True. For default (persist=False), it does not explain what the tool returns. Missing details on result format or any 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% with each parameter having a description. The description repeats the same information for each parameter, adding no new meaning beyond the schema. Baseline 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?

First sentence clearly states the tool's purpose: 'Identify which users and tables are driving the most query and resource activity within a specific Teradata database.' This distinguishes it from sibling tools like dba_resusageSummary.

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: 'Use when the user asks who is hitting a named database hardest' and when not to, with a direct alternative: 'For system-wide CPU, IO, and memory metrics... use dba_resusageSummary instead.' Also requires database name and advises to ask for clarification if missing.

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 adds value by describing the persist parameter's behavior (materializes as volatile table and returns table name). 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?

Two concise sentences plus parameter list. Front-loaded with purpose and usage. Every sentence is informative and 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?

Covers purpose, usage, parameters, and persist behavior. However, lacks explicit description of the return format (e.g., what the 'report' looks like). Still fairly complete for a read-only 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% with descriptions for start_date, end_date, and persist. The description restates these but does not add new 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 reports how long users waited in the query queue, using specific verb 'Report' and resource 'user wait times'. It distinguishes from sibling dba_flowControl by specifying different focus areas.

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 (user asks about user wait times, queue delays) and when not (system-level throttling should use dba_flowControl instead). Provides clear usage context.

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 context about the persist parameter behavior (materializes as volatile table and returns 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?

The description is fairly concise with a clear purpose statement and parameter list, though the parameter list is somewhat redundant with the schema. It is well-structured and front-loaded.

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

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

The description covers input parameters well but does not describe the output format or return fields. Since there is no output schema, the description should detail what the retrieved SQL statements include (e.g., timestamp, text). This is a notable 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 coverage is 100% with descriptions for all three parameters. The description repeats and reinforces the user_name requirement and semantics, adding usage 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 the tool retrieves SQL statements executed by a specific user, with a specific verb and resource. It also distinguishes from the sibling dba_tableSqlList by explicitly stating when not to use it.

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 excellent guidance: when to use (user asks about queries by a named user), when not to use (if no user name is given, ask; never call with empty user_name; do not use for table history). It also names the alternative 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, so the tool is safe. The description adds value by explaining the shared edge fetch, in-memory edge sharing, algorithmic complexity, and performance advantages over serial calls. 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 clear sections: purpose, performance, use cases, arguments, return format, and examples. It is front-loaded. However, it is relatively long; some redundancy exists in the performance section, but it's justified by the tool's complexity.

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 detailed return format with JSON example. All parameters are documented. The tool's relationship to siblings (composite vs individual) is clear. Context signals (6 params, no output schema) are fully addressed.

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

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

Schema coverage is 0%, but the description compensates fully: each parameter is explained with types, defaults, examples, and critical warnings (e.g., container_pattern must be string, not array). The edge_repository parameter is described with a reference to another tool. This is exemplary.

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 defines the tool as a composite graph analysis combining four individual analyses into one call, with a specific verb ('runs') and resource ('graph analyses'). It distinguishes from siblings (e.g., graph_bfsLevels) by highlighting the composite nature and shared edge fetch.

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 lists use cases such as full migration readiness assessment and dashboard data population. Contrasts with individual tools by noting performance benefits and suggests using this when 3+ individual calls would be needed. Includes example calls with different scenarios.

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

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

Annotations declare readOnlyHint and idempotentHint, and the description adds substantial behavioral details: pure-Python BFS, one SQL round-trip, multi-source BFS, filter application order, direction conventions, and node metadata derivation. 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 well-organized with clear headings and structure, though lengthy. Front-loaded with purpose and usage, every section adds value. Slightly verbose in technical implementation details but still effective.

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 (6 parameters, no output schema), the description covers all aspects: return structure with example, direction values, cycle candidates, summary metadata, and technical implementation notes. It enables the agent to use the tool 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 description coverage is 0%, but the description provides thorough explanations for each parameter, including examples, defaults, and behavioral notes (e.g., exact names requirement for root_node_list, fnmatch usage for exclude_objects). 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 starts with a clear verb+resource statement: 'Compute BFS shortest-path hop distances from one or more root nodes.' It also explicitly contrasts with sibling tool graph_traceLineage, providing distinct usage scenarios.

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 includes a detailed 'WHEN TO USE THIS TOOL vs graph_traceLineage' section with explicit use cases and non-use cases. It also gives a key distinction about root_node_list requiring exact names and suggests using graph_findRootObjects 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 readOnly and idempotent. The description adds implementation details (pure-Python, Union-Find, single SQL SELECT) and clarifies no stored procedure, going 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 sections, parameters, and return structure. Every sentence adds value, though slightly verbose; could be trimmed slightly without losing clarity.

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

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

Given the algorithmic complexity, the description covers input, output format (with field lists), use cases, and edge conditions. No output schema, but response structure is detailed enough.

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 coverage, the description fully explains all three parameters with format, examples, critical warnings (string not array), and defaults. This provides excellent semantic 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?

Clearly states it identifies Weakly Connected Components in a dependency graph, explains what a component is, and distinguishes from sibling graph tools (bfsLevels, detectCycles, 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?

Includes a 'Use this tool for:' list covering six concrete use cases. Does not explicitly exclude alternatives but provides enough 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?

The description adds behavioral details beyond the readOnlyHint and idempotentHint annotations: 'Pure-Python implementation', 'Issues a single SQL SELECT', 'performs WCC partitioning followed by iterative DFS cycle detection entirely in the MCP server process.' It also describes the response structure, providing transparency about execution and output.

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 for purpose, implementation notes, use cases, arguments, and returns. Each sentence adds value, and the information is front-loaded with the main purpose. It is concise yet comprehensive.

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 the absence of an output schema, the description fully details the response structure with field names and types. It covers purpose, usage, parameters, behavior, and output, making it self-contained and complete for the agent to understand and invoke the tool correctly.

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

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

With 0% schema description coverage, the description fully compensates by documenting each parameter with format, examples, defaults, and constraints. For instance, container_pattern is explained with CSV LIKE patterns and examples, and edge_repository references the Graph Edge Contract and links to another tool.

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: 'Detect circular dependencies (cycles) in the dependency graph.' This is a specific verb+resource combination that distinguishes it from sibling tools like graph_traceLineage or graph_connectedComponents.

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 five explicit use cases (e.g., 'Validating graph integrity (DAG property)', 'Debugging topological sort hangs') and mentions sibling tool graph_edgeContractDDL for generating the edge repository. It provides clear context for when to use this tool, though it lacks explicit comparisons to 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=true and idempotentHint=true. The description aligns perfectly: 'does NOT require a database connection — it generates DDL text from templates. No SQL is executed.' It also explains the conn parameter is unused, adding transparency beyond annotations. 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?

Well-structured: starts with core purpose, then details required/optional columns, provides a usage shortcut, lists arguments with examples, and describes return value. No fluff; 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?

Covers all aspects: behavioral (no DB connection), parameter semantics, return structure, and a practical usage shortcut. For a tool with this complexity and rich annotations, the description is complete and leaves 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?

Schema coverage is 100%, so baseline is 3. The description adds value with examples (e.g., 'StGeoMortgage_Semantic'), default values, and differentiation between TABLE and VIEW output types. This extra context justifies a 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 the tool 'generates DDL for a Graph Edge Contract-conforming table or view,' specifying a specific verb and resource. It distinguishes from sibling tools like graph_analyseDatabase by emphasizing it is for DDL generation, not 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?

Explicit when-to-use guidance: 'If you are working within an AI-Native Data Product... you do not need to generate DDL — pass that view... directly.' Provides clear context for when to use this tool versus relying on an existing view, and explains the tool's uniqueness (no database connection needed).

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

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

The description adds behavioral details beyond annotations (readOnlyHint, idempotentHint): it explains the read-only query nature, server-side filtering, performance implications, and return formats. 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 well-structured with clear sections (purpose, use cases, arguments, returns, examples). Each sentence adds value despite length. Information is front-loaded.

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

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

Given the tool's complexity (5 parameters, no output schema), the description is remarkably complete: it explains all parameters, provides example calls, technical implementation, and return format. 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?

The input schema has 0% parameter descriptions, so the description fully compensates with extensive details for each parameter: examples, wildcard usage, CSV format, whitespace handling, how to pass in code, and common patterns. This is extremely helpful.

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: 'Find root objects (objects with no upstream dependencies) in specified containers.' It uses specific verbs and resources, lists multiple use cases, and distinguishes from sibling tools like graph_analyseDatabase and graph_traceLineage.

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 this for:' scenarios, but does not directly state when NOT to use it or compare to alternatives. However, the context is clear enough for an agent to decide.

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

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

The description adds significant behavioral details beyond annotations: hybrid implementation, Python constructing recursive CTEs, only reachable subgraph crossing network, per-pattern CTE execution, and deduplication.

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 length could be slightly reduced without losing 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 the complexity (7 parameters, no output schema), the description is thorough, detailing response structure, edge row fields, and behavior for multiple patterns.

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

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

With 0% schema description coverage, the description compensates fully by explaining each parameter's format, constraints, defaults, and use examples, adding substantial meaning.

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 the tool analyzes object dependencies in Teradata, supporting wildcards and CSV patterns. It clearly distinguishes from sibling graph tools by focusing on lineage tracing and impact analysis.

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

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

The description provides explicit use cases (impact analysis, lineage tracing, etc.) but does not specify when not to use the tool or mention alternative sibling tools.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. Description adds that it reads directly from a database table, which is consistent and provides context about data source. No contradictions. Score reflects additional context 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 fairly concise with front-loaded key behavior. The included parameter section repeats schema information, which is slightly redundant but not excessive. Clear structure with usage instructions first.

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, description adequately explains what the tool does, what it reads, and when to use it. Missing return format details, but for a charting tool, it's sufficient. Completeness for a simple tool with good annotations.

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. Description adds context that labels is 'typically a date or time field' and columns are 'numeric', which adds meaning beyond the schema's generic descriptions. Also clarifies table_name as the table to generate chart from.

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 generates a line chart from a Teradata table, with explicit verb 'generate' and resource 'line chart'. It distinguishes from siblings by specifying not to use for proportional breakdowns (use plot_pie_chart or plot_polar_chart) or spider comparisons (use plot_radar_chart).

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 (time-series, trend lines, sequential data) and when-not-to-use (proportional categories, spider comparisons) with alternatives. Also instructs not to use base_readQuery to pre-fetch data, offering a clear directive.

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?

Given annotations already indicate readOnlyHint and idempotentHint, the description adds valuable context: it reads directly from the table without pre-fetching, and instructs not to use base_readQuery. This goes beyond mere restatement.

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 4 sentences, front-loading the purpose. It uses backticks for parameters and includes usage guidance. It is slightly longer than necessary but still 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 3-parameter tool with rich annotations, the description fully covers purpose, usage, parameters, and alternatives. It leaves little ambiguity for the agent, making it highly 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 coverage is 100% and the schema descriptions already specify each parameter's role. The main description integrates these roles but adds no new semantic information beyond what the schema provides. 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?

The description clearly states 'Generate a pie chart that reads directly from a Teradata table' with specific verb and resource. It distinguishes from siblings by explicitly referencing plot_polar_chart and plot_line_chart for alternative 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 tells when to use: 'when the user asks for proportions, shares, or how a total breaks down by category'. It provides explicit alternatives for polar and line charts, and warns against using base_readQuery. However, it does not exhaustively cover all sibling tools.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that it reads directly from a table and should not be preceded by base_readQuery, providing extra behavioral context 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 a single focused paragraph with clear sections for parameters and returns. Every sentence serves a purpose, no fluff, and 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?

For a simple three-parameter tool with no output schema, the description covers what the tool does, its parameters, and when to use it. Missing details about the returned dict format, but overall sufficient for agent selection and invocation.

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

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

Schema coverage is 100% so baseline is 3. The description not only lists parameters but also explains their roles (table_name for table, labels for category, column for numeric value), adding meaning beyond the schema's attribute 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 it 'Generate a polar area chart' from a Teradata table, specifying the resource and verb. It distinguishes from sibling plot_pie_chart, and explicitly names the three parameters.

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 instructions: 'Use when the user explicitly asks for a polar chart or polar area chart' and advises against using base_readQuery first. Directs standard pie breakdowns to plot_pie_chart.

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

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

Annotations already provide readOnlyHint and idempotentHint. The description adds that it reads directly from a Teradata table and warns against pre-fetching, which is valuable behavioral context beyond annotations. However, it does not describe what the returned chart looks like.

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

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

The description is very concise: two sentences plus a brief parameter overview. It front-loads the purpose and then provides usage guidance without any redundant or unnecessary information. 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 chart tool with 3 parameters and no output schema, the description covers purpose, usage, parameters, and an alternative. It lacks details about the return format (e.g., URL or image), but given the simplicity and annotations, it is reasonably 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 coverage is 100%, so baseline is 3. The description adds meaning by explaining the role of each parameter (table_name as source, labels as category column, columns as values) and how they map to chart elements, exceeding baseline.

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, distinguishes from siblings by noting to use plot_line_chart for time-series, and mentions alternative names like spider chart. The verb 'generate' and resources are explicit.

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

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

Explicitly tells when to use (user asks for spider/radar/web chart or multi-dimensional comparison) and when not to (time-series/trend data → plot_line_chart). Also includes a strong directive not to pre-fetch data using 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?

The description states that if persist=True, it 'materializes result as a volatile table and returns table name', implying a write side effect. However, annotations declare readOnlyHint=true and idempotentHint=true. The description contradicts these annotations by describing a potentially state-changing behavior. According to scoring rules, this contradiction results in a score of 1.

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 paragraphs: first for purpose/usage, second for arguments. It is reasonably concise and front-loaded, though the argument list is redundant with the schema. No unnecessary sentences. Slightly verbose but acceptable.

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 omits what the summary statistics actually contain; it only says 'summary statistics for ALL columns' without specifying which statistics (mean, count, etc.). Since there is no output schema, the description should elaborate on the return format. Additionally, the contradiction with annotations creates confusion about the tool's side effects. For a tool with no output schema and a complex return, more detail is 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% (all three parameters described in schema). The description lists the arguments but only restates information from the schema without adding new semantics. Baseline is 3, and the description does not exceed this.

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 'Get summary statistics for ALL columns in a table in a single call' and distinguishes from the sibling tool qlty_univariateStatistics for single column stats. The verb 'Get' and resource 'summary statistics for all columns' are specific and 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 provides when to use: 'when the user asks for an overview, profile, or summary of every field in a table.' Also provides when not to use and alternative: 'For detailed statistics on a SINGLE specific column... use qlty_univariateStatistics instead.' 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 indicate readOnlyHint=true and idempotentHint=true. The description is consistent and adds context: explains that setting persist=True materializes a volatile table and returns the table name, which is significant behavioral information 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 very concise: three sentences cover purpose, usage condition, and parameters. It is front-loaded with the main action, and each part serves a clear purpose. No unnecessary words.

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

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

Given the tool is straightforward (retrieving distinct values) and has no output schema, the description covers purpose, usage, parameters, and a special condition (missing column). It could mention limitations like performance on large columns, but overall it is complete for the tool's complexity.

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

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 usage semantics beyond the schema by stating that column_name must be specified and if missing, ask for clarification. Also explains the effect of persist parameter, which adds value over the schema description.

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

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

The description clearly states the tool retrieves unique values from a column, with specific verb 'Get the unique (distinct) values'. It distinguishes from sibling tools like qlty_columnSummary by specifying the exact use case (unique values/categories) and providing usage guidance.

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 what unique values, categories, or entries exist in a named column'. Provides action for missing column: 'ask for clarification before calling'. However, does not mention when not to use or alternatives, so not a perfect 5.

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 aligns and adds context: returns a column-level summary, and persist parameter materializes a volatile table. Adds 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 and well-structured with a usage paragraph and argument list. Slight redundancy between first two sentences ('list column names' vs 'column-level summary'). Still 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; description says 'column-level summary' but doesn't specify if it includes counts or just names. However, it explicitly distinguishes from qlty_rowsWithMissingValues, and the persist parameter behavior is explained. Adequate for a simple analysis 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 3 is appropriate. Description repeats parameter info but adds minimal extra context (e.g., 'Name of the database (optional)'). No significant improvement over 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?

Description clearly states the tool lists column names with NULL/missing values, specifying verb (list) and resource (columns in a table). Explicitly distinguishes from sibling 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?

Provides explicit usage: 'Use when the user asks which columns have nulls...' and 'Do NOT use to retrieve actual data rows — use qlty_rowsWithMissingValues'. Clear when-to-use and when-not-to-use with alternative tool named.

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, which the description does not contradict. The description adds behavioral context such as returning a list of affected column names and the effect of the persist parameter (materializing as a volatile table).

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 two paragraphs: the first states purpose and usage, the second lists parameters in a clear format. No unnecessary words, front-loaded with 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?

The tool has 3 parameters, one required, and no output schema. The description explains the return value (list of affected column names), the persist behavior, and usage context. It is sufficiently complete for the tool's complexity.

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

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 restates the parameter docs from the schema without adding new semantics beyond what is already in the structured field.

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 starts with a specific verb+resource: 'Identify which numeric columns in a table contain negative values.' It also provides usage context, differentiating it from sibling tools like qlty_columnSummary or 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?

The description explicitly says 'Use when the user asks about negative numbers, values below zero, or columns with anomalous negative entries.' This provides clear when-to-use guidance, though it does not explicitly state when not to use or name 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, so the tool is known safe. The description adds value by clarifying it returns actual rows (not summaries) and that the persist parameter materializes results as a volatile table, which is useful behavioral context.

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

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

The description is front-loaded with the core purpose and usage guidelines. It is concise but includes a redundant argument list that echoes the schema; while not verbose, it could be slightly tighter.

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 and 4 parameters, the description covers the tool's return type (rows), persist behavior, and usage context. It does not explicitly detail the output format when persist is false, but the overall picture is complete for common use.

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

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

Schema description coverage is 100%; all parameters are documented in the input schema. The description repeats this information in a bullet list without adding new semantics beyond the schema, meeting the baseline for high coverage.

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

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

The description clearly states it retrieves actual rows with missing values in a specified column. It explicitly contrasts with sibling tools base_readQuery and qlty_missingValues, making the tool's unique purpose unmistakable.

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 wants to see/fetch rows with null values) and when-not-to-use (do not write SQL, do not use for column summary). It names specific alternatives (base_readQuery, qlty_missingValues), leaving no ambiguity.

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 tool is read-only and idempotent. Description adds that it calculates mean and stddev, and explains the persist argument (materializes result as 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?

Two clear sentences followed by a concise argument list. Front-loaded purpose, no wasted words. Every sentence earns its place.

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

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

For a simple tool with annotations and no output schema, description covers behavior, usage, parameters, and alternatives. Complete and sufficient for agent to select and invoke correctly.

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

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

Schema coverage is 100% with parameter descriptions. Description repeats parameter info, adding no new semantic meaning beyond what schema provides. 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?

Description states it calculates mean and standard deviation for a single numeric column, with specific verb 'Calculate'. It distinguishes from sibling tool qlty_univariateStatistics, which provides a fuller profile.

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 the user asks specifically for standard deviation, the spread of values, or just mean and variability.' Also provides alternative: 'For a fuller statistical profile... use qlty_univariateStatistics 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. The description adds value by explaining that setting 'persist' to True materializes a volatile table and returns the table name, which is a behavioral trait 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 and well-structured: a clear purpose sentence, followed by usage guidelines, then a bulleted list of arguments. Every sentence is informative and earns its place.

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

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

No output schema, but the description lists the statistics computed (min, max, mean, sd, quartiles, percentiles), which covers expectations. It lacks details on return format but is sufficient given the tool's simplicity.

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 lists arguments with descriptions that mostly mirror the schema but do not add significant new meaning beyond what is already in the input schema.

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

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

The description clearly states the verb (calculate) and resource (full univariate statistics for a single numeric column) and distinguishes from siblings by explicitly naming alternatives for different scenarios (e.g., qlty_standardDeviation for just mean/std, qlty_columnSummary for all columns).

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 complete/comprehensive breakdown of one column) and when not to, providing specific alternative tools (qlty_standardDeviation, qlty_columnSummary) for other 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?

Description provides extensive behavioral details beyond annotations, including workflow steps, configuration, technical implementation, answering rules, language restrictions, and silent execution. No contradiction with annotations regarding idempotent, but readOnlyHint is contradicted by table creation.

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 very verbose, containing multiple sections with redundant or overly detailed information (e.g., full list of configuration values). While well-structured, it could be more concise without losing essential guidance.

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, lack of output schema, and zero parameter coverage, the description is thoroughly complete, covering all necessary aspects for correct invocation.

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

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

With 0% schema coverage, description fully compensates by clarifying the 'question' parameter expects a user query with optional /rag prefix and 'k' controls the number of chunks retrieved, with configurable default.

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 distinctly specifies it executes a complete RAG workflow for answering questions from document context triggered by /rag prefix, clearly differentiating from siblings like sql_Execute_Full_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?

Explicitly states RAG mode only triggers with /rag prefix and that no additional tools are needed, but does not discuss alternative tools or when to avoid 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?

The description does not contradict annotations (readOnlyHint=true, idempotentHint=true) and adds some context (requires role name, persist parameter behavior). However, with annotations already covering safety, the description adds minimal extra behavioral detail 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 and well-structured: a short first paragraph defining purpose and usage, followed by a brief argument list. Every sentence serves a purpose 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 tool is simple and the description covers purpose, usage, and parameters. The lack of an output schema is mitigated by the clear purpose; the description could mention the return format briefly, but it is still largely complete given the 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description repeats the same descriptions without adding new meaning, so it meets the baseline for full coverage without enhancing 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 lists database-level permissions for a Teradata role, using a specific verb and resource. It explicitly distinguishes from sibling tools sec_userDbPermissions and sec_userRoles, which handle user-level queries.

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

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

The description provides explicit guidance on when to use the tool (e.g., when user asks about a role's access rights) and warns against confusion with user-level queries, naming the alternative tools. This is a clear usage directive.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that it lists 'directly granted' permissions across all databases and explains the persist parameter's behavior, providing useful context 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 concise and well-structured: a first paragraph for purpose and usage, and a second for arguments. 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 the tool's complexity (listing permissions) and the absence of an output schema, the description could mention the output format or typical columns. It does not, but it covers purpose, usage, and parameters sufficiently.

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 replicates the schema's parameter descriptions without adding new semantic meaning. Therefore, it meets the baseline 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 clearly states it lists database-level permissions for a specific user across all databases, using specific verbs and resources. It distinguishes itself from the sibling tool sec_userRoles by explicitly contrasting their 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?

It provides explicit usage context: 'Use when the user asks what a named user can DO in each database.' It also gives a clear 'Do NOT use' condition for roles and directs to sec_userRoles, effectively guiding the agent.

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

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

Annotations already declare readOnlyHint and idempotentHint, so description doesn't need to repeat. It adds context about requiring a user name and mentions persist parameter 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?

Front-loaded with the main purpose, followed by clear usage guidelines and a brief arguments section. Every sentence adds value without 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 list tool with 2 params and no output schema, the description covers purpose, usage, and parameters. Could mention output format but not essential given simplicity. References sibling tools for 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 baseline is 3. The description mentions both parameters but doesn't add significant meaning beyond the schema. However, it indirectly provides context through the tool's purpose.

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 the roles currently assigned to a specific Teradata user account' with a specific verb and resource. It distinguishes from sibling tools sec_rolePermissions and sec_userDbPermissions by explicitly stating what not to use them for.

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 ('when the user asks which roles a named user HAS') and when-not-to-use ('Do NOT use to see the permissions of those roles – use sec_rolePermissions') with direct sibling references.

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 it as readOnly=true and idempotent=true. The description adds valuable context: it analyzes pre-computed stats without re-running the pipeline, lists analysis capabilities, and explains output format. 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?

Well-structured with headings, bullet points, and code blocks. Front-loaded with purpose, then detailed sections on capabilities, metrics, and usage. Every sentence adds value; no redundant or filler content. Appropriate length for the complexity.

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 thoroughly covers inputs (sorting metrics, limit), behavior (analysis of pre-computed stats), and output format (detailed cluster statistics). It also provides categorization, workflow, and decision framework. Complete for an analysis 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 has 2 params with 0% description coverage. The description compensates fully by listing all available sorting metrics with explanations (e.g., 'avg_cpu: Average CPU seconds'), describing the default behavior, and explaining limit_results usage. Adds significant meaning 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 analyzes pre-computed cluster statistics for optimization, with a specific verb ('analyzes') and resource ('cluster stats'). It distinguishes itself from sibling tools like sql_Execute_Full_Pipeline and sql_Retrieve_Cluster_Queries by focusing on analysis of existing data.

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 guidance including a typical workflow (sort by metrics, use limit_results), an optimization decision framework (e.g., High CPU + High Query Count = max impact candidates), and how to prioritize. Clearly differentiates from sibling tools by focusing on analysis rather than execution or query retrieval.

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 implies write operations (e.g., 'Creates vector store', 'Creates cluster statistics'), but annotations set readOnlyHint: true and idempotentHint: true. This is a direct contradiction. The description does not disclose that the tool writes to the database, despite mentioning sufficient space in feature_ext_db.

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, bold headers, and bullet points. It front-loads the purpose and workflow. Some redundancy could be trimmed, but overall it's organized for readability.

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

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

Given the tool's complexity (multi-step pipeline), minimal input schema, and no output schema, the description provides extensive context: full workflow steps, performance metrics explanations, configuration details, prerequisites, and follow-up tools. It is highly 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?

The input schema has 0% description coverage, but the description explains that optimal_k controls the number of clusters and max_queries limits the top queries by CPU time. It provides meaning beyond the schema's raw parameter 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 that the tool 'executes the entire SQL query clustering workflow' to identify high CPU usage queries. It distinguishes itself from siblings by detailing the full pipeline and referencing subsequent tools like sql_Analyze_Cluster_Stats and sql_Retrieve_Cluster_Queries as follow-ups.

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 includes an 'OPTIMIZATION WORKFLOW' section that explicitly tells when to use this tool and what tools to use after (e.g., sql_Analyze_Cluster_Stats). It also lists use cases and prerequisites, providing clear guidance on appropriate 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?

Beyond annotations (readOnlyHint=true, idempotentHint=true), the description details query extraction, performance metric association, automatic categorization by thresholds, and output contents. It fully informs the agent of the tool's behavior without 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?

Well-structured with headings and lists, but somewhat verbose—e.g., the 'DETAILED ANALYSIS CAPABILITIES' section partially overlaps with the workflow. Could be trimmed without losing meaning.

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

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

Covers all essential aspects: purpose, parameters, usage workflow, output contents, config thresholds, and categorization. Despite no output schema, the description provides a complete picture for an AI agent to correctly invoke and interpret results.

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

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

Despite 0% schema description coverage, the description compensates by listing available metric options (ampcputime, logicalio, etc.) with explanations, clarifying the meaning of 'metric'. It also addresses 'limit_per_cluster' via the query limit strategy. 'cluster_ids' is inherently clear from the context.

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

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

The description opens with a strong verb-resource pairing: 'RETRIEVE ACTUAL SQL QUERIES FROM SPECIFIC CLUSTERS FOR PATTERN ANALYSIS', clearly distinguishing it from sibling tools like sql_Analyze_Cluster_Stats (cluster-level stats) by focusing on actual query text and metrics.

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 an explicit workflow ('TYPICAL OPTIMIZATION WORKFLOW') stating to start with sql_Analyze_Cluster_Stats, and offers query selection strategies by metric. Lacks explicit when-not-to-use, but the workflow context gives clear guidance.

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