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

With no annotations provided, the description carries the full burden of behavioral transparency. It explicitly states what the tool does (pulls rule definition, taint trace, sink context, reconstructs source→sink path) and what it does not do ('nothing is written to the platform'). This clearly sets expectations for a read-only, context-assembly tool, which is highly transparent for a tool with no annotation support.

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 one-sentence summary at the start and clear elaboration. The final sentence ('Respond with a judgment...') is more of an instruction to the LLM than a description of tool behavior, but it does not add excessive bulk. Overall, it is well-structured and avoids unnecessary repetition.

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

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

The description is complete for a tool of this complexity. It explains the purpose, what data is pulled, what is returned, and the read-only nature. An output schema exists (not shown) which the description references, so return values are covered. No annotations are present, but the description provides enough context for safe use. It could be considered complete.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not. While parameter names (task_id, bug_id, context_lines) are somewhat self-explanatory, the description does not clarify their roles, how they relate to 'one defect', or the meaning of context_lines. This is a significant gap given the low 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 opens with a specific verb+resource: 'Assemble a judgment-ready audit context for one defect.' It clearly states what the tool does: pulls rule definition, taint dataflow trace, and sink code context, and returns them together with judging criteria and output schema. It distinguishes itself from siblings by combining these elements and explicitly noting that nothing is written to the platform, differentiating it from codesafe_submit_audit.

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

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

The description provides clear context on when to use the tool: to gather all necessary context for judging a single defect, with the verdict produced by the calling LLM. It also notes that nothing is written to the platform, implying it is for read-only analysis and not for submission. However, it does not explicitly name alternative tools or state 'use this instead of X', so it stops short of full alternative exclusions.

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

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

With no annotations, the description carries full burden. It discloses read-only behavior, the return format (contexts + summary table skeleton), the cap on number of items, and the internal process (resolving bugIds via codesafe_bug_summary). This goes beyond minimal requirements and gives the agent a clear behavioral model.

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 three sentences: purpose, process, and return/read-only. Every sentence contributes necessary information and is front-loaded with the core action. No waste or 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 has an output schema, so return values need not be fully described. The description covers purpose, dependencies, limits, and return structure, making it sufficiently complete for an agent to invoke correctly. Minor omissions like error handling are acceptable given the 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 0%, so the description must compensate. It explains max_n (cap), rule_code (the rule), and task_id indirectly via context. However, task_id is not explicitly defined, and the description does not detail each parameter's format or constraints. It adds some meaning but could be more explicit.

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

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

The description clearly states the tool's function: batch-assemble audit contexts for up to max_n defects of one rule. It specifies the action (batch-assemble), resource (audit contexts for defects), and scope (one rule, capped). This distinguishes it from siblings like codesafe_audit_bug (single audit) and codesafe_bug_summary (summary only).

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

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

The description implies when to use the tool: when auditing multiple defects under a single rule in batch. It also mentions the internal dependency on codesafe_bug_summary and the cap with CODESAFE_AUDIT_BATCH_LIMIT, providing context. However, it does not explicitly name alternatives or state when not to use it, though siblings make this inferable.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the data source (auditState field) and does not reveal whether the tool is read-only, how it behaves for invalid task IDs, error handling, or rate limits. The word 'summarize' hints at a read operation, but this is not explicit.

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

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

The description is a single, concise sentence of 11 words, with no filler, no repetition, and all information is front-loaded. Every word 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?

The tool is simple with one parameter and has an output schema that likely describes return values. The description gives a basic purpose but lacks parameter semantics and behavioral transparency. It is adequate for a basic status tool but leaves ambiguity about what task_id identifies and the exact content of the summary, making it incomplete for full autonomous 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?

The schema defines task_id as an integer, but the description does not explain what task_id refers to (e.g., that it represents the report ID). Since schema description coverage is 0%, the description should compensate by clarifying the parameter, but it does not add any 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 uses a specific verb 'summarize' and clearly identifies the resource: 'a report's audit progress', sourced from the 'platform auditState field'. This distinguishes it from sibling tools like codesafe_audit_bug or codesafe_submit_audit, which are about auditing bugs or submitting audits, not summarizing status.

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

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

The description implies the tool is used when a report's audit progress is needed, but it provides no explicit guidance on when to use this instead of alternatives, nor does it mention any exclusions or prerequisites. It simply states what the tool does without contextual usage direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses a significant quirk: 'The platform ignores the line range and returns the whole file, so we slice the requested [begin_line, end_line] window client-side with line numbers.' This goes beyond the obvious and tells the agent about unexpected platform behavior and how the tool compensates.

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

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

