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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the basic safety and side-effect profile. The description adds meaningful context beyond that by explaining the binding PLHCP override (1904.6(b)(3)) and clarifying that requires_judgment is a non-decision state to be escalated, not acted upon. It does not detail return-format specifics, but with an output schema present and the annotations already carrying the safety burden, a 3 is appropriate.

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 compact and well-structured: purpose first, then workflow ordering, then the key legal distinctions, then the output verdicts and a caution about misuse. Each sentence carries distinct regulatory or procedural information. It loses one point for density — the 1904.6(b)(3) PLHCP rule is described in a long single sentence, and the overlap between the description's example ('occupational asthma episode') and the schema's parameter description is some slight redundancy, but no sentence is wasted.

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 100% parameter coverage, an output schema, and read-only/idempotent annotations, the description fills every remaining gap: imputed workflow position among 10 sibling tools, special-case handling (PLHCP binding), and the output's semantics (requires_judgment means ask the user). No side-effect or resource-lifetime concerns exist for this read-only classifier, so nothing is arguably missing to invoke/triage 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 coverage is 100% (all 6 parameters have rich schema descriptions), so the baseline is already 3. The description adds substantial value beyond the schema by interpreting the regulatory context: why PLHCP opinion overrides the logic, what 'conflicting' means in practice, and what makes requires_judgment occur. The parameter 'causation_is_clear' gets practical meaning — 'Pass false when the narrative does not establish this' — which the schema itself does not fully convey.

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

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

The description opens with a specific verb and resource: 'Determine whether an injury or illness is a NEW case or a continuation of one already on the 300 Log.' It precisely names the second condition of the 1904.4(a) conjunction and distinguishes itself from sibling tools by placing itself explicitly between osha_assess_work_relatedness and osha_assess_recordability. This gives an agent an unambiguous understanding of what the tool does and how it differs from the rest of the osha_* family.

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 explicit sequencing: 'Run this after osha_assess_work_relatedness and before osha_assess_recordability, and pass its new_case result through.' It also lists key distinctions the tool settles and provides a clear behavioral rule for ambiguous results: 'Treat requires_judgment as a question for the user, never as a licence to pick.' This is strong when-to-use guidance with a direct exclusion of misuse.

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?

Beyond the already helpful annotations of readOnlyHint, idempotentHint, and destructiveHint, the description adds meaningful behavioral detail: the tool applies the closed first-aid list deterministically, returns a cited determination, marks results provisional when needed, and requires a follow-up interaction when clarification is pending. It also discloses the limitation that this is not legal advice or a medical determination.

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 thorough and front-loaded with the main decision. Every sentence contributes something valuable: the decision rule, the deterministic behavior, the input-mapping requirement, the disclaimer, and the follow-up workflow. It is long because it needs to be, but it still feels tight and structured.

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

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

For a regulatory decision tool with nine parameters, rich annotated safety metadata, and a complex sibling set, the description is complete. It covers the decision tree, the output provisional state, user clarification flow, mapping of narrative input to controlled fields, and the non-legal/non-medical disclaimer. An agent has enough information to invoke the tool and respond to the results 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 100%, and each parameter already carries detailed regulatory guidance, so the description does not need to re-explain individual inputs. It adds a high-level instruction to map the incident narrative to controlled inputs, but most of the substantive usage semantics are already embedded in the schema.

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

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

The description names a specific action and resource: 'Determine whether a work-related injury or illness is OSHA recordable under the 1904.4 decision tree.' It then spells out the exact conditions of the decision tree, and the resource and scope are clearly distinct from sibling tools that assess only one component such as work-relatedness or new-case status.

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

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

The description provides clear operational context by stating 'Reference and triage only' and by specifying what to do when the result is provisional: follow the clarification_required instruction, ask the user, and call again. However, it does not explicitly name sibling tools or give exclusion conditions for when a caller should use one of them 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: it explains that the tool returns one of three verdicts, specifies the exact conditions that trigger requires_judgment, and includes a not-legal-advice caveat. No contradiction with 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 detailed but efficiently front-loaded with the core purpose, then the workflow ordering, verdict semantics, and handling guidance. Each sentence contributes distinct information: regulatory basis, tool sequencing, return values, requires_judgment behavior, and scope disclaimer.

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

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

