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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety/idempotency profile. The description adds that the output is a 'portable' pack, but omits meaningful behavioral context such as what allow_fallback (default false) actually does and what the pack contains beyond the domain list.

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 verb first and zero filler. It is appropriately tight, though its brevity is arguably under-specification for a 12-parameter composite tool.

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

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

For a 12-parameter aggregation tool the description is thin: it does not explain fallback behavior, candidate/assay limits, or how the pack differs from the narrower sibling builders. An output schema and rich annotations reduce the burden somewhat, but the behavioral and usage gaps are substantial.

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

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

With 12 parameters at only 42% schema description coverage, the description must compensate. It only loosely names the include_* domains and says nothing about allow_fallback, max_assays, max_candidates, or the hazard_datasets enum, leaving most parameters undocumented in both schema and 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?

States a specific verb ('Assemble') and resource ('CompTox evidence pack') and enumerates the six constituent domains (identity, hazard, exposure, bioactivity, AOP linkage, PBPK context). Clear purpose, but it gives no signal to distinguish it from sibling composite builders like build_aop_linkage_summary or build_pbpk_context_bundle.

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 only says what the tool produces; it offers no when-to-use guidance, no prerequisites, and no mention of alternatives such as the narrower build_* sibling tools or prioritize_risk_signals. The agent must infer when a full evidence pack is warranted.

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 cover the read-only, idempotent, non-destructive, open-world behavior. The description adds no behavioral context beyond the name, such as rate limits or how the batch is processed, so it provides no value beyond 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple batch tool, though its brevity means it omits useful routing information.

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 annotations covering safety and an output schema covering return values, the description only needs to state purpose. It does so adequately, but fails to mention the sibling get_bioactivity_aed or when to prefer the batch version, leaving a gap for an agent selecting among many tools.

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 the single dtxsids parameter is fully documented in the schema, including the max 200 per batch constraint. The description adds no additional meaning about the parameter, so the baseline of 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 states a specific verb (batch retrieve) and resource (AED data) with a clear scope (multiple chemicals). It is clear but does not differentiate from the sibling get_bioactivity_aed, leaving the agent to infer the batch-vs-single distinction.

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 or alternatives are provided. The phrase 'for multiple chemicals' merely restates the batch nature and does not tell the agent when this tool should be chosen over get_bioactivity_aed or batch_get_bioactivity_data.

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 readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds nothing beyond that — no note on what an 'annotation' contains, whether missing AEIDs are tolerated, or any batch-size 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?

A single short, front-loaded sentence with no wasted words. It is efficient, though its brevity is partly the cause of the missing usage and behavioral 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-value explanation is not required. However, for a batch retrieval tool positioned among dozens of bioactivity siblings, the definition is minimally adequate: it identifies the input but leaves routing and result semantics largely unexplained.

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 there is a single required parameter, so the schema already documents 'aeids' as a list of assay endpoint IDs. The description's phrase 'for AEIDs' merely restates that without adding format or batch-size detail; baseline 3 applies.

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 (retrieve) and resource (assay annotations) with a clear batch scope and the key selector (AEIDs). It is clear what the tool does, but it does not differentiate itself from adjacent bioactivity tools such as get_bioactivity_assay or get_bioactivity_aed by explaining what 'annotations' actually covers.

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 use this tool rather than the many sibling bioactivity retrieval tools, nor any prerequisite or exclusion guidance. The agent must infer the use case entirely from the name, despite a crowded sibling set.

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 annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing behavioral beyond the noun 'batch' in its title – no mention of the 200-item cap, error/partial-failure behavior on a batch, or rate limits. With rich annotations the bar is lower, but the description contributes essentially no extra context.

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 zero filler; the batching scope is stated immediately. It is arguably too terse to earn a 5, but nothing in it 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?

With an output schema present and 100% schema coverage, the description does not need to explain return values or parameter details. It supplies the batching scope, which is the key missing piece for the agent, though it could be stronger by routing to the singular sibling.

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 both parameters (identifier_type enum and identifiers array with minItems/max 200) are fully documented in the schema. The description adds no syntax, format, or value guidance beyond what the schema already provides, making the baseline 3 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 states a specific verb (fetch), resource (bioactivity data) and scope (batch, multiple identifiers), which is enough to distinguish it from the singular sibling get_bioactivity_data. However, it never names that sibling explicitly, so the distinction relies on the agent inferring it from 'batch' vs. the sibling's singular 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?

'for multiple identifiers' implies the selection condition (use this when you have more than one identifier), but there is no explicit when-to-use statement and no reference to get_bioactivity_data as the single-identifier alternative. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing on top: no batch size limits, no behavior for unknown/invalid identifiers, and no partial-failure semantics.

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 short sentence with zero waste, but it is under-specified rather than tight - there is room for one or two more sentences that would earn their place by covering batching and sibling routing.

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 batch mutation-free lookup with enum-driven parameters, the description omits batch limits, identifier-format expectations, and how it relates to the singular sibling tool. That leaves gaps an agent must guess at.

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

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

Schema description coverage is 100% and both enums (id_type, subset) are documented in the schema, so the baseline is 3. The description adds no format details for identifiers or explanation of what each subset returns.

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 clear verb+resource ('Get detailed information about ... chemicals') and the batch scope via 'multiple'. It is distinguishable from get_chemical_details by the plural/batch framing, but it never explicitly contrasts itself with that sibling or with batch_search_chemical.

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, no exclusions, and no mention of alternatives such as get_chemical_details for a single chemical or batch_search_chemical for discovery. The agent must infer that this is the bulk lookup path.

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, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds nothing beyond that — no batch-size ceiling, no partial-failure behavior, no rate-limit or missing-ID handling.

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, so nothing is wasted. It is arguably under-specified rather than over-long, which the conciseness dimension should not penalize heavily.

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. For a batch tool, though, the absence of any guidance on list size, ordering, or handling of unknown IDs leaves a real gap that annotations do not fill.

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

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

With one parameter at 100% schema description coverage, the schema already documents dtxsids as a list of DSSTox Substance Identifiers. The description's 'batch' wording implies a plural input but adds no format, limit, or validation detail beyond 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?

States a clear verb (batch fetch) and resource (reported functional use data), and the 'batch' qualifier distinguishes it from the singular sibling get_exposure_functional_use. However, it never names that sibling or explains the batch-vs-single distinction 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 mention of the single-item alternative, and no indication of batch-size limits or prerequisites. The agent must infer that this is the multi-ID variant purely from the word 'batch'.

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 and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no batch-size behavior, no partial-failure handling for bad DSSTox IDs, no rate-limit or ordering context.

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 four-word phrase is front-loaded and wastes nothing, but it is terse to the point of being under-specified rather than genuinely concise. There is no second sentence to earn its place because none exists.

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?

