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

No annotations are provided, so the description carries the behavioral burden. The verb 'Read' implies a non-mutating operation, and the listed fields clarify what is returned. However, it does not disclose behavior for missing scan IDs, whether data is live or cached, or any other edge-case 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?

A single sentence that front-loads the operation and lists specific data elements. Every word earns its place with no redundancy.

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

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

For a simple one-parameter tool with an output schema, the description is mostly sufficient. However, the close sibling get_scan_results creates ambiguity, and without explicit differentiation or parameter explanation, an agent may not reliably choose the correct 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%, and the description does not mention scan_id at all. The parameter name and type are self-explanatory, but the description adds no meaning beyond the schema, so it fails to compensate for the low 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 names a specific verb ('Read'), a resource ('scan'), and enumerates the exact data returned: status, progress, timestamps, and severity summary. This distinguishes it from the sibling get_scan_results, which likely returns detailed findings rather than a summary.

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

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

No guidance is given about when to use this tool instead of siblings like get_scan_results or list_scans. The agent must infer that get_scan is for a single scan's status, which is not explicitly 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does this reasonably well: 'Read' signals a non-mutating operation, and 'false-positive status' indicates what kind of state is included. It does not cover error behavior or edge cases, but nothing suggests side effects or destructive 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?

A single sentence delivers the core purpose and the most behaviorally important detail. There is no filler, and the information is immediately usable.

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 one required parameter and an output schema, so the description does not need to enumerate return fields. It covers what the tool reads, the input condition, and an important output nuance. It could mention what happens for incomplete or missing scans, but that is not essential for a simple read 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?

With 0% schema description coverage, the description must compensate for the scan_id parameter, but it does not explain its semantics beyond the implied 'the scan whose findings are returned.' No format, examples, or additional constraints are provided, so the parameter meaning is left mostly to the schema's name and 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 names a specific verb ('Read'), a specific resource ('completed scan findings'), and an extra distinguishing detail (false-positive status). This clearly separates it from siblings like start_scan or list_scans, and an agent can infer what the tool returns.

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 word 'completed' gives a preconditions signal, so the agent knows results are only meaningful after a scan finishes. However, there is no explicit guidance about when to prefer get_scan_results over the closely related get_scan tool, nor any stated 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 provided, the description carries the behavioral disclosure burden, and 'List' strongly implies a read-only operation. It also adds useful behavioral detail by specifying that only active projects are returned and that each project includes its most recent scan. Minor caveats like ordering or empty-result behavior are not mentioned, but they are not critical for a simple listing tool.

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

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

The description is a single sentence with no filler, and the action and resource are front-loaded. Every phrase contributes meaning, making it easy for an agent to parse quickly.

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 parameterless listing tool with an output schema, the description is largely complete: it identifies the resource, the active filter, and the scan detail included in results. It could be slightly stronger by explicitly signaling read-only safety or clarifying its relationship to list_scans, but the low complexity makes these gaps minor.

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

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

The tool accepts zero parameters, so the schema already covers all parameter semantics vacuously. The description adds value by indicating what the result includes—active projects with their most recent scan—which is the relevant semantic content for this 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 uses a specific verb ('List') with a clear resource ('active DefAudit projects') and adds the distinctive result detail ('their most recent scan'). This clearly differentiates it from sibling tools like list_scans, which focus on scan records rather than projects.

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 conveys a reasonable sense of scope—listing active projects—but does not explicitly say when to choose this tool over list_scans or how it relates to the scan-focused siblings. The intended usage is implied by the tool name and sibling names rather than stated directly.

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 present, so the description carries the behavioral burden. It adds a useful constraint ('Limit must be between 1 and 100') and implies a read-only listing, but does not explain ordering, pagination, or permissions.

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

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

Two short sentences with no filler; the purpose and the limit constraint are front-loaded and 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?

The tool is simple, has an output schema, and the description covers its core operation and the key limit constraint. Minor gaps like sorting semantics do not prevent correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It maps project_id via 'for a project' and gives the valid range for limit, but it does not clarify optionality or other constraints.

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

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

