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

No annotations are supplied, so the description carries the full burden. It does disclose two meaningful behavioral traits beyond the schema: only ACCEPTED findings are considered, and results are categorized as new/fixed/persisting. It says nothing about read-only nature, behavior with unknown or mismatched job IDs, or the ordering of the returned buckets.

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

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

One short sentence, front-loaded with the verb and scope, with the result categories parenthesized for quick scanning. No filler 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?

An output schema exists, so return values need no explanation, and the result-category hint is a useful addition. However, for a mutation-free but parameter-critical diff tool with zero annotation coverage, the unresolved direction of the comparison (a vs b) leaves a real gap an agent must guess at.

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 neither job_id_a nor job_id_b has a description. The phrase 'between two jobs' implies both parameters are job identifiers but never establishes which is the baseline and which is the comparison — the single most important semantic for a diff tool. The description therefore fails to compensate for the coverage 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?

States a specific verb (Compare) and a precisely scoped resource (ACCEPTED findings between two jobs), plus the three result buckets new/fixed/persisting. That scope wording separates it from get_job and get_finding, which fetch single objects, though it never names those siblings directly.

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

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

Usage is only implied: 'between two jobs' signals a two-job comparison, but there is no explicit statement of when to reach for this versus get_job, get_finding, or explain_finding, and no prerequisite guidance (e.g., that both jobs must exist or be completed).

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 behavioral burden. It does not disclose whether the operation is read-only, whether it requires permissions, whether it has side effects or costs, or what the "honesty contract" concretely guarantees. The only behavioral hint is that the output is in plain language.

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 short sentence with no wasted wording. However, the phrase "keeping the honesty contract" consumes space without adding actionable 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?

An output schema exists, so return-value details need not be repeated. Still, for a two-required-parameter tool with no annotations and no schema descriptions, the definition is too thin: it omits parameter meanings, relationship to `get_finding`, and any behavioral constraints.

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 says nothing about the two required parameters. One parameter can be loosely inferred from "a finding," but `job_id` is completely unexplained in both the schema and the 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 gives a clear verb and resource: "Explain a finding in plain language." It implies value beyond retrieving a raw finding, but does not explicitly name or differentiate itself from the sibling `get_finding` tool, and the phrase "honesty contract" is unexplained jargon.

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

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

There is no explicit guidance on when to use this tool versus `get_finding`, nor any prerequisites or exclusions. The only implied usage is that an agent should call it when a finding needs explanation.

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 behavioral burden. It discloses that findings may be accepted or retracted but says nothing about permissions, error behavior for missing ids, or whether the call is read-only, leaving significant gaps for a retrieval 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?

It is a single short sentence with no wasted words, and the key purpose is front-loaded. The terseness is efficient but borders on under-specification given the missing parameter detail.

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?

An output schema exists, so return values need not be explained, which lowers the burden. However, with 0% parameter coverage and no annotations, the description omits how job_id and finding_id relate and provides no behavioral context, leaving gaps for a two-parameter retrieval tool.

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

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

Schema description coverage is 0%, so both required parameters (job_id and finding_id) are undocumented. The description mentions only 'id' and does not clarify that both a job id and a finding id are required, nor their format or relationship.

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

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

States a specific verb and resource ('Fetch a single finding by id') and adds a scope qualifier that the finding may be accepted or retracted. It is distinguishable from siblings like list_jobs and explain_finding, though it does not explicitly contrast itself with get_job or explain_finding.

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

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

The description gives no explicit when-to-use guidance or alternatives; it does not say to use explain_finding for interpretation or scan_domains for discovery. The only implied usage is retrieval by id, which the agent must infer.

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, and it does disclose one real behavioral trait: findings are only returned once the job is done, so the tool is a status/polling endpoint. It omits other important traits — what statuses exist, whether it blocks, error behavior for unknown or expired job_ids, and whether results are stable after completion.

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

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

A single front-loaded sentence with no filler; the conditional clause is placed usefully right after the primary purpose. It is terse rather than wasteful, though the terseness is achieved by omitting needed context.

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?

