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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description's 'save a new report' is consistent, adding the useful detail that a new artifact is produced rather than an in-place update. It does not disclose whether prior reports are overwritten, permission requirements, or how cached intelligence is refreshed.

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 that states the action, inputs, and outcome with zero filler. Every clause 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?

An output schema exists, so return values needn't be explained, and the operation is simple with one parameter. However, the description omits prerequisite/permission context and any routing advice relative to the many sibling tools, leaving the definition only minimally 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% for the single report_id parameter, so the description must carry the burden. It refers to 'a saved inventory' and 'a new report' but never clarifies what report_id identifies or its required format, leaving the parameter's semantics under-specified.

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 scope: re-evaluate a *saved* inventory against *current cached intelligence* and save a new report. The word 're-evaluate' plus 'saved inventory' distinguishes it from siblings like audit_scan or audit_start, which imply fresh scans, without naming them 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 explicit when-to-use, when-not-to-use, or alternative routing. The phrase 'saved inventory' weakly implies an existing report is prerequisite, but the agent receives no guidance on choosing this over reports_compare, audit_scan, or intelligence_sync.

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=false, destructiveHint=false, and openWorldHint=false, and the description is consistent with them while adding real context: the scan relies on cached intelligence (no network call) and persists an evidence report as a side effect. It does not say where the report is written or whether prior reports are overwritten, but the safety/offline profile is well 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 dense sentences with the capability first and the safety constraint second; every clause carries information (scope, mechanism, output, safety). No filler or restatement of the tool name.

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, and the offline/non-mutating profile is covered. What remains missing for correct invocation is parameter meaning (sbom, device_info) and where the evidence report lands, which matters because the tool's side effect is the deliverable.

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 three parameters, so the description must compensate and largely does not. 'Local source/APK/IPA' hints that target is an artifact path, but sbom and device_info are left entirely unexplained in both schema and description, including their expected format and why they would be supplied.

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 (Inspect), a specific resource class (local source/APK/IPA), the mechanism (cached intelligence), and the outcome (saved evidence report). It implicitly separates itself from audit_start/audit_reassess by emphasizing 'local' and offline operation, but never names a sibling 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?