For a tool with 8 parameters and an output schema, the description provides enough operational context for an agent to call it correctly: when to run it, what it returns, why requires_judgment appears, and how to respond to it. The output schema covers return structure, so the description does not need to restate that.

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 100%, so the input schema fully documents all parameters and enums. The tool description itself does not add parameter-level detail, but it does add useful higher-level context about how the result should be used. Per the baseline for complete schema coverage, a 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 opens with a specific verb and resource: 'Determine whether an injury or illness is work-related.' It clearly identifies the tool's role as the gate for Part 1904 determinations and distinguishes it from the sibling tool osha_assess_recordability by instructing the agent to run this tool first.

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 explicit workflow guidance: 'Run this BEFORE osha_assess_recordability and pass its work_related result through.' It also tells the agent how to handle the requires_judgment verdict — 'put to the user, never as a licence to pick' — and frames the tool as 'Reference and triage only.'

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, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe, read-only operation. The description adds valuable behavioral context beyond annotations: it specifies what the tool returns (required log entry, confidential-list and redaction obligations, and the only three recipients) and warns about the closed-list prohibition (1904.29(b)(8)), which prevents misapplication. This enriches the agent's understanding of side effects and output.

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 moderately long but each sentence carries substantive information. The core purpose is front-loaded in the first sentence, followed by the closed-list explanation, output summary, and usage timing. For a complex regulatory topic requiring precision, this structure is efficient and not padded. It is slightly denser than necessary but appropriate given the need to convey legal nuances.

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

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

The description covers the essential elements: what the tool determines, what it returns, when to invoke it, and the closed-list constraint. Since an output schema exists (has output schema: true), the return structure is presumably detailed there, but the description mentions the key outputs (log entry, confidential-list, redaction obligations, three recipients) to orient the agent. It does not explicitly address edge cases like 'none_of_these' returning false, but the schema and closed-list description imply that. Overall, it is complete enough for a read-only classification 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 100%, so the parameters are fully documented in the input schema. The tool description adds meaning by explaining the regulatory basis for the enum values (e.g., '1904.29(b)(7) is a closed list — injury to an intimate body part or the reproductive system, sexual assault...') and clarifies that 'other_illness_employee_requested' is the only category that requires both is_illness and employee_requested_name_omitted. This helps the agent map incident narratives to the correct enum value and understand the conditional logic.

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 ('Determine'), a precise resource ('whether a recordable case is a privacy concern case'), and the core consequence (name must NOT be entered on the OSHA 300 Log). It explicitly distinguishes from siblings by indicating this runs after recordability is established, which is not obvious from any other tool. The mention of the closed list and prohibition adds specificity.

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 clearly indicates when to run the tool ('Run this after a case is determined recordable') and provides context for the input nature by enumerating the closed list. It does not explicitly name alternative tools for different steps, but the instruction 'after a case is determined recordable' implicitly separates it from recordability assessment tools like osha_assess_recordability. The guidance is sufficient for correct usage.

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=true, openWorldHint=false, idempotentHint=true, destructiveHint=false. The description adds meaningful behavioral context beyond those: it explains the size exemption measurement (entire company, peak employment), the industry exemption resolution against Appendix A, the partial nature of the exemption (1904.39 still binds), and that written notice defeats the exemption. It also notes the tool resolves the 1904.2 industry question itself. No contradictions. The only minor gap is not detailing what the return value looks like, but output schema exists and the description says 'Reference and triage only', which hints at the read-only consultative nature.

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 front-loaded with the critical 'Run this FIRST' instruction, then covers key behavioral traps. It is structured in logical flow: purpose, when to use, common mistakes, exceptions, and parameter hints. It is somewhat dense — the sentences are long and packed with regulatory citations. But every sentence earns its place: each clause adds a distinct fact (coverage scope, peak employment, written request exception, partial exemption). Slight deduction for density that may slow parsing, but not for waste.

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

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

For a complex regulatory tool with 4 parameters (including a fallback boolean), the description and parameter-level detail together cover the key nuanced behaviors: the across-company scope, peak employment, industry exemption resolution, the written-notice defeat, and the partial exemption caveat. With output schema present, return format is not a gap. The sibling set includes many downstream chain tools, and this description establishes itself as the entry point. The completeness is high for the tool's complexity.

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

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