An output schema exists, so return-value shape need not be explained. However, for an asynchronous job-status tool the description should at minimum say where job_id comes from and the polling expectation; those omissions leave the agent without the workflow context it needs.

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 for job_id is 0%, so the schema gives only a bare string type. The description does not explain the job_id format or, more importantly, where to obtain one (presumably from a scan tool's start response), which is exactly the gap the description should fill.

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 ('Fetch') and resource ('job status') and states the conditional payload ('if done) its findings'). The singular 'job' plus the required job_id distinguishes it from the sibling list_jobs, though it never names that sibling or get_finding explicitly.

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

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

There is no when-to-use guidance: nothing says to call this after scan_domains/scan_file, how often to poll, or when to prefer list_jobs or get_finding. Usage is only inferable from the noun 'job' and the parenthetical about completion.

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 supplied, so the description carries the full burden and does almost nothing with it. It does not disclose result ordering (newest first?), the time window implied by "recent", pagination limits, or the default page size, all of which materially affect how the tool behaves.

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 words are certainly front-loaded, but here brevity comes from under-specification rather than efficiency. The sentence is clean yet carries almost no information an agent could act on.

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?

An output schema exists, so return values need not be explained. But for a list tool with an undocumented limit parameter and no annotations, the description should at least define "recent" and describe result ordering and volume — none of which it does.

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 description coverage is 0%, so the lone `limit` parameter is undocumented everywhere. The description never mentions the parameter, its default of 20, or any maximum, so it fails to 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?

"List recent jobs" names a specific verb (List) and resource (jobs), so the basic action is clear. However, "recent" is never defined and there is no differentiation from siblings like get_job (single job retrieval) or diff_jobs (comparison), which an agent must infer on its own.

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

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

There is no when-to-use guidance, no statement of what selects this over get_job or diff_jobs, and no prerequisites or exclusions. The agent is left to guess the routing logic entirely.

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 and discloses almost nothing: it doesn't say whether the scan runs synchronously or returns a job handle, what permissions or rate limits apply, or what happens to results between runs. The phrase 'debug exposures' is undefined and gives no sense of what is actually detected or how invasive the scan is.

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?

It is a single front-loaded sentence with no wasted words, but the brevity reflects under-specification rather than density. There is nothing structurally wrong, just very little content.

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?

An output schema exists so return values needn't be described, but for a four-parameter scanning tool with a job-based sibling set, the definition omits the execution model, the meaning of suspected findings, and timeout behavior. The agent cannot tell whether it will receive results directly or a job to poll.

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?

All four parameters have zero schema description coverage and the description explains none of them. Critically, 'wait' (default true) implies a synchronous-vs-job execution mode that ties directly to the get_job and list_jobs siblings, and 'include_suspected' implies a confidence threshold, yet neither behavior is clarified anywhere.

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

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

States a specific verb and resource: scans a list of domains for exposed secrets and debug exposures. The domain-based scope implicitly separates it from the sibling scan_file, but it never names that alternative, so the differentiation is left for the agent to infer.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of when to pick this tool over scan_file or when to follow up with get_job or list_jobs. The agent must infer the workflow entirely from the sibling names.

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 behavioral burden, and it discloses almost nothing. It does not say whether scanning is synchronous or enqueues a job (siblings get_job/list_jobs strongly suggest async), what permissions are needed, or what happens by default. The only behavioral detail offered is the accepted file formats.

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 single sentence is front-loaded and free of waste, so it is not verbose. The problem is under-specification rather than excess, leaving it too thin for a four-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?

An output schema exists, so return values need not be described. But with no annotations, four undocumented parameters, and a job-oriented sibling set implying asynchronous execution, the description falls well short of what an agent needs to invoke this correctly.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate, and it largely does not. 'CSV or TXT' gives a hint about the path argument, but wait, timeout_s, and especially include_suspected (a non-obvious output-affecting flag) are left entirely unexplained.

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 verb 'scan' and resource 'a CSV or TXT domain list' are stated, and the accepted file formats narrow the input. However, it never explains what a 'scan' produces or how it differs from the sibling scan_domains, so an agent cannot confidently choose between them from the description alone.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to the obvious alternative scan_domains. An agent must infer from the name alone that this handles file-based input while scan_domains likely takes inline domains.

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