'No network or device mutation' functions as an implicit boundary condition, steering the agent toward this tool for offline artifact inspection. However, there is no explicit when-to-use vs audit_start or audit_reassess, and no stated prerequisites (e.g., whether intelligence_sync must run 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 declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, covering the safety profile. The description adds value beyond that by revealing this starts a persistent background job that must be polled rather than returning results inline, a trait absent from the 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?

A single front-loaded sentence that states the action first and then the follow-up routing. No filler, 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?

Output schema exists, so return values need not be explained, and annotations carry safety. However, with three undocumented parameters at 0% schema coverage, the definition leaves an agent guessing about sbom and device_info, a meaningful gap for a kickoff 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 adds no information about any of the three parameters (sbom, target, device_info). With low coverage the description was expected to compensate, and it provides nothing on parameter meaning 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?

States a specific verb (Start) and resource (audit) with a differentiating scope marker, 'persistent offline', that separates it from the one-shot audit_scan sibling. It does not open the schema to tell them apart, but the phrasing makes the async/background nature clear.

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

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

Explicitly routes the agent to jobs_status for progress and jobs_cancel to stop, which is useful lifecycle guidance. It does not address the more important selection question of audit_start vs audit_scan or audit_reassess, so it stops short of full alternative coverage.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the categories of information returned, but says nothing about auth requirements, idempotency, or whether it needs to be re-invoked, leaving the discovery semantics implicit.

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 that lists the four discovery categories with no filler. Nothing is padded or repeated, making it appropriately sized for a zero-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 explained, and annotations cover the safety profile. For a no-param discovery tool the description is nearly sufficient, missing only a hint about when in the workflow it should be invoked.

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?

Zero parameters, so there is no parameter semantics to document; the baseline for a no-param tool is 4. Schema coverage is vacuously complete, and no additional meaning is required from 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 verb 'Discover' plus an explicit enumeration (input types, evidence states, runtime requirements, available interfaces) makes it clear this is a self-describing discovery endpoint. However, it never states whose capabilities are being discovered (whole system vs. a subsystem) and gives no differentiation from siblings like runtime_devices or runtime_plan.

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 when-to-use guidance is given. A discovery tool would benefit from saying it should be called first/once at startup or as a prerequisite to runtime_plan, audit_start, etc., but nothing routes the agent relative to the 16 siblings.

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=false, openWorldHint=true and destructiveHint=false; the description usefully adds that it makes external OSV queries, mutates a cache of matches, and persists a reassessed report. It stops short of stating auth requirements or overwrite semantics for the cached matches, so it is helpful but not exhaustive.

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 that names the data source and the three effects with no filler. Efficient, though it packs three distinct actions without signaling their order or relative importance.

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, and annotations cover externality and safety. However, the combination of a mutation tool with a 0%-covered parameter and no usage guidance leaves the description short of what an agent needs to call it confidently.

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 single report_id parameter (default 'latest') is never mentioned in the description. The text refers to saving a report but never explains that report_id selects which inventoried report is checked, leaving the key input ambiguous.

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 specific verbs (query, refresh, save) tied to clear resources (OSV package matches, a reassessed report), so an agent understands this checks dependency versions against a vulnerability source. It does not differentiate from siblings like audit_reassess or intelligence_sync, which is the only clear gap.

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 statement of when to invoke this versus alternatives such as audit_reassess (which also produces reassessed reports) or intelligence_sync. The agent is left to infer the workflow context 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?

The description usefully discloses that refresh=true mutates state by fetching the official CNA record into a cache, which explains the otherwise surprising readOnlyHint=false on a tool whose description starts with "Read". It does not cover error behavior for unknown CVE IDs or rate limits, so it falls short of 5.

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 the primary action first and the optional flag's effect second. No filler, no redundancy, instantly scannable.

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, and the non-obvious cache side effect of refresh is covered. The remaining gap is the accepted format/validation of cve_id, which an agent should not have to guess.

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 carry parameter meaning. It explains refresh (fetches the CNA record into cache) but says nothing about cve_id format (e.g. CVE-YYYY-NNNN) or whether an unknown ID is an error, leaving one of two parameters undocumented.

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+resource ("Read an exact CVE") and the word "exact" implicitly distinguishes it from the lookup-by-query sibling intelligence_search. It is clear what the tool does, but it never names the sibling it differs from, so differentiation is inferred rather than stated.

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: "exact CVE" suggests this is the direct-ID path versus intelligence_search, and refresh=true is given a condition, but there is no explicit "use this when / use X instead" guidance and no statement of when to set refresh.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. 'Does not contact the network' largely restates openWorldHint=false, though 'cached' usefully signals potential staleness of results. No rate limits, freshness windows or result-shape notes are added.

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 and scope front-loaded and a single behavioral qualifier after it. No filler or 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?

An output schema exists, so return values need not be explained, and the annotations cover safety. However, for a low-coverage search tool, the absence of any query-format guidance or result-scoping notes leaves a real gap 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?

Schema description coverage is 0%, so both parameters carry their full burden in the schema titles alone. The description says nothing about whether 'query' is free text, a CVE ID, a keyword set, or how 'limit' interacts with results, leaving the agent to guess at query syntax for a search 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?

States a specific verb (search) and resource (cached CVEs and OWASP tests), with the 'cached' scope narrowing it versus the sibling intelligence_get and intelligence_sync. It is clear what the tool does, though it never explicitly names a sibling or the boundary between 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives among siblings like intelligence_get or intelligence_sync. The agent must infer that this is the free-text search path and that the others are direct-fetch or refresh paths.

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=false, openWorldHint=true and destructiveHint=false, so the agent knows this reaches external sources and mutates local state without being destructive. The description usefully adds that it updates a local cache and reports per-source failures plus scope, but omits whether the sync is blocking, whether it overwrites existing cached advisories, and any auth or rate-limit 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?

Two short sentences with no filler, and the primary action is front-loaded ahead of the return-value note. It is efficient, though 'scope' is left unexplained and reads as an afterthought.

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 restated, and the description does gesture at per-source failures. However, for a non-read-only tool with an open-world dependency and two completely undocumented parameters, the definition leaves too much unstated to call it 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% and neither of the two parameters is described in the schema. The description never mentions 'limit' or 'sources', so an agent gets no help understanding what limit bounds or what source identifiers are valid — a real gap for a tool whose only inputs are these two fields.

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 pair (fetch + update local cache) and a concrete resource (official public mobile advisories), which separates it from read-only siblings like intelligence_get and intelligence_search. It stops short of explicitly naming those siblings as the non-sync alternatives, so it is clear but not fully differentiated.

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

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

No guidance on when to run a sync versus calling intelligence_search or intelligence_get directly, no mention of prerequisites, freshness needs, or how often it should be invoked. The agent must infer the trigger condition entirely from the name.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false but say nothing about timing. The description adds that this is a *request* (not synchronous) and that the job reaches a terminal state observable via jobs_status — genuinely useful context beyond the annotations. It stops short of noting reversibility or permission requirements.

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 sentence, front-loaded with the action and followed by the essential next step. 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?

Output schema exists, so return values need not be explained, and the async workflow is conveyed. For a mutation tool with no explicit permission or reversibility notes, a small gap remains.

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% for the single job_id parameter, so the schema gives no semantic help. The description only implies through 'authorized job' that the id must belong to a job the caller is permitted to cancel, adding minimal 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?

States a specific verb and resource ('Request cancellation of an authorized job') and implicitly contrasts with the polling tool it names, jobs_status. It doesn't distinguish itself from other job-related siblings like jobs_list, but the action is 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?

Provides clear follow-up guidance: 'poll jobs_status until terminal,' which tells the agent this is asynchronous and how to complete the workflow. It does not state when cancellation is inappropriate (e.g., already-terminal jobs) or name any exclusion.

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 presents a pure enumeration operation ('List background jobs'), while the annotations declare readOnlyHint=false, meaning the tool is not guaranteed to be side-effect free. The description offers no explanation of what non-read-only behavior occurs, and no pagination or ordering behavior 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?

One short, front-loaded sentence with no filler, so it reads cleanly. It is terse to the point of under-specification, but there is no wasted or redundant text to penalize.

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 an output schema present, return values need not be explained, and the tool's complexity is low (one optional parameter). However, the limit/pagination semantics and the tension with the non-read-only annotation leave real gaps 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?

Schema description coverage is 0% and the single 'limit' parameter (default 20) is never mentioned in the description, so its meaning, range, and pagination implications are undocumented anywhere. The description does not 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 (List) and resource (background jobs) plus a scoping qualifier ('visible inside this server's configured roots'), which is more than a tautology. It does not explicitly distinguish itself from siblings jobs_status and jobs_cancel, but the verb choice makes the read/enumerate role inferable.

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 'inside this server's configured roots' implies the context in which listing makes sense, but there is no explicit when-to-use guidance and no mention of the sibling alternatives jobs_status or jobs_cancel for inspecting or cancelling a specific job.

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 asserts a pure read operation ("Read durable job state and progress"), but the annotations declare readOnlyHint=false, meaning the tool may modify state. That is a direct contradiction of the behavioral claim in the text. The remaining sentence adds no concrete behavior such as polling cadence, terminal state semantics, or error conditions.

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, front-loaded with the action, which is good. The second sentence is atmospheric and ambiguous rather than informative, so it does not clearly earn its place in a definition this terse.

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 job-polling tool the description omits the essential context: how the job_id is obtained, how to interpret completion vs. failure, and how this differs from jobs_list. Combined with the annotation contradiction, this leaves the agent under-informed.

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% for the single job_id parameter, and the description says nothing about its format, or where the id comes from (presumably audit_start or jobs_list). The name is largely self-explanatory, which prevents a 1, but the description does nothing to compensate for the missing schema documentation.

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?

"Read durable job state and progress" states a specific verb (Read) and resource (job state/progress), so the core purpose is unambiguous. It does not, however, distinguish itself from sibling job tools such as jobs_list or jobs_cancel, leaving the agent to infer the boundary from the name 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 explicit when-to-use, when-not-to-use, or alternative guidance. The agent must infer that this is called after audit_start to poll a job, and the cryptic line "an interrupted worker never becomes a successful audit" reads as an aphorism rather than a usage rule. None of jobs_list, jobs_cancel, or audit_scan are referenced as 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, destructiveHint=false and openWorldHint=false, so 'without changing reports' is largely redundant with structured data. The description does add domain context by naming the three classes of policy checks performed (thresholds, coverage requirements, expiring waivers), which goes slightly beyond the annotations, but says nothing about required inputs, permission needs, or failure 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 front-loaded sentence with no filler or repetition, and the non-mutating constraint is placed at the end where it reads naturally. It is efficient, though the packed enumeration of policy check types makes the sentence dense without adding usable operational 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, but the tool has three parameters at 0% schema coverage and no usage guidance, so an agent cannot reliably construct a call — particularly the required policy_path. The description is too thin for a parameterized evaluation 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% for three parameters, so the description carries the full burden and fails to meet it. It never mentions policy_path (the sole required parameter), report_id, or baseline_id, leaving format, expected values, and the meaning of 'latest'/null defaults entirely undocumented.

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?

Names a specific verb (evaluate) and enumerates the policy objects being checked (team thresholds, explicit coverage requirements, expiring waivers), which tells an agent this is a policy-compliance evaluation rather than a report mutation. However, it never distinguishes itself from plausible siblings like reports_compare or audit_scan, so the agent must infer where it fits.

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 when-to-use or when-not-to-use guidance, and no alternative tool is named. The only directional signal is the trailing phrase 'without changing reports', which implies a read-only, non-mutating context but does not say when this should be preferred over reports_compare or dependency_check.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context about the comparison semantics ('retaining coverage differences and unproven remediation states'), which tells the agent what the diff preserves rather than normalizes away. It remains terse and jargon-heavy, and says nothing about cost or ordering of the two inputs.

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 core action leads and the retention clause follows. The dense phrasing ('unproven remediation states') is compact but requires domain familiarity.

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, and the safety profile is covered by annotations. Still, for a two-required-parameter comparison tool with zero schema coverage, the definition omits where the IDs originate and how the two inputs are ordered, leaving a real gap an agent would hit.

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, and it partially does by establishing that both parameters are report IDs ('exact report IDs'). However, it does not clarify the before/after ordering semantics, ID format, or whether the IDs must come from the same target, leaving the bare 'Before'/'After' schema titles to carry the rest.

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 resource (report IDs), and 'exact report IDs' distinguishes it from the filter-based reports_list / reports_get siblings. It is clear what the tool does, though it never names a sibling 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, no prerequisite stating where the two IDs come from, and no mention of alternatives such as reports_get for inspecting a single report. The agent must infer that this tool is selected whenever two known report IDs need a diff.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the mode switch (context vs. finding evidence) on top of that; it discloses nothing about defaults, error behavior, or scoping that isn't in 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?

A single front-loaded sentence with no filler; the two retrieval modes are stated inline rather than buried. It is efficient, though arguably terse to the point of under-specification.

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, and read-only annotations cover safety. What is missing is the meaning of the 'latest' report_id default and whether finding_id can be used without a report_id — usable, but not complete for a 2-param tool at 0% schema coverage.

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 carry the load. It meaningfully ties finding_id to 'the exact evidence for one finding ID', but says nothing about report_id, its 'latest' default, or the null default for finding_id — leaving half the parameters unexplained outside the bare schema.

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

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

States a specific verb ('Read') and resource ('report context' / 'evidence'), and distinguishes two retrieval modes (whole report vs. one finding's evidence). It does not, however, differentiate itself from siblings like reports_list or reports_compare, which a 'get' tool sharing that namespace arguably needs.

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 implied rather than stated: supplying a finding ID selects the evidence mode, omitting it reads report context. There is no explicit when/when-not guidance and no mention of the sibling tools an agent should consider instead (reports_list, reports_compare).

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds that the output is 'saved audit IDs', which is useful context, but says nothing about pagination behavior or result set size despite the limit parameter.

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, which is efficient. It may be slightly too terse to carry the tool's scope, but 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?

An output schema exists, so return-value detail is not required, and the safety profile is covered by annotations. However, for a list tool the description omits pagination/limit behavior and gives no relationship to reports_get or reports_compare, leaving gaps an agent would want filled.

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 never mentions the 'limit' parameter or its default of 20. With one undocumented optional parameter, the description fails to compensate for the schema gap, leaving pagination semantics entirely unstated.

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 ('List') and resource ('saved audit IDs') and hints at its role as a lookup step ('for exact follow-up reads'), which faintly distinguishes it from reports_get/reports_compare. It does not explicitly name a sibling or clarify the 'audit IDs vs reports' naming mismatch, so it falls short of full differentiation.

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 exact follow-up reads' implies the workflow (list IDs, then read them individually), but there is no explicit when-to-use statement, no when-not, and no named alternative such as reports_get. Usage is only 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?

The description adds the behavioral note 'without changing app state,' which reinforces the read-only nature but is somewhat redundant with the readOnlyHint annotation. It does not disclose other traits like output format details, though the annotations already cover safety and open-world aspects.

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, efficient sentence with no unnecessary words, front-loading the core purpose clearly.

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 parameters, read-only annotations, and an output schema), the description adequately conveys the core action. It could mention when to use it, but for a listing tool, the essential information is present.

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 has no parameters, so the baseline score is 4. The description does not need to explain any parameters, and the schema coverage is 100% for the empty object.

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 (List) and resources (adb devices and iOS simulators), making the tool's function unambiguous and easily distinguishable from siblings like runtime_plan.

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?

Offers no guidance on when to use this tool versus alternatives, nor any prerequisites or context. It simply describes what it does without indicating appropriate scenarios or 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context by clarifying that the generated scenario is editable and will not be executed or trigger automatic logout. It does not cover permissions, persistence, or other operational details, but that is a modest gap given 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 short and front-loads the core action in the first sentence, with the caveat immediately after. It is efficient with no filler, though its brevity means it omits important parameter 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?

An output schema exists, so return values need not be explained here, and annotations cover the safety profile. Still, for a tool with three optional inputs, no schema descriptions, and ambiguous scope, the description should say more about what the scenario is based on and how package/platform/report_id shape it.

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 any of the three parameters (package, platform, report_id). It adds no meaning about what these inputs select or how they affect the generated plan, leaving the agent with only bare parameter names.

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 verb and object: 'Generate an editable test scenario.' However, 'test scenario' is vague without saying what domain or system it applies to, and no sibling tool is named or contrasted, so an agent must infer the tool's precise role among runtime and audit siblings.

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 second sentence provides an important usage boundary: it does not run the scenario or log out the app automatically. That implies the tool is for planning only, but it does not state when to choose it over alternatives such as audit_start or runtime_devices, nor does it describe prerequisites.

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