Complexity is low (one array parameter) and an output schema exists, so return values need not be explained. Still, for a batch endpoint, the absence of any note on batch sizing or partial failures leaves a small but real gap.

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?

There is a single parameter at 100% schema description coverage ('List of DSSTox Substance Identifiers'), so the schema fully documents it. The description adds no semantics such as maximum list length, ID format expectations, or behavior on unresolvable identifiers, so the baseline 3 applies.

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 verb (fetch), a scope modifier (batch) and a resource (HTTK data), which does implicitly distinguish it from the single-item sibling get_exposure_httk. However, 'HTTK data' is an unexplained acronym and the description never says what kind of data is returned, so the purpose is only vaguely conveyed.

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

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

There is no when-to-use guidance, no mention of the singular sibling get_exposure_httk as the alternative for non-batch calls, and no preconditions or batch-size limits. An agent must infer the routing decision entirely from the 'batch' prefix in 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds nothing beyond that – no note on partial-failure behavior across a batch, no rate limits, and no clarification of what 'presence' means for a substance.

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 five-word phrase, front-loaded with the verb. It is efficient but so terse that it reads as under-specification rather than deliberate 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?

An output schema exists, so return values need not be described. However, for a batch tool the description never explains what 'list presence' denotes, gives no batch-size expectations, and does not route the agent away from the singular sibling – gaps that matter 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?

Only one parameter and schema description coverage is 100%, so the schema fully documents 'dtxsids' as a list of DSSTox Substance Identifiers. The description adds no extra meaning, making the baseline 3 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?

States a specific verb and resource ('fetch list presence data') and the 'batch' prefix implies plural input, but it never explains what 'list presence' means or distinguishes itself from the sibling get_exposure_list_presence, which a reader would naturally confuse it with.

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 at all. The singular sibling get_exposure_list_presence exists, yet the description never states that this variant is for multiple DTXSIDs or when to prefer one over the other.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds nothing on top of that: no batch size limits, no partial-failure behavior when some DTXSIDs are invalid, no latency or rate-limit context for a batch call.

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 short phrase with no filler and the batch scope front-loaded. It is efficiently sized, though its brevity is partly under-specification rather than true density.

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

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

The tool is structurally simple (one required array parameter) and an output schema exists, so return values need not be described. Still, the description omits any notion of batch limits or failure handling, which is the main thing an agent needs before issuing a multi-ID call.

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?

Only one parameter, and the schema documents it fully (100% coverage) as a list of DSSTox Substance Identifiers with minItems 1. The description adds no extra meaning about accepted ID formats or how many IDs are practical per call, so the baseline of 3 applies.

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 verb (fetch), a resource (CPDat product data) and a batch scope, which loosely separates it from the single-item sibling get_exposure_product_data. However, 'CPDat' is unexplained domain jargon and the description gives no sense of what the product data contains, so it is only marginally more informative than the tool 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?

There is no when-to-use guidance, no prerequisite for resolving DTXSIDs first, and no named alternative. The 'batch' prefix weakly implies 'use this for many IDs', but nothing states when to prefer it over get_exposure_product_data or over the other batch_get_exposure_* tools.

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, openWorldHint=true and destructiveHint=false, so the safety and idempotency profile is fully covered structurally. The description adds nothing beyond that — no notes on batch-size limits, partial-failure behavior, or handling of unknown DTXSIDs, which is the kind of context a batch call needs.

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; the scope qualifier is placed where it is read first. It is efficient, though its brevity is partly why other dimensions are thin.

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 carry the safety profile. What remains unaddressed for a batch retrieval tool — result ordering, behavior with invalid or mixed identifiers — keeps it at minimum-viable rather than 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?

There is a single parameter with 100% schema description coverage, so the schema fully documents the DTXSIDs array. The description's 'multiple chemicals' only loosely corroborates the array shape and adds no format or limit detail, so the baseline 3 applies.

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 (Retrieve) and resource (cancer hazard summary) with the key scope qualifier 'for multiple chemicals', which implicitly separates it from the single-chemical sibling get_hazard_cancer_summary. It does not name that sibling explicitly, so it stops short of a 5.

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 multiple chemicals' implies this is the batched path, but there is no explicit when-to-use guidance or named alternative (get_hazard_cancer_summary) telling the agent to pick the single-item variant for one chemical. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds nothing beyond that—no batch-size limits, partial-failure behavior, ordering, or rate-limit context—so it contributes no behavioral value of its own.

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 short sentence with zero waste and the key scope word 'multiple' placed up front. It is efficiently sized, though it is so terse that it borders on under-specification rather than tight 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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. Still, for a batch retrieval tool the description omits batch cardinality limits and how per-chemical failures are handled, leaving gaps an agent would want covered.

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% for the single dtxsids parameter, which is already documented as 'Chemical identifiers (DTXSIDs)' with a minItems constraint. The description's 'multiple chemicals' only restates the array nature and adds no format or syntax detail, so the baseline 3 applies.

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 ('Retrieve') and resource ('genotoxicity detailed data') with the scope 'multiple chemicals', which distinguishes it from the singular get_hazard_genetox_details. However, it never names or contrasts with the singular or summary siblings, leaving the agent to infer the batch distinction 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?

No when-to-use guidance is given: nothing says when to prefer this batch variant over get_hazard_genetox_details or batch_get_hazard_genetox_summary, nor any prerequisite or batching limit. The 'multiple chemicals' phrasing is only an implied usage hint.

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 and openWorldHint=true, covering the safety profile. The description adds no further behavioral context (batch limits, partial-failure handling, pagination), so it earns little beyond 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?

A single front-loaded sentence with zero filler. It is efficient, though extremely terse given the batch behavior that could be clarified.

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 single parameter is fully covered. Still, as a batch endpoint it omits practical constraints (max number of DTXSIDs, behavior on unknown IDs) that an agent would benefit from.

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 the single 'dtxsids' parameter is documented as 'Chemical identifiers (DTXSIDs)' with minItems 1. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 ('Retrieve'), resource ('genotoxicity summary data'), and scope ('for multiple chemicals'), which hints at batch semantics. However it does not name the singular sibling get_hazard_genetox_summary or the details variant, so differentiation relies on the 'batch' prefix 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?