The description is two sentences long, front-loaded with the primary purpose and concise in explaining the necessary behavioral quirk. Every sentence adds value with no wasted words or 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?

Despite having an output schema, the tool lacks annotations and schema descriptions, so the description is the sole source of context. It covers the line range semantics and a key quirk, but omits usage differentiation and does not fully define all parameters. The description is adequate for a simple fetch but incomplete for a tool with four required, undocumented parameters.

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

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

With schema description coverage at 0%, the description must compensate. It clarifies the semantics of begin_line and end_line (1-based, inclusive, and the slicing behavior), but it does not explain task_id or bug_id in detail. The phrase 'for the file behind a bug' implies bug_id is the bug identifier, but task_id's role is left ambiguous. Partial compensation only.

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

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

The description clearly states the tool's function: 'Fetch a range of source lines (1-based, inclusive) for the file behind a bug.' It uses a specific verb ('fetch') and resource ('source lines'), making it distinct from siblings like codesafe_bug_summary or codesafe_bug_detail. The 1-based inclusive range is explicitly defined, leaving no ambiguity about the core operation.

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

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

The description provides clear context for when to use the tool (when you need source lines for a bug's file), but it offers no explicit guidance on alternatives or exclusions. It does not differentiate from sibling tools like codesafe_bug_detail, nor does it state 'use this instead of X when you need code.' The usage guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It clearly states what the tool returns (rule definition, dataflow trace, location, audit state). It is an honest read-oriented description, though it does not mention potential errors or access requirements. No annotation 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 a single sentence with a front-loaded verb phrase, followed by a colon and a clear enumerated list of contents. Every element earns its place, with no extra words or redundancy.

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

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

Given the output schema exists, the description adequately summarizes the returned content categories. However, it omits usage context and parameter semantics. For a retrieval tool, it is fairly complete, but the missing parameter guidance lowers it from a top score.

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

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

Schema description coverage is 0% and the description does not explain the two parameters (task_id and bug_id) or their relationship. The description's mention of 'defect detail' implies bug_id identifies the defect, but task_id is unaddressed. This is insufficient compensation for the lack of schema descriptions.

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

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

The description starts with a clear verb and resource: 'Get full defect detail'. It enumerates specific components (rule definition, taint trace, exact location, audit state), which distinguishes it from sibling tools like codesafe_bug_summary (summary) and codesafe_bug_code (code-only).

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

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

The description implies this tool is used for obtaining detailed defect information, but it does not explicitly state when to use it over alternatives. It lacks exclusions or comparison with sibling tools. Usage is implied rather than stated.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It transparently states that IDs are omitted by default and that include_ids=true yields a bounded sample, revealing default behavior and an option. It could mention id_limit's role, but the core non-obvious behavior (ID omission) is disclosed.

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, each serving a purpose: first states the action and use-case, second lists return fields and key parameters. No wasted words, front-loaded with the tool's 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?

The tool is simple and has an output schema, so the description need not detail return structure. It covers purpose, usage, and one key behavioral option. The 'bounded sample' phrase is slightly vague but does not undermine completeness for an aggregation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains include_ids ('set include_ids=true to include a bounded sample') but leaves id_limit to inference from 'bounded sample'. task_id is self-evident, but id_limit could be misinterpreted without explicit linkage. Partial compensation only.

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 'Aggregate' and identifies the resource 'defects by rule (from bugType)', clearly differentiating from sibling list/detail tools. It also states the intended use case ('Use this to pick a rule to audit'), making the tool's purpose unambiguous.

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

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

Explicit guidance is given with 'Use this to pick a rule to audit', telling the agent when to use the tool. It does not explicitly mention alternative tools, but the use-case focus and mention of omitted IDs imply when this is appropriate versus, say, listing raw bug details.

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?

Since no annotations are provided, the description carries the full burden. It discloses a key behavioral trait: the server ignores level/ruleCode filtering, so filters are applied client-side to a single page, possibly returning fewer than page_size results. This is beyond what the schema or name conveys. However, it does not mention permissions, safety, or return structure, which would be expected without 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: a single line overview followed by a focused NOTE. It front-loads the core action and then delivers critical caveat and alternative usage in two sentences. 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 covers the main behavioral caveat, points to alternatives, and provides missing context about filtering. Although it omits some parameter details, the output schema is present and the tool is a straightforward paginated list, so the overall context is sufficient for effective 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 0%, so the description must compensate. It clarifies that level and rule_code are filters (and explains their client-side limitation), and it mentions 'single page' and 'page_size' which relate to pagination. However, it does not explain task_id, page_index, or their roles, leaving gaps in parameter understanding.

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

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

The description opens with 'Page through defect instances,' which clearly specifies the action (paging) and resource (defect instances). It distinguishes this tool from siblings by noting the filtering limitation and recommending alternatives for complete filtered sets.

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: 'For a complete filtered set, use codesafe_bug_summary + codesafe_audit_by_rule.' This tells the agent when not to use this tool and names specific alternatives, which is exactly what usage guidelines should do.

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

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

With no annotations, the description carries the full burden. It discloses the return structure ('totalCount and quickVOS, each carries taskVO.pkTask / taskName / taskStatus / language, plus owner and time'), which is helpful. It does not explicitly state read-only behavior, but 'list' implies it. It adds return structure beyond what annotations would 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 two sentences long, front-loaded with the main purpose, then efficiently adds return field info and a usage pointer. Every sentence earns its place 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?

Given the simplicity of the tool (two pagination parameters, an output schema), the description is largely complete: it explains the return structure and hints at downstream usage. It could be improved by mentioning that page_size and page_index control pagination, but that is inferable from parameter names.

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

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

Schema description coverage is 0%, so the description must compensate for parameter understanding. It does not mention page_size or page_index at all, nor explain pagination behavior. The schema provides only names and defaults, leaving agents to guess their semantics. This is a significant gap.

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

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

The description clearly states the tool's function: 'List quick-check scan tasks.' It specifies the resource (quick-check scan tasks) and the verb (List), distinguishing it from sibling tools like codesafe_list_bugs. It also mentions the return fields, making the purpose undeniable.

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

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

The description implies usage context: 'Use a pkTask as taskId below.' This tells agents that this tool is meant to obtain task IDs for subsequent operations. However, it does not explicitly discuss when to use this over alternatives, though sibling names help.

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

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

No annotations are provided, so the description fully discloses the mutation behavior, dry-run default, environment variable requirement, confirmation flag, and the verification that raises if no state change occurs. This is rich behavioral context beyond any structured fields.

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

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

The description is well-structured with a clear purpose statement, a parameter breakdown, and a warning section. It is dense but not bloated; every sentence adds necessary information.

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

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

For a 4-parameter mutation tool with no annotations and no schema descriptions, this description covers purpose, all parameter semantics, safety behavior, and verification. Since an output schema is present, return values need no explanation, making the description contextually 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 schema has 0% description coverage, so the description compensates thoroughly by explaining the audits array structure, bugId/pkResbug alternatives, auditResult/verdict mapping, and dry_run/confirm_write semantics. However, task_id is not explained beyond being required, leaving a small 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 opens with a clear verb and object: 'Write audit verdicts back to the platform', and specifies the exact endpoint and UI effect. It explicitly distinguishes itself from sibling tools by stating it is the only tool that mutates the platform.

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

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

The description gives clear usage context: it is the only mutation tool, so it should be used for persisting verdicts while siblings are read-only. It also advises to prefer dry_run first and write in small batches, providing explicit when-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It describes what data is returned (metadata, code statistics) but does not state that the operation is read-only, whether it has side effects, or any relevant limitations. Since 'get' implies read-only but is not explicit, the transparency is insufficient.

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

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

The description is a single concise sentence that front-loads the core purpose and includes specific examples of the output (file/line counts, template, times). Every word contributes value, with no unnecessary repetition or filler.

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

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

The tool is simple, with one parameter and an output schema (present, though not shown). The description covers the key aspects of what is returned and is adequate for a straightforward fetch operation. However, it falls short of full completeness by not explicitly stating the read-only nature or providing usage context with siblings.

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

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

The schema has one parameter (task_id) with 0% description coverage, and the tool description does not explicitly mention or explain task_id. The phrase 'a task's' implies an identifier is needed, but the description fails to compensate for the lack of schema documentation by explaining the parameter's role or format.

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

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

The description clearly identifies the tool's action (get) and resource (a task's metadata and code statistics), with specifics like file/line counts, template, and times. This distinguishes it from sibling tools like 'codesafe_list_tasks' (lists tasks) and 'codesafe_bug_summary' (specific to bugs).

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

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

The description implies the tool is for retrieving details of a single task, which suggests using it when you need a task's summary rather than a list or bug-specific info. However, it does not explicitly state when to use this over alternatives or mention any exclusions, leaving the guidance implicit.

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