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

With no annotations, the description carries the full burden of behavioral disclosure. It honestly states that the tool is cheap, returns only sensitivity likelihoods, and does not certify safety or provide security conclusions. This is valuable caveat-level transparency, though it does not mention caching behavior, side effects, or operational details.

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

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

The description is two tight sentences with no filler. The purpose is front-loaded, and each clause adds meaning: cost profile, decision purpose, output scope, and a caveat. This is an efficient structure.

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 purpose and output caveat are present, but the description is incomplete for a tool with six parameters and zero schema descriptions. It does not say what inputs the agent must supply or how the returned likelihoods map to the go/no-go decision. Output schema existence helps, but the description alone leaves invocation details to inference.

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 provides no guidance on any of the six parameters. It does not explain the role of task_goal, diff_summary, changed_files, requirements, client, or use_cache. With zero coverage, the description was expected to compensate but does not mention parameters at all.

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

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

The description clearly states a specific purpose: 'Cheap change-risk triage to decide whether a more expensive frontier review appears warranted.' It also defines the output scope, 'sensitivity likelihoods only,' which separates it from final security assessments. However, it does not explicitly differentiate from the sibling tools, particularly 'jev_triage_failure,' which also uses triage language.

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 a clear usage context: use this cheap triage to decide whether a more expensive frontier review is necessary. It also warns against over-interpretation with 'These are not security conclusions and do not certify safety.' It does not name specific sibling alternatives or when not to use them, but the decision-oriented framing is helpful.

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. It discloses the tool's lightweight nature, its output (per-requirement likelihoods and review-warranted items), and its non-certification limitations. It does not mention side effects or external dependencies, but the key behavioral boundaries are present.

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

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

The description is three concise sentences with the main purpose front-loaded. Every sentence adds value: what it does, when to use it, what it returns, and what it cannot vouch for. There is 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?

The description gives solid selection guidance and output expectations, and an output schema exists so return values are covered. However, for a tool with five parameters and nested objects, it leaves the construction of task and implementation inputs unexplained. It is adequate but not fully self-sufficient 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 the description must compensate for parameter meaning, but it does not. It hints at 'requirements' and 'evidence' but does not explain the roles of task, implementation, verification, use_cache, or client. This leaves most parameters semantically 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 clearly names a specific verb and resource: a cheap requirement/evidence coverage check performed before an expensive full-task review. It distinguishes the tool from a full review, though it does not explicitly differentiate it from the listed sibling tools by name.

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

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

It gives an explicit use case ('Use on large tasks with explicit requirements') and a clear boundary ('Never certifies correctness, safety, or merge readiness'). It does not name alternative sibling tools, so the guidance is strong but not fully explicit on what to use instead.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is 'cheap', returns 'likelihood signals only', and explicitly states it does not confirm existence of vulnerabilities. This provides meaningful behavioral insight. However, it doesn't disclose potential side effects, rate limits, or specifics about the output format beyond likelihood signals. The return type is disclosed as 'likelihood signals only', which is a positive disclosure.

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

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

The description is extremely efficient: two sentences. It conveys purpose, use context, and an explicit limitation. Every word earns its place, and the key constraint ('likelihood signals only') is front-loaded near the end of the first sentence. This is textbook conciseness.

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

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

The tool has an output schema (though not provided in detail here), 5 parameters of which only 2 are required, and a clear differentiation from siblings. The description covers the core purpose, the triage context, and the critical limitation. It doesn't detail the 'likelihood signals' format or what the output schema looks like, but that is likely covered by the output schema itself. This is complete enough for an agent to decide when to invoke.

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 coverage is 0% in terms of parameter descriptions; all parameter semantics come from the schema structure alone. The description does not enumerate or explain individual parameters. However, the description gives context about 'triage' and 'normalization' which helps interpret the role of findings and task_goal. Given the 0% coverage, the description could do more to explain parameters, but the schema itself has reasonably descriptive names (finding, task_goal, requirements). Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb ('classification'), resource ('review findings'), and context (cheap normalization from multiple sources). It also distinguishes itself from siblings by mentioning 'triage' and 'likelihood signals only'. The description differentiates from sibling tools by framing this as a cheap pre-filter before expensive reasoning, which is unique among the listed 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 description explicitly states when to use it ('to triage a large finding set before expensive reasoning') and what it does not do ('Does not confirm that a vulnerability or defect exists'). It implies when not to use it (when confirmation is needed), though it doesn't name specific alternative sibling tools. The usage context is clear and actionable.

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 discloses that the tool is 'cheap' (cost/performance signal), returns 'stuck/progress signals and an advisory control signal,' and explicitly does not choose the next fix. This goes beyond the schema and annotations (which are absent). It doesn't mention side effects or failure modes, but for a read-only comparison tool, the disclosed behavior is reasonably complete.

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

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

The description is three sentences, each with a distinct purpose: what it does, when to use it, and what it returns/doesn't return. It is front-loaded with the core action and scoped efficiently. No wasted words.

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

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