No when-to-use guidance: it does not say to prefer this over get_hazard_genetox_summary when handling many DTXSIDs, nor whether there are batch-size limits or alternatives. The 'multiple chemicals' phrasing is the only implied usage signal.

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 readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is fully covered. The description adds only the batch/multiple-chemicals scope, but does not describe error handling for invalid or missing DTXSIDs or rate limits. Given the annotations, 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?

One sentence, front-loaded with verb and resource, with no redundant or filler text. Appropriate for a simple retrieval 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?

With an output schema, full parameter descriptions, rich annotations, and low complexity, the description is largely complete. It could mention the singular alternative more explicitly, but an agent has enough to select and invoke this batch endpoint.

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% and the single dtxsids parameter is documented as an array of chemical identifiers. The description adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 ('Retrieve') and resource ('skin and eye hazard data') with batch scope ('multiple chemicals'). The 'batch_' prefix and plural scope distinguish it from the singular sibling get_hazard_skin_eye.

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 use for multiple chemicals at once, but does not explicitly state when to choose this over the singular sibling or any prerequisites. Usage is implied by the batch scope, not guided by alternatives 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the data source (ToxRefDB), and says nothing about batch size limits, partial-failure behavior, or ordering that would be genuinely useful for a batch call.

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 tight sentence with no filler and the key scoping term ('Batch') front-loaded. It is efficient, though the brevity borders on under-specification for a batch operation.

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, leaving little an agent strictly needs. Still, for a batch endpoint the description omits any note on batching semantics or how it relates to get_hazard_toxref, so it is 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 100% and there is a single parameter, so the schema already documents dtxsids as an array of chemical identifiers. The description's 'by DTXSID' merely restates this with no added format or cardinality detail, so the baseline 3 applies.

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 (retrieve) and resource (ToxRefDB data) keyed by DTXSID, and the 'Batch' prefix distinguishes it in kind from the singular sibling get_hazard_toxref. However, it never explicitly names the sibling or states the batch-vs-single relationship, so an agent must infer the distinction 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 guidance on when to use this tool versus get_hazard_toxref or the other hazard batch tools, and no stated preconditions or batch-size limits. The only implied usage is 'multiple DTXSIDs', which comes from the name rather than the description.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no note on batch size limits, partial-failure behavior when some DTXSIDs are unknown, or how results are keyed back to 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?

One short, front-loaded sentence with no filler. It is efficient, though there was room to add routing or batch behavior without bloat.

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 and annotations cover the safety profile, so the definition is not obligated to explain return values. Still, for a batch tool the absence of any guidance on input limits or result correspondence leaves a real gap.

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% for the single dtxsids array parameter, so the schema already documents the input fully. The description's 'multiple chemicals' phrasing merely restates the array shape and adds no format or validation detail.

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 (Retrieve), resource (ToxValDB hazard data), and scope (multiple chemicals), which distinguishes it from the singular sibling get_hazard_toxval. It never names that sibling explicitly, but the batch scope 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?

There is no when-to-use guidance and no mention of the alternative get_hazard_toxval for single-chemical lookups. The agent must infer the batch-vs-single routing 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only that these are "predictions" (as opposed to measured data), which is modest added value; it says nothing about batch size limits, throttling, or partial-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 tight sentence with zero filler, front-loaded with the operation type. It is efficient, though so terse that it leaves useful routing detail on the table.

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 output schema means return values need no explanation, and the schema documents the sole parameter, so the core is covered. Gaps remain around how this differs from its single-input sibling and what practical limits apply when batching multiple DTXSIDs.

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% and the single dtxsids parameter is fully documented in the schema, so the baseline of 3 applies. The description adds no extra syntax, cardinality limits, or identifier-format detail beyond what the schema already provides.

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 concrete verb ("Batch fetch") and a specific resource ("SEEM demographic exposure predictions"), and the "Batch" prefix implies the multi-input variant of get_seem_demographic. However, it never explicitly distinguishes itself from the single-input sibling or from batch_get_seem_general, so the agent must infer the routing.

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

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

There is no when-to-use guidance, no mention of when to prefer this over get_seem_demographic (single) or batch_get_seem_general, and no prerequisites stated. The batch semantics are only implied by the name prefix.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that - no note on batch size limits, partial-failure behavior, or coverage of the predictions - so it contributes no behavioral value over 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 with no filler; the batch qualifier comes first, which is the most important discriminator. It is terse to the point of being thin, but nothing 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?

An output schema exists, so return values need not be described, and annotations cover safety, leaving only the parameter. Still, for a batch endpoint there is no mention of how many identifiers can be submitted per call or what happens on partial success, which are the main practical unknowns.

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 single dtxsids parameter is documented in the schema as a list of DSSTox Substance Identifiers. The description adds no format or semantics beyond that, so the baseline 3 for high-coverage schemas applies.

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 clear verb ('Batch fetch') and resource ('SEEM general exposure predictions'), so an agent immediately knows the operation. It does not name or contrast itself with the single-item sibling get_seem_general or with get_seem_demographic, so sibling differentiation is left implicit in the word 'Batch'.

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

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

The word 'Batch' implies the tool is for fetching many substances at once rather than one, which is the key selection signal against get_seem_general. However, there is no explicit statement of when to prefer this over the single-item call, nor any note about batch-size limits or 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, openWorldHint=true, idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond that: no note on batch size limits, partial-failure behavior for unknown identifiers, 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?

A single short sentence with no wasted words and the key qualifier ('Batch') front-loaded. It is efficient, though it borders on under-specification rather than true 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?

Because an output schema exists, return values need not be explained, and the annotations carry the safety profile. Still, for a batch tool nothing is said about identifier limits, mixed-type lists, or unmatched-identifier handling, leaving meaningful 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?

Only one parameter exists and schema coverage is 100%, with the schema itself listing accepted identifier forms (DTXSIDs, CASRNs, names, etc.). The description merely restates 'list of identifiers' and adds no syntax, limit, or format detail, so the baseline 3 applies.

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 (batch search, chemicals) plus the input mechanism (a list of identifiers), so the agent knows exactly what the tool does. However, it never distinguishes itself from the sibling search_chemical, which does a single-identifier lookup; the distinction must be inferred from the word 'batch'.

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 sibling is named as an alternative. At best the word 'Batch' implies 'use this for multiple identifiers', which is a weak inference rather than stated guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description only adds the batch/multi-DTXSID nature, which is already implied by the name, and says nothing about response size, limits, or how batching behaves. Marginal value beyond 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 efficient sentence that is front-loaded with the key verb and scope. No filler, though it is arguably under-specified rather than genuinely concise.

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 carry the safety profile. Still, the routing ambiguity against search_hazard and the per-dataset batch_get_hazard_* tools leaves the agent without enough to call this correctly versus alternatives.

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 already documents dtxsids, summary, and data_type with an enum. The description mentions 'multiple DTXSIDs' and 'selected dataset' but adds no syntax, format, or enum-value meaning beyond what the schema supplies. 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?