Schema description coverage is 100%. The description adds significant meaning beyond each property description. For company_peak_employees_last_calendar_year it emphasizes 'PEAK', 'ENTIRE COMPANY', 'not an average, not a year-end headcount', with an illustrative example ('if the company touched 11 employees for one week, it is over the threshold'). For establishment_naics_code it explains the 4-digit matching logic against Appendix A and the fallback to boolean. For notified_in_writing it adds context about state agencies and that it defeats both exemptions. This goes well beyond the schema's basic descriptions.

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

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

The description states a specific verb and resource: 'check whether recordkeeping applies' under 29 CFR 1904.1, and frames it as the threshold question before all other Part 1904 determinations. It clearly distinguishes from siblings by naming the first step in a chain and explicitly instructing to 'Run this FIRST'. The title reinforces the regulatory citation, and the description exceeds mere tautology by explaining the consequence of skipping this check.

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 tells the agent when to use: 'Run this FIRST for any small employer or any establishment that may be in a partially exempt industry'. It gives a clear when-not condition: 'otherwise the chain will confidently instruct them to make 300-Log entries for a log they need not keep.' It also reveals two common mistakes to guard against, which adds practical usage context. No direct alternative named, but the sibling set context implies the chain, and the description frames this as the gate.

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 transparently explains key behavioral rules: exclusions still leave the case recordable, observation-only hospitalizations are not reportable, and specific amputation definitions. It also clarifies that deadlines run from the learned datetime. Annotations already cover safety (read-only, idempotent), so the description adds regulatory context without redundancy.

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 detailed but necessary given the regulatory complexity. It is structured logically: purpose, key rules, exclusions, and a disclaimer. While slightly long, every sentence adds relevant information, and it is not redundant with the schema.

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 provides sufficient regulatory context for the tool's operation, including definitions, exclusions, and deadline logic. Since an output schema is present, the lack of explicit return-value explanation is acceptable. The tool appears complete for its intended triage role.

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 covers 100% of parameters with descriptions, and the tool description reinforces the meaning of each parameter by explaining regulatory context (e.g., amputation_kind definitions, exclusion categories). It adds value beyond the schema by linking parameters to the regulation.

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: determine if reporting is required and compute deadlines for severe outcomes. It uses specific verbs like 'determine' and 'compute' and references the specific regulation (29 CFR 1904.39). It distinguishes itself from general recordability tools by focusing on reporting obligations.

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 explains when the tool is applicable (severe outcomes) and includes exclusions (e.g., public road accidents, transport). It also notes it is for reference and triage only, not legal advice. However, it does not explicitly contrast with sibling tools, which slightly reduces clarity.

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, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds specific behavioral rules: the most-serious-outcome rule, 180-day cap, on_log false for non-recordable, medical removal never column J, chemical exposure → poisoning column, TB → respiratory condition column, and lining out on three kinds of evidence. This is substantial context beyond annotations. It doesn't restate the annotations and adds value on the regulatory logic. Not a 5 because it doesn't address what happens on edge cases like the 7-day completion deadline (though that's in the schema) or failure modes.

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 dense but well-structured paragraph: opens with the decision target, then the key rule, then the on_log gate, then the two special-column rules, and closes with the prerequisite and a triage note. No wasted words. It front-loads the most critical info (the classification rule) before regulatory details.

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 11 parameters, a rich output schema, and a complex regulatory domain. The description ties into the prerequisite tools and gives enough context to invoke correctly: what to check first, when not to use (on_log false, medical removal not J), and special cases. It could go deeper on the interaction with e.g. osha_evaluate_restricted_work for the restricted-days counting, or clarify the refusal of the 180-day cap on the day counts, but it covers the major decisions. Given the output schema exists, not explaining return format is acceptable. 4 is fair.

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 100%, so the schema thoroughly documents every parameter. The tool description itself doesn't expand on individual parameters, but it does compound the regulatory logic: e.g., it mentions the medical-removal rule and the chemical-exposure/poisoning link that ties to the medical_removal_from_chemical_exposure and medical_removal_case parameters, and notes the TB/gas evidence that maps to tb_non_occupational_evidence. That gives the parameters regulatory meaning beyond the schema's own text, which is already rich. I'd give 3—the schema carries most of the weight, but the description adds some regulatory interrelations.

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 ('determine the correct OSHA 300 Log outcome column'), names the exact resource (OSHA 300 Log column G/H/I/J), and explains the selection rule (most-serious-outcome, injury/illness type, day counts capped at 180). It clearly distinguishes this tool from siblings like osha_assess_recordability and osha_evaluate_restricted_work, which are mentioned as prerequisites.

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 instructs 'Run osha_assess_recordability first' and mentions 'Check on_log first' for non-recordable cases. It also references osha_evaluate_restricted_work for days restrictions in the parameter description, and 'Reference and triage only' clarifies this is a classification tool, not one that creates or modifies records. It clearly scopes when to use this tool versus when to use the assess/evaluate 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?

The description fully discloses the decision logic, including the day-to-day supervision test and the irrelevance of paycheck issuer for temporary workers. It also references specific OSHA regulations (1904.31(a), (b)(1)-(b)(4)) and notes that it is not legal advice, which sets appropriate expectations. No contradictions with the readOnlyHint and idempotentHint 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 a bit lengthy but well-structured with clear sentences addressing different aspects (purpose, when to use, controlling test, exclusions, and legal reference). It avoids unnecessary fluff, though some points are repeated across the description and parameter descriptions.

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 provides comprehensive context for the decision process, including the rule for temporary workers and the exclusion of self-employed and owners. It also mentions that the case must be recorded only once (1904.31(b)(4)), making it complete for the tool's intended use within the OSHA recording workflow.

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 already provides descriptions for both parameters, but the overall description adds meaningful context, such as clarifying that 'on_your_payroll' covers all employee types and that supervision is irrelevant for payroll employees. This enriches understanding beyond the schema's individual descriptions.

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

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

The description clearly states the tool's purpose: determining which employer records a case on their OSHA 300 Log for non-payroll workers. It lists specific categories (temp, contractor, self-employed, owner) and the controlling test (day-to-day supervision), distinguishing it from sibling tools like assess_work_relatedness or evaluate_restricted_work.

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 explicitly instructs to run this tool first whenever the injured person is not on the employer's payroll, and explains that if the outcome is 'the other employer' or 'no one', the rest of the chain is not this employer's obligation. This provides clear when-to-use guidance and differentiates from later steps in the recordability assessment chain.

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, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context: the two tests must be met in the same ear, age adjustment applies only to the STS test, retest rules (30-day window, confirmation vs. non-confirmation), and the PLHCP determination ending the case. It also warns that the tool does arithmetic and the user must supply age adjustments. This rich disclosure goes well beyond the annotations and precisely explains the decision logic.

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?

Though long, every sentence carries unique regulatory detail. The main purpose is front-loaded, and the subsequent sentences each clarify a distinct condition or exception. The structure uses parentheses for references and enumerations, making it scannable. There is no redundancy or filler; the length is justified for the regulatory complexity.

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 10 parameters, nested objects, and an output schema present, the description covers all essential behavioral aspects: the two decision tests, same-ear requirement, age adjustment scope, retest logic, PLHCP override, and usage constraints. It also includes a disclaimer about legal advice. The output schema handles return values, so that gap is not an issue. For a complex OSHA evaluation tool, this description is thoroughly 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 100%, so a baseline of 3 applies. The description adds meaning beyond the schema by clarifying relationships: it explains the same-ear condition, that baseline values should be the revised baseline when applicable, and that age adjustments are for STS only. It instructs the agent to pass raw values and not precompute averages, and clarifies the interplay between retest flags and the PLHCP flag. This adds semantic depth that the schema alone does not provide.

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

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

The description opens with a precise verb and resource: 'Compute whether an audiogram produces a recordable hearing loss.' It also specifies the regulatory basis (29 CFR 1904.10) and the two tests, making it unmistakable from sibling tools that handle other OSHA recordkeeping aspects. The purpose is specific, actionable, and distinguishes this tool from the broader osha_assess_recordability and similar 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 gives clear context and instructions: 'Pass raw audiogram values and the tool does the arithmetic — do not compute averages yourself,' and explains when to pass a revised baseline. It also disclaims 'Reference and triage only — not legal advice.' However, it does not explicitly name sibling tools or state when NOT to use this tool (e.g., for work-relatedness determination, use osha_assess_work_relatedness). Since the domain is specific, the exclusion is implicit but not explicit, so a 4 is appropriate.

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, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat those. It does add valuable behavioral context beyond the annotations: the tool applies a decision tree based on regulation, and it emphasizes the doubt-resolution rule that vague recommendations default to recording. It also notes the tool is not legal advice, which is a helpful behavioral caveat. There is no contradiction with 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 long, but it packs a dense set of regulatory rules that are essential for correct usage. It front-loads the purpose and usage instruction ('Run this BEFORE...'), then lists the key rules in a structured sequence. While it could be slightly trimmed, the length is justified by the complexity of the regulatory domain. It is not tautological or redundant with the title.

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 complexity of the tool (7 parameters, complex decision rules, and an output schema), the description provides sufficient context: it explains the decision criteria, the critical vague-restriction rule, and the tool's place in the workflow. Since an output schema exists, the description need not describe return values. The only minor gap is that it does not explicitly state the ternary nature of the output (true/false/unknown), but the output schema presumably covers that. It is complete enough for an agent to understand when and how to invoke it 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 100% — every parameter has a detailed description including regulatory references (e.g., '1904.7(b)(4)(iii)' for restriction confined to day of injury). The description itself does not elaborate on individual parameters, but that is unnecessary given the schema's thoroughness. The description does add context about the overall decision logic, but it does not go beyond what the schema already explains for each parameter. 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 specific action: 'Decide whether a work restriction or job transfer actually counts as restricted work'. It immediately differentiates itself from siblings by mandating that it runs BEFORE passing 'restricted_work_or_transfer' to osha_assess_recordability, and it lists the exact regulatory references (29 CFR 1904.7(b)(4) subsections). This is a specific verb+resource with explicit sibling 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?

Usage is precisely defined: 'Run this BEFORE passing restricted_work_or_transfer as an outcome to osha_assess_recordability'. It also enumerates what does and does not count as restricted work, including the critical caveat about vague restrictions that must be recorded unless clarified. It further warns that it is 'Reference and triage only — not legal advice,' setting clear boundaries for its use.

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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description fully aligns with these. It goes beyond annotations by elaborating the regulatory framework and edge cases (e.g., telecommuting, mobile work, short-term establishments), providing transparency about the tool's decision-making behavior without contradiction. No side effects are implied, consistent with read-only nature.

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?

While lengthy, the description is well-structured and information-dense. It front-loads the core purpose and then systematically explains the decision logic, referencing specific regulations and edge cases. Every sentence adds value, and the regulatory citations (1904.30(a), (b)(1)-(4), 1904.46) are precise. No redundancy or filler is present.

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 complexity of OSHA regulations, the description is remarkably complete. It covers the main rule (place of injury), exceptions (telecommuting, mobile work), and ancillary considerations (short-term establishments, central recordkeeping deadlines). Since an output schema exists, the lack of explicit return-value description is acceptable. The description equips an agent to make the correct routing decision without ambiguity.

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 100% with all 5 parameters described in detail. The description adds semantic depth by explaining the significance of each parameter (e.g., 'occurred_at_one_of_your_establishments' definition includes mobile work nuances, and 'employee_was_telecommuting_from_home' clarifies that a home is never an establishment). This exceeds the schema's basic descriptions and provides the rationale for parameter values.

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: to decide which establishment's OSHA 300 Log a recordable case belongs on. It uses a specific verb ('Decide') and a specific resource ('establishment's OSHA 300 Log'), and it distinguishes itself from sibling tools like check_recordkeeping_obligation and determine_recording_employer by focusing on the final routing decision.

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 positions this as 'the last question about an individual incident,' making clear it is used after other recordability steps. It also provides detailed regulatory context (1904.30(b)(4)) and explains the decision logic, effectively guiding when to use this tool versus alternatives. The 'last question' phrasing implies it's the final step in a sequence, which is sufficient for routing.

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