The description states a specific verb and resource ('List recent scans for a project'), making the tool's purpose clear. It is distinguishable from siblings like list_projects and get_scan, though it does not explicitly call out which sibling to use 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 phrase 'for a project' implies the intended context: retrieve scans scoped to a project_id. There is no explicit when-to-use or exclusion guidance compared to sibling tools like get_scan or get_scan_results.

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 must carry the behavioral burden. It adds useful context by disclosing that the operation affects not only the given finding but also 'matching findings in the project,' and that a reason is mandatory. However, it does not disclose other behavioral traits such as permissions, reversibility, idempotency, or consequences of the broad matching scope.

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 short sentences with no filler. The primary action and scope are front-loaded, and the required reason is stated immediately afterward. 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?

For a simple two-parameter mutation, the description covers the key invocation details: what to mark, the project-level scope, and the required reason. However, it leaves 'matching findings' undefined, which is a significant ambiguity for an agent deciding whether calling the tool might affect a broader set of findings than expected.

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 should compensate, but it adds little beyond the schema. 'Finding' and 'reason' are obvious from the parameter names and titles, and the requirement that reason is mandatory is already in the schema's required list. The description does not explain what 'matching findings' means for finding_id or what constitutes an acceptable reason.

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 identifies the action ('Mark... as false positives'), the resource ('a finding and matching findings in the project'), and the requirement ('A reason is required'). It is distinguishable from the sibling unmark_false_positive by the 'false positive' direction, though it does not explicitly name 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?

The description implies the tool is for suppressing false positives but gives no explicit when-to-use guidance or exclusions. It does not mention the sibling unmark_false_positive or any situation where a different tool should be preferred, so the agent must infer usage context from the name and action.

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 behavioral burden. It adds meaningful detail that omitting branch selects the project default, but it does not disclose whether the scan runs asynchronously, what side effects occur, or what response to expect beyond the provided output schema.

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

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

Two short sentences, with the core action first and the optional-branch rule second. Every word earns its place and no schema information is repeated.

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

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

For a two-parameter tool with an output schema, the description is nearly complete: it identifies the required project context and the optional branch behavior. It falls short only in not clarifying asynchronous execution or common failure modes, which are useful but not essential for invoking the 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 only that branch is optional and defaults to the project default; project_id is only glossed as belonging to an existing project and lacks guidance on how to obtain or validate 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 states a specific verb and resource: 'Start a security scan for an existing project.' This clearly differentiates it from sibling list/get/mark tools, which are about viewing or annotating scans rather than initiating them.

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 use case (starting a scan for an existing project) and the optional branch behavior, but it never explicitly contrasts this tool with alternatives such as list_scans or get_scan. There is no when-not-to-use or alternative 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 present, so the description carries the transparency burden. It does disclose a meaningful behavioral scope—the flag is removed from 'matching findings' as well as the single finding—but it does not clarify reversibility, idempotency, or what 'matching findings' means.

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

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

The description is a single, compact sentence with no filler. It front-loads the action and adds the important scope detail without wasted words, which is ideal for a one-parameter tool.

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 one-parameter mutation, the description conveys the core operation and scope, and the presence of an output schema reduces the need to explain return values. However, the lack of annotations, explicit usage guidance, and a definition of 'matching findings' leaves some ambiguity about side effects and prerequisites.

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

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

Schema coverage is 0%, and the description does not explicitly explain finding_id. However, the parameter is self-explanatory by name and title, and the description gives some context that the id selects a finding plus its matches. Still, the description does not fully compensate 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 states a specific action—'Remove the false-positive flag'—against a specific resource ('a finding and matching findings'). The scope wording also distinguishes it from the sibling mark_false_positive, so an agent can tell them apart without opening schemas.

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

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

The intended use case—undoing a false-positive marking—is strongly implied by the operation itself, but the description does not explicitly state when to use it versus mark_false_positive or provide exclusions. The guidance is inferred rather than stated.

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