States a clear verb (batch lookup), resource (hazard), and scope (multiple DTXSIDs, selected dataset). However, it fails to distinguish itself from closely related siblings such as search_hazard (single lookup) and the per-dataset batch_get_hazard_toxval/skin_eye/cancer/genetox/toxref tools. An agent cannot tell from the description alone whether this tool subsumes those or is a separate generic path.

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, when-not-to-use, or alternative routing is provided. 'For the selected dataset' implies the data_type parameter drives selection but gives no guidance on choosing between this generic batch tool and the more specific batch_get_hazard_* 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 already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds nothing beyond that: it does not explain the fallback path implied by allow_fallback, what happens when an identifier fails to resolve, or any cost/rate characteristics of this composite build operation.

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 is under-specified rather than bloated, but as written 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?

Although an output schema exists (so return values needn't be described), this is a 7-parameter composite tool with a 57% schema coverage gap and no usage guidance. The description does not provide enough context for an agent to invoke it correctly or distinguish it from sibling AOP/bioactivity tools.

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 only 57%, and several parameters (max_assays, max_candidates, allow_fallback) have no schema descriptions at all. The description provides no parameter-level meaning to compensate, so the agent is left guessing what allow_fallback or the max_* limits actually control.

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 ('Build') and resource ('AOP linkage summary') with the source data named (bioactivity assay and AOP crosswalk data). However, it offers no differentiation from closely-named siblings such as get_bioactivity_aop or get_bioactivity_summary_by_dtxsid, and 'CompTox-side' is unexplained jargon, so an agent cannot confidently pick it over those alternatives.

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 contains no when-to-use, when-not-to-use, or prerequisite guidance. It does not mention the dtxsid-vs-identifier choice, when to prefer this over the sibling AOP/bioactivity summary tools, or what conditions make the summary useful.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully names the aggregation sources, but says nothing about the meaning of allow_fallback (does it degrade the bundle?), latency, or what 'context bundle' contains.

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 front-loaded sentence that wastes no words and puts the resource and sources up front. It is efficient, though it reads as a flat list rather than prioritizing the key constraint.

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

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

An output schema exists, so return values need no explanation, and the annotations cover safety. However, for a 6-parameter aggregation tool with a fallback switch and moderate schema coverage, missing when-to-use and fallback semantics leave real gaps.

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 only 67%, and the two undocumented parameters (allow_fallback, max_candidates) are not explained in the description either. 'model-card references' loosely hints at model_name, but the fallback and candidate-limit semantics that govern behavior are left entirely opaque.

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 ('Build') and resource ('CompTox-side PBPK context bundle') and enumerates the source domains (HTTK, ADME/IVIVE, exposure, model cards). It is clear what the tool produces, but it does not distinguish itself from the similar-sounding sibling assemble_comptox_evidence_pack.

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 use this aggregation tool rather than the adjacent assemble_comptox_evidence_pack, nor on prerequisites (resolvable identifier, DTXSID requirement). The agent must infer the context 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds no behavioral context beyond the name — no note on scope, pagination, data provenance, or what the AED dataset contains, so it contributes essentially nothing on top of 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?

One short, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity borders on under-specification rather than tight 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?

An output schema exists, so return values need not be described, and a single-param read tool carries a light burden. Still, with ~100 sibling tools and several bioactivity variants, the description lacks the routing context an agent needs to pick this one 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% ('DSSTox Substance Identifier'), so the schema fully documents the single required parameter. The description adds no syntax or format guidance beyond that, which is the expected baseline when the schema does the heavy lifting.

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 ('Retrieve') and resource ('Activity Exposure Distribution (AED) data') with the target entity ('for a chemical'), and even expands the acronym. However, it does nothing to distinguish itself from close siblings like get_bioactivity_data or batch_get_bioactivity_aed, leaving the agent to guess which retrieval route to take.

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 use this tool versus alternatives, no prerequisites beyond the implied dtxsid, and no indication of when-not to use it. In a sibling set with get_bioactivity_data, get_bioactivity_summary_by_dtxsid, and batch_get_bioactivity_aed, this omission forces inference.

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 disclose readOnly, idempotent, openWorld, and non-destructive behavior. The description adds no further behavioral context such as what QC data includes, whether results are paginated, or any limits, so it does not enrich the structured safety profile.

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 wasted words. The purpose is delivered immediately and nothing extraneous is included.

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 one fully documented parameter, rich annotations, and an output schema, the description only needs to identify the resource, which it does minimally. However, in a crowded sibling space, it omits any differentiation or selection context that would make invocation unambiguous.

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% for the single dtxsid parameter, so the schema already defines it as the DSSTox Substance Identifier. The description adds no syntax, format, or usage detail beyond what the schema provides, making the baseline 3 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?

States a clear verb ('Retrieve') and a specific resource ('analytical QC data') scoped to a chemical. It does not differentiate from siblings such as get_bioactivity_summary_by_dtxsid or get_bioactivity_data, but the resource is distinctive enough to be actionable.

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?

Gives no guidance on when to use this tool versus the many sibling bioactivity and chemical-detail tools. There are no exclusion conditions, prerequisites, or alternative recommendations.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that – no note on lookup semantics, external dependency, or what the mapping entails.

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 short sentence with no filler, appropriately front-loaded. Its problem is under-specification, not verbosity.

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, but for a tool with a required enum-driven lookup the description leaves usage, lookup semantics, and sibling boundaries entirely unspecified. Incomplete 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 100% with both parameters documented and lookup_type carrying an enum, so the schema does the heavy lifting. The description adds no interpretation of identifier or lookup_type, so the 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?

States a verb ('Retrieve') and resource ('adverse outcome pathway mappings'), so the basic purpose is legible. However, it offers no differentiation from sibling tools like build_aop_linkage_summary, which also concerns AOP data, leaving the agent to guess at the boundary.

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, no prerequisites, and no mention of alternatives despite the presence of build_aop_linkage_summary and various AOP-related siblings. The identifier/lookup_type requirement that drives applicability is never surfaced in prose.

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, idempotentHint, openWorldHint, and destructiveHint=false. The description adds no additional behavioral context such as rate limits, authentication requirements, or response behavior beyond what the annotations and schema already convey.

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 wasted words. It immediately states the action, the resource, and the available query dimensions.

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 and rich annotations already present, the description only needs to cover purpose and invocation context. It does so adequately by naming the retrieval targets and modes, though it could better distinguish this tool from its batch and list-oriented siblings.

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 already documents aeid, mode, and gene_symbol. The description names the same modes but adds no extra syntax, format, or constraint information beyond 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?

States a specific verb ('Retrieve') and resource ('assay annotations or lists'), and lists the query modes. It does not explicitly distinguish itself from close siblings such as batch_get_bioactivity_assay_annotations or get_bioactivity_assay_chemicals, but the purpose is clear enough to select the tool.

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 modes ('by AEID, gene, single-concentration, or all') imply when each query path applies, but the description never states when to use this tool versus the batch annotation, count, or chemical-list siblings. Usage is implied rather than guided.

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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond those annotations—no pagination, return shape, or scope details—so it contributes little on this dimension.

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 the resource front-loaded after the verb. It is appropriately sized for a simple lookup tool, though it omits any differentiating or usage context that could make it more informative.

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 low-complexity, single-parameter lookup with an output schema and full annotation coverage, the description is minimally adequate. It does not need to explain return values, but it still lacks usage guidance and sibling differentiation, leaving a clear gap for an agent navigating many similar bioactivity tools.

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?

There is one required parameter (aeid) and schema description coverage is 100%, so the schema already fully documents it. The description says the input is an assay endpoint, which corroborates the schema but adds no syntax or format detail beyond it, matching the baseline of 3 when the schema does the heavy lifting.

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 clear verb (get) and resource (chemicals associated with an assay endpoint), so an agent can tell what the tool returns. However, it does not distinguish itself from close siblings such as get_bioactivity_summary_by_aeid or get_bioactivity_data, which also operate on assay endpoints, so sibling differentiation is missing.

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 guidance on when to use this tool versus alternatives, nor any prerequisite or exclusion. The description only restates the purpose, leaving the agent to infer usage context from the name alone.

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 annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, fully covering the safety profile. The description adds no behavioral context beyond the return value, such as how 'available' is scoped or any rate/permission 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?

The description is a single front-loaded sentence with no filler. Every word contributes to stating the tool's output.

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

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

For a simple count tool with no parameters, rich annotations, and an output schema, the description is nearly complete. It could briefly clarify what 'available assays' means or when to prefer this over sibling detail tools, but the output schema covers return details.

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?

There are zero parameters, so the baseline is 4. The description does not need to compensate for any parameter documentation gaps.

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 ('Return') and resource ('total count of available assays'), making the purpose clear. It does not, however, differentiate this count tool from sibling detail- or batch-oriented assay 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?

Usage is implied: the tool returns only a count, so an agent needing a lightweight total would choose it over detail-returning siblings like get_bioactivity_assay. But no explicit when-to-use or when-not-to-use guidance is provided.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only that results are 'detailed' and scoped to one identifier, offering little beyond the structured fields about projection behavior or result breadth.

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 zero filler; it is appropriately sized. It could carry a little more routing information without bloat, so it is efficient but thin rather than exemplary.

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

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

An output schema exists, so return values need no explanation, and the annotations cover safety. However, with this many closely named bioactivity siblings, the description is too sparse to fully route an agent 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%, so identifier, identifier_type (with its enum), and projection are already documented in the schema. The description adds no format hints, valid-ID guidance, or projection semantics, so 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?

It states a specific verb+resource ('Retrieve detailed bioactivity data') and narrows the scope with 'for a single identifier', which implicitly separates it from the batch_get_bioactivity_data sibling. It does not, however, distinguish it from the many summary/aed/assay bioactivity siblings that also operate on single identifiers.

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

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

The description gives no when-to-use guidance, no conditions for selecting it over get_bioactivity_summary_by_dtxsid, get_bioactivity_aed, or the batch variant. The only implicit cue is the word 'single' in an environment dense with 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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds no behavioral context of its own — no mention of result size, pagination, or what 'summary' aggregates — so it contributes nothing beyond 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?

A single front-loaded sentence with no wasted words. It is efficient, though its brevity also reflects the thin content rather than a tightly packed, information-dense definition.

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 the safety profile. However, for a tool surrounded by same-family siblings (by_dtxsid, by_tissue), the description does not supply the disambiguation an agent needs to select 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 coverage is 100% and the single aeid parameter is fully documented as 'Assay endpoint identifier'. The description only restates that as '(AEID)', adding no format, source, or lookup guidance beyond the schema, so the baseline 3 applies.

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 (Fetch) and resource (bioactivity summary data) scoped to an assay endpoint ID. The AEID keying distinguishes it from get_bioactivity_summary_by_dtxsid and get_bioactivity_summary_by_tissue, though it never explicitly names those siblings or contrasts itself with 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?

No when-to-use, when-not-to-use, or alternative is stated. The agent must infer from the name alone that this is the right choice when it holds an AEID rather than a DTXSID or tissue, and nothing in the description guides that decision against the near-identical sibling tools.

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 and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that — it does not say what the summary aggregates, whether the DTXSID must be pre-resolved, or how missing data behaves. With annotations doing the heavy lifting, this earns a low score for adding no new behavioral context.

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 short sentence with no filler and the resource front-loaded after the verb. It is efficiently sized, though its brevity reflects under-specification rather than tight editing of rich content.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The remaining gap is disambiguation from the by_aeid and by_tissue siblings, which the description does not address and which is the primary decision an agent faces here.

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?

There is one parameter with 100% schema description coverage, so the schema already documents the DTXSID input; per the rubric this sets a baseline of 3. The description's phrase 'for a chemical' adds only marginal meaning beyond the schema and name.

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 (fetch) and resource (bioactivity summary data) and hints at the chemical-keyed scope. However, it never distinguishes itself from the two near-identical siblings get_bioactivity_summary_by_aeid and get_bioactivity_summary_by_tissue, so the agent must infer the keying from the tool 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 when-to-use guidance, no statement of prerequisites, and no mention of the alternative summary tools keyed by assay endpoint or tissue. An agent choosing among three sibling summary tools gets no routing help from the description.

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, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered structurally. The description adds nothing beyond that – no auth requirements, rate limits, or data-scope caveats – so it contributes little behavioral context on top of 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?

A single front-loaded sentence with no filler, appropriately sized for a simple two-parameter read tool. It could arguably carry one more clause of routing guidance without becoming bloated.

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

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

For a simple read tool with rich annotations and an output schema, the description is minimally sufficient. However, given the dense cluster of near-identical bioactivity summary siblings, it lacks the routing information an agent needs to select 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%, so both dtxsid and tissue are already documented in the schema (including the liver example). The description restates the two dimensions but adds no format, identifier syntax, or validity details beyond the schema, making the baseline 3 correct.

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 (Fetch) and resource (bioactivity summary data) with the scoping dimension (chemical + tissue). This distinguishes it from sibling summary tools like get_bioactivity_summary_by_dtxsid and get_bioactivity_summary_by_aeid via the tissue grouping, though it never names those alternatives 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 when-to-use guidance, no prerequisites, and no mention of when to prefer this over the closely-related get_bioactivity_summary_by_dtxsid or get_bioactivity_data siblings. The agent must infer the routing from the name alone.

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, idempotentHint, destructiveHint=false, and openWorldHint, covering the safety profile. The description adds nothing beyond them - no note on the 6-way subset selector, no indication of what the returned payload contains or how large it may be.

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 short sentence with no wasted words, but its brevity comes from under-specification rather than disciplined editing. Nothing is front-loaded because there is nothing of substance to front-load.

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 description leaves key agent decisions unanswered: which of the six subset values to request and how this differs from the batch and extra-data siblings. For a lookup tool with a required identifier pair and a rich enum, this is under-described.

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 identifier, id_type enum, and subset enum are already documented in the schema. The description contributes no additional parameter meaning, so the baseline of 3 applies.

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 'Get detailed information about a chemical' is essentially a restatement of the tool name and title, adding no distinguishing scope. It does not separate this tool from siblings such as batch_get_chemical_details, get_chemical_extra_data, get_chemical_fate_details, or get_chemical_details' own single-vs-batch variant.

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, no prerequisites, and no mention of alternatives. An agent cannot tell from the description when this should be preferred over search_chemical, resolve_chemical_identifier, or the batch sibling.

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 annotations already declare read-only, idempotent, non-destructive, and open-world behavior, so the description's main additional value is naming the data categories returned (functional use, use cases). It does not add auth, rate-limit, or other behavioral context, nor does it contradict 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?

A single front-loaded sentence with no wasted words. It is efficient, though its terseness contributes to the vagueness captured in other dimensions.

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 simple one-parameter shape, rich annotations, and presence of an output schema, the description is minimally adequate. However, the ambiguity of 'extra' and absence of any sibling differentiation leave a meaningful gap for correct tool selection.

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 single parameter (dtxsids) is already documented in the schema. The description adds no additional meaning about the parameter format or usage, which is the baseline expectation when the schema does the heavy lifting.

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 clear verb (Fetch) and resource (extra chemical data) with example data types, but 'extra' is vague and the description does not distinguish it from closely related siblings like get_exposure_functional_use or get_chemical_details. An agent can identify it as a read fetch but not precisely what scope it covers.

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 no when-to-use guidance, no conditions for selecting this tool over alternatives, and no mention of prerequisites. The many sibling tools that also retrieve chemical or exposure data make the lack of routing guidance a notable gap.

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 annotations already establish that this is read-only, idempotent, open-world, and non-destructive. The description adds no behavioral context beyond that, such as scope, output characteristics, or authentication needs.

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

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

It is a single, front-loaded sentence with no wasted words. The purpose is stated immediately.

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

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

The tool is a simple retrieval operation with one well-documented parameter, rich annotations, and an output schema, so the description does not need to explain return values. It is mostly sufficient, though it leaves the relationship to the summary sibling slightly implicit.

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% for the single dtxsid parameter, and the schema itself explains it as a DSSTox Substance Identifier. The description adds no further meaning to the parameter beyond saying it is for a chemical.

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: retrieve detailed environmental fate data for a chemical. It implicitly distinguishes itself from get_chemical_fate_summary through the word 'detailed', though it does not explicitly name the sibling.

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 no explicit guidance about when to use this tool versus alternatives such as get_chemical_fate_summary. The intended usage is only weakly implied by 'detailed environmental fate data' and there are no exclusions or prerequisites.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond the purpose statement (no note on what the summary contains or filtering behavior), but it does not contradict the annotations either.

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 redundancy. It is efficient, though its brevity is arguably under-specification rather than true 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?

An output schema exists, so return values need not be explained, and the tool is simple (2 params). The main gap is the lack of any routing guidance relative to get_chemical_fate_details, leaving the agent without enough to disambiguate in this dense sibling set.

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 both dtxsid and the optional property_name filter are already documented in the schema. The description adds no parameter meaning beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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 (Retrieve) and resource (environmental fate summary) scoped to a chemical, which is clear on its own. However, it offers no differentiation from the sibling tool get_chemical_fate_details, so an agent cannot tell from the description alone which one to pick.

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 guidance on when to use this tool versus the closely named get_chemical_fate_details sibling, nor any prerequisites or exclusions. Usage is only implied by the word 'summary' versus 'details' in the sibling name, which the description never addresses.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the output is machine-readable and enumerates what is inventoried, which is useful, but says nothing about size, format, or whether the manifest can go stale.

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. It is somewhat list-heavy but every item listed is informative about the return contents.

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 zero parameters, full schema coverage, an output schema present, and clear annotations, the description need not explain return shape. The only real omission is routing guidance, which is scored under usage guidelines.

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 takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify beyond the empty 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 and resource ('Return a machine-readable inventory') and enumerates the inventory's contents, which no sibling tool does. It is clearly distinguishable from the data-fetching siblings, though the term 'suite boundary notes' is vague about what that actually means.

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 call this manifest versus the dozens of domain tools, nor that it is a discovery/meta operation. The agent must infer its role from the name and content list alone.

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 annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that this returns controlled vocabulary values, which is implied by the name but not by annotations. It doesn't describe return format, pagination, or caching behavior; with output schema present, return format is less critical.

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 that front-loads the core purpose. It is appropriately sized for a simple lookup tool, though it could be slightly more informative without becoming verbose.

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 one-parameter read-only tool with full schema coverage and an output schema, the description is adequate but not rich. It doesn't explain the relationship to other exposure tools or what the vocabulary values represent, which would help an agent decide when to use 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 100%, and the enum values (fc, puc, lpk) are documented in the schema. The description maps human-readable names to these domains, which is helpful, but this information is largely redundant with what the schema already provides. 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 states a clear verb+resource: 'Return CPDat controlled vocabulary values'. It then lists the concrete domains (functional use, product use categories, list presence tags), which map to the enum values. However, it doesn't distinguish itself from siblings like search_cpdat or list_exposure_product_puc, leaving some ambiguity about when to call this tool versus those.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The sibling list includes search_cpdat and several list_exposure_* tools that overlap in purpose, yet the description offers no routing cues or prerequisites.

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, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing on top of that — no note on data provenance, update cadence, or what a missing DTXSID yields.

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 short sentence with no filler or redundancy. It is efficient, though that efficiency comes at the cost of substance rather than from tight editing of richer content.

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

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

An output schema exists, so return values need no explanation, and the lone parameter is documented. Still, the definition leaves 'CCD' undefined and gives no reason to pick this endpoint over its many exposure siblings, which is the main completeness gap for a one-parameter read tool.

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

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

Schema coverage is 100% with a single required dtxsid parameter that the schema itself documents as 'DSSTox Substance Identifier'. The description adds no format, casing, or identifier-resolution guidance, so the baseline 3 applies.

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 restates the tool name almost verbatim ('Retrieve CCD chemical weight fractions data' for get_exposure_ccd_chem_weight_fractions), so the agent learns little beyond the identifier itself. It does signal a read of a specific resource, but 'CCD' is unexplained jargon and there is no differentiation from the many sibling get_exposure_ccd_* 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?

No when-to-use, when-not-to-use, or alternative guidance is offered. With ~60 siblings, several of which are other CCD exposure endpoints, the agent gets no help choosing between them.

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, and openWorldHint=true, covering the safety/idempotency profile. The description adds nothing beyond that - no scoping constraints, coverage notes, or return behavior - so it contributes no behavioral value over 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 short sentence with no wasted words, and the key action is front-loaded. It is efficient, though the terseness borders on under-specification rather than optimal 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 so return values need no description, and the single param is fully documented. The description nonetheless omits what the agent most needs: the meaning of 'CCD' and how this tool differs from its exposure-functional-use siblings.

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?

There is a single parameter and schema description coverage is 100%, so the schema already fully documents dtxsid as the DSSTox Substance Identifier. The description adds no format or usage detail beyond the schema, so the baseline 3 applies.

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 verb ('Retrieve') and a resource ('CCD reported functional use data'), so the basic purpose is identifiable. However, it never explains what 'CCD' is or how this differs from the closely related sibling get_exposure_functional_use, leaving the agent to guess at the distinction.

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 offers no when-to-use guidance and names no alternatives or conditions. With a near-identical sibling present (get_exposure_functional_use, batch_get_exposure_functional_use), the absence of any routing information is a real gap.

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 the full safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lower, but the description contributes nothing beyond the safety data — no note on what 'keywords' represent, scoping, or any retrieval 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 phrase with zero filler or repetition. It is efficient, though its brevity borders on under-specification rather than genuine economy.

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 and full parameter coverage, the definition is minimally sufficient for a one-param lookup. What is missing is domain context (what CCD keywords are) and sibling differentiation, which an agent would need to route 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?

One parameter with 100% schema description coverage ('dtxsid' documented as DSSTox Substance Identifier), so the schema carries the burden. The description adds no syntax, format, or example beyond what the schema already provides, which is the baseline-3 case.

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 verb (retrieve) and a resource (CCD general use keywords), so the basic action is identifiable. However, 'CCD general use keywords' is opaque jargon, and with six sibling tools named get_exposure_ccd_* the description does nothing to distinguish this one from get_exposure_ccd_functional_use, get_exposure_ccd_puc, etc.

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, no prerequisites, and no mention of any alternative. The agent gets no signal about when this keyword lookup is preferable to the other CCD or exposure endpoints in the sibling set.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no note on data scope, latency, or the open-world nature of the biomonitoring lookup that would justify the openWorldHint. It simply restates the retrieval.

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 clause with zero filler. It is efficiently stated, though the extreme brevity is under-specification rather than tight, purposeful concision.

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?

Because an output schema exists and parameter coverage is 100%, the description needn't explain return values or inputs. What remains missing is differentiation from the CCD sibling family, which matters here given the density of same-prefix tools. Adequate but with a clear routing gap.

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% with a single required parameter (dtxsid, 'DSSTox Substance Identifier'), so the schema fully documents the input. The description adds no extra semantics beyond the schema, which is the expected baseline of 3.

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 verb (retrieve) and a resource (CCD biomonitoring data), identifying the underlying dataset. However, it does nothing to distinguish this tool from its five CCD siblings (get_exposure_ccd_puc, get_exposure_ccd_production_volume, get_exposure_ccd_keywords, etc.), and 'CCD biomonitoring' is left unexplained. Vague on what makes this dataset distinct.

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, no exclusions, and no mention of alternative CCD tools. The agent gets no signal on when this specific CCD endpoint is the right one versus the other four CCD calls.

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 fully declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the description is not obliged to restate them. But it adds nothing beyond them: no note on data coverage, recency, units, or what a missing record looks like. Net behavioral value contributed is essentially zero.

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

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

One short sentence with no wasted clauses, but its brevity comes from omission rather than precision. It is front-loaded but contains almost no information payload.

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. Still, with a large family of similar exposure/CCD tools and no siblings named for disambiguation, the description leaves the agent unable to confidently pick this tool over its neighbors or understand what 'production volume' data entails.

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% for the single dtxsid parameter, so the schema already carries parameter meaning; per the baseline this is a 3. The description does not add format, resolution, or lookup semantics beyond what the schema field description states.

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?

It gives a verb (Retrieve) and a resource (CCD production volume data), so the purpose is identifiable at a basic level. However, among many near-identical siblings (get_exposure_ccd_puc, get_exposure_ccd_monitoring_data, get_exposure_ccd_keywords, etc.) it makes no attempt to explain what 'CCD production volume' is or how it differs from those neighbors, so an agent must guess 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 when-to-use guidance, no mention of required inputs, prerequisites, or alternatives. The only clue about invocation is the required dtxsid in the schema, which the description never references.

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, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond this — no note on data source, coverage limits, or what a missing PUC record yields — so it contributes essentially zero behavioral context.

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 five-word sentence with the resource front-loaded and zero filler. It is efficient, though the extreme brevity borders on under-specification rather than disciplined 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?

An output schema exists, so return values need not be described, and the tool is a simple one-parameter read. Still, nothing explains what a CCD PUC record represents or how it relates to the other exposure siblings, leaving the agent to guess at selection.

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 single required dtxsid parameter is documented as 'DSSTox Substance Identifier' in the schema itself. The description adds no syntax, format, or identifier-resolution guidance beyond that, so the baseline 3 applies.

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 clear verb ('Retrieve') and a specific resource ('CCD Product Use Category data'), so the agent knows what domain object is returned. However, it offers no differentiation from nearby siblings such as list_exposure_product_puc or get_exposure_ccd_functional_use, and 'CCD'/'PUC' acronyms are left unexplained.

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 indication of when this tool should be chosen over the many other exposure/CCD siblings (e.g. get_exposure_product_data, list_exposure_product_puc). No prerequisites, no exclusions, no alternatives named — the agent must infer usage 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 already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that – no hint about data source, coverage, or what 'reported' means as opposed to modeled or predicted use, which is the kind of context that would earn credit here.

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 zero padding, which is appropriate for a simple lookup. It is efficient, though its brevity is more a symptom of under-specification than of disciplined editing.

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 explanation is not required, and the annotations carry the behavioral profile. Still, given the dense cluster of functional-use siblings, the description is too thin to let an agent confidently choose and scope this call.

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?

Only one parameter (dtxsid) and schema description coverage is 100%, with the schema itself labeling it 'DSSTox Substance Identifier'. The description adds no meaning beyond the schema, so the baseline 3 applies.

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 clear verb ('Retrieve') and resource ('functional use data'), so the basic purpose is legible. However, it does nothing to distinguish itself from several close siblings such as get_exposure_ccd_functional_use, batch_get_exposure_functional_use, get_exposure_functional_use_probability, and list_exposure_functional_use_categories. An agent cannot tell from the description which functional-use endpoint is the right one.

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 offers no when-to-use guidance, no prerequisites, and no mention of alternatives. With four sibling tools covering functional-use-adjacent data, the absence of routing guidance is a real gap. Usage has to be inferred 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 already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds only that outputs are probability predictions, a minor restatement of the tool name, and discloses no auth requirements, rate limits, or model caveats.

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, front-loaded sentence with no wasted words. It is appropriately sized for a simple one-parameter retrieval 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?

The output schema exists, so return values need not be explained, and the schema plus annotations cover parameter meaning and safety. However, with many overlapping exposure siblings, the description lacks enough context to confidently choose this tool over get_exposure_functional_use or related alternatives.

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 input schema has 100% description coverage for the single dtxsid parameter, so the schema already defines its meaning. The description adds no parameter syntax, format, or filtering information beyond that baseline.

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 specific verb and resource ('Retrieve functional use probability predictions'), so the core action is clear. However, it does not distinguish this tool from closely named siblings such as get_exposure_functional_use or list_exposure_functional_use_categories, leaving the agent to infer the difference.

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 no when-to-use guidance, no prerequisites, and no alternatives. Usage is only implied by the required dtxsid parameter and the tool name, which is insufficient for selecting among many exposure-related 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without the description. The description adds nothing beyond that — no note on what the HTTK payload contains, whether a missing DTXSID errors or returns empty, or any caveats.

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 sentence is short and front-loaded but does no work — it conveys no information beyond the tool name, so it is under-specified rather than genuinely concise. This matches the LOW-tier pattern where brevity reflects missing content, not efficiency.

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 one simple parameter, an output schema, and full annotations the structured metadata covers most of the interface, but the description leaves the agent unable to tell what HTTK output is or when this tool beats search_httk or batch_get_exposure_httk. For a tool sitting in a large exposure/httk family, that routing information is the missing piece.

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 the single dtxsid parameter is fully documented as "DSSTox Substance Identifier", so the schema carries the load. Per the baseline rule for high coverage, 3 is appropriate; the description adds no format hints or examples beyond what the schema already states.

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?

"Retrieve HTTK data" essentially restates the tool name and title without saying what HTTK data means, what entity it is keyed on, or how it differs from the sibling search_httk and batch_get_exposure_httk. An agent cannot distinguish this from its siblings without opening the schema.

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, no prerequisites, and no mention of alternatives such as search_httk (search) or batch_get_exposure_httk (multiple IDs). The single-ID vs. batch distinction is left entirely to inference from the tool 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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds nothing beyond that — no note on scope, data source, or what 'list presence' records contain — so it earns no credit for behavioral context.

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

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

It is a single short sentence with no bloat and the resource is front-loaded, but the brevity reflects under-specification rather than economy of expression. There is nothing to trim because there is almost nothing there.

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

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

An output schema exists so return values need not be described, but for a domain-specific exposure tool the description never explains what list-presence data represents or how it differs from the batch and tags siblings. Given the large sibling set, this leaves a real selection gap.

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% with a single documented parameter (dtxsid = DSSTox Substance Identifier), so the baseline of 3 applies. The description adds no meaning beyond the schema, such as whether the identifier is validated or what happens for unknown IDs.

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 'Retrieve list presence data' essentially restates the tool name get_exposure_list_presence in different words, adding no specificity about what 'list presence' means. It also fails to distinguish this from siblings batch_get_exposure_list_presence or list_exposure_list_presence_tags.

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, no prerequisites, and no mention of the batch variant or the tags-listing sibling that an agent must choose between. The agent is left to infer selection criteria entirely from the tool 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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, covering the safety profile. The description adds nothing beyond that – no mention of what an "aggregate" contains, aggregation granularity, or any behavioral constraint. It neither contradicts nor enriches 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?

A single short phrase with zero filler, so nothing needs trimming. It is front-loaded, though the extreme brevity edges toward under-specification rather than economical clarity.

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

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

An output schema exists, so return values needn't be described, but the description fails to clarify what "MMDB aggregate" means relative to the single-sample and by-medium variants, which is exactly what an agent needs in this dense sibling set. Too thin 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% for the single dtxsid parameter, so the schema carries the burden; baseline 3 applies. The description adds no meaning about how dtxsid is interpreted or what form the aggregate takes.

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 verb ("Retrieve") and a resource ("MMDB aggregate records"), so the basic purpose is identifiable. However, it does not distinguish this tool from close siblings like get_exposure_mmdb_aggregate_by_medium or get_exposure_mmdb_single_sample_by_dtxsid, and "aggregate records" is left undefined. Vague on scope.

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 use this tool versus the numerous sibling MMDB/exposure tools. The name hints at dtxsid-based lookup, but the description itself offers no context, prerequisites, or alternatives.

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