The description is complete for a comparison tool: it states the trigger condition, the output type, and the limitation. The output schema exists, so return values are partially documented. The main gap is that the Attempt object's fields are not semantically explained, but the schema provides their names and types, and the description's 'stuck/progress signals' gives a high-level sense of the output.

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 carries the burden of explaining parameters. The description names the key inputs ('two unsuccessful implementation attempts') and the output signals, but it does not explain the individual fields within the Attempt object (failure, approach, hypothesis, diff_summary, changed_files) or the client metadata. The schema provides field names and types, but the description adds no semantic detail about how these fields are used in the comparison.

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 ('compare'), a specific resource ('two unsuccessful implementation attempts'), and a clear scope ('cheap comparison'). It also distinguishes itself from siblings by noting it 'does not choose the next fix,' which helps an agent understand its role relative to other jev_* tools.

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

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

The description explicitly says when to use it: 'Use when repeated work may be spending frontier inference on the same failed strategy.' This gives a clear trigger condition. It also states what it does not do ('does not choose the next fix'), which helps an agent avoid over-trusting the tool's output.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: it only evaluates supplied evidence, returns calibrated probabilities, and rejects generative requests. This gives the agent a clear behavioral model, though it doesn't cover potential errors or rate limits.

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?

Three sentences with no filler. The core purpose is front-loaded, and each sentence adds distinct information: what it does, what it rejects, and a key behavioral caveat.

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 nested objects and 4 parameters, but the description covers only the general behavior. It doesn't explain the structure of questions, the role of state, or client metadata. For a tool that requires evidence, it doesn't specify where evidence goes.

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 hints at questions holding propositions and evidence being supplied, but it doesn't explain state, client, or use_cache. This leaves most parameters underspecified.

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

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

The description clearly states the tool's function: asking one evidence-grounded yes/no proposition per question and receiving calibrated probabilities. It also mentions what it rejects. However, it does not explicitly differentiate from sibling judgment tools, relying on 'generic' to imply its role.

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

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

The description implies usage by calling it a 'generic bounded judgment primitive' and notes it rejects generative requests, which is a when-not. It does not provide explicit guidance on when to prefer this over sibling tools like jev_assess_risk or jev_triage_failure.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is 'cheap' and 'ranks only; never deletes or permanently excludes candidates', establishing that this is a non-destructive, side-effect-free operation. It doesn't mention caching or output specifics, but the core behavioral traits are disclosed.

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

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

Two sentences with no filler. The core purpose is front-loaded, the usage condition follows immediately, and the non-destructive guarantee is stated succinctly. Every word earns its place.

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

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

The description is sufficient for an agent to know when to call this tool and what it does, including the key safety property. An output schema exists, so return values needn't be explained. The main gap is lack of parameter detail, but the tool's simple concept and clear parameter names make this a relatively minor omission.

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

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

Schema description coverage is 0%, so the description must compensate for parameter understanding, but it does not describe parameters at all. While parameter names like task_goal, current_step, and candidates are somewhat self-explanatory, the description adds no semantics beyond the schema's literal titles. This is a significant gap for a 5-parameter 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 states a specific verb ('ranking') and resource ('repository context candidates') and distinguishes this tool from sibling tools like jev_assess_risk or jev_judge. It precisely describes the tool's role as a preliminary filter before deeper frontier inspection.

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

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

Explicitly states when to use it ('when discovery produced many plausible files or symbols'). This gives clear context for selection. It doesn't explicitly name alternatives or state when not to use it, but the use condition is strong and the tool's narrow scope implies the boundary.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is 'cheap' and 'probabilistic', returns 'structured likelihood signals', and explicitly does not diagnose or fix. This is meaningful behavioral context beyond the schema. It could add more about caching or side effects, but the core behavior 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?

Three sentences, each earning its place: what it is, when to use it, and what it returns/doesn't do. The key information is front-loaded. No redundancy or filler.

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

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

The tool has an output schema, so return values are documented elsewhere. The description covers purpose, usage timing, and limitations. It doesn't mention the 'use_cache' parameter or how the tool handles previous_failure, but for a triage tool with a clear scope, the description is largely complete. The main gap is that it doesn't explain what inputs are most important to provide, but the schema covers the input structure.

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. The description explains the tool's overall purpose but does not explain any of the 8 parameters (task, current_step, failure, use_cache, diff_summary, changed_files, previous_failure, client). The parameter names are fairly self-explanatory, and the schema has detailed nested definitions, but the description adds no parameter-level meaning. Baseline 3 is appropriate because the schema itself is rich, but the description does not help with parameter semantics.

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 ('triage'), a resource ('test/build/lint/typecheck failures'), and a clear scope ('probabilistic', 'cheap'). It also explicitly distinguishes itself from diagnosis/fixing, which helps an agent understand exactly what this tool does and does not do.

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

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

The description explicitly says 'Use before broad reasoning when the relationship or scope of a failure is unclear.' This gives a clear when-to-use condition. It also states what the tool does not do ('does not diagnose or fix the problem'), which helps an agent avoid using it for the wrong purpose. Sibling tools are not named, but the usage context is specific enough to route correctly.

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