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

Annotations already declare readOnlyHint and idempotentHint, so the safety/idempotency profile is covered. The description adds real context beyond that: the snapshot hash binds the decision to supplied evidence and the tool performs no data fetching, clarifying that this is a pure deterministic evaluation over provided 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?

Three sentences, each earning its place: purpose, prerequisites/ordering, and a scope/immutability constraint. The key information (what it does) is front-loaded with no filler.

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

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

An output schema exists, so return values need not be explained, and the schema is fully documented. The description supplies the pipeline context and immutability/no-fetch semantics needed to call it correctly; only edge behavior on rule failure is unmentioned.

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 all seven parameters and baseline is 3. The description goes beyond it by explaining the semantic role of snapshotHash (binding the decision to supplied evidence) and by framing the three candidate arrays as the rule inputs for a single snapshot.

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 (apply), the exact rule set (base, duplicate, overlap), and the scope (one immutable candidate snapshot returning final rule outcomes). It is clearly distinguishable from the three sibling tools it consumes, since this is the terminal aggregation step rather than a detection/validation step.

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

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

Explicitly states the prerequisite tool sequence: use after validate_thresholds, remove_duplicate_candidates, and detect_overlapping_epitopes when their inputs are ready. It also sets a negative scope boundary ('does not fetch new evidence'), though it doesn't say what to do if prerequisites are unmet.

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 read-only and idempotent semantics, and the description adds real context beyond them: RDKit mode has a runtime dependency, and lightweight mode produces estimates that are explicitly labeled as such (a quality/provenance disclosure). It does not say what happens if the RDKit runtime is absent, which is the one remaining behavioral gap.

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

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

Three sentences, front-loaded with the action and followed by placement and exclusions; every clause carries information. Slight density in the second sentence ('does not predict binding or prepare 3D ligand coordinates') bundles two distinct exclusions, 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?

With an output schema present, return values needn't be described, and the description covers prerequisites, method trade-offs, and scope exclusions. What's missing is modest: whether descriptor coverage varies by method, and the failure mode when RDKit is unavailable.

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%, so the baseline is 3, but the description adds meaning the schema does not: 'method' selects between RDKit and lightweight algorithms with different fidelity, and 'smiles' is the sole structure input to the calculation. It still doesn't enumerate allowed method values or explain how runId/compoundId scope the result.

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 (calculate) plus a specific resource (molecular descriptor values) with the input medium (SMILES) and the two method families (RDKit vs lightweight). It draws clear boundaries against siblings such as predict_synthetic_binding and prepare_ligand by saying it does not predict binding or prepare 3D coordinates.

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

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

Explicitly positions the call in the workflow ('Use after validate_compound') and adds two negative conditions (no binding prediction, no 3D ligand prep). It stops short of naming the specific sibling tools to use for those excluded jobs, so routing is implied rather than spelled out.

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 cover read-only/idempotent safety, and the description adds real behavioral context beyond them: results carry source provenance, and LIVE_ONLY mandates the live service with no cache/fixture substitution. It stops short of describing failure behavior when the live service is unavailable or how partial coverage is reported.

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

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

Three tight sentences: what it does first, when to use it second, source semantics last. There is no filler and no restatement of the tool name.

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

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

With an output schema present, return values need no explanation, and annotations plus 100% schema coverage handle safety and parameters. The description supplies the remaining essentials: calculation scope, source authority, provenance, and sibling disambiguation.

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%, including the fallbackPolicy enum semantics, so the schema already carries parameter meanings and the baseline of 3 applies. The description only echoes the popular concept of 'allele restrictions and population IDs' without adding format or constraint 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?

Specific verb+resource: 'Estimate HLA population coverage for supplied peptide-allele associations,' with the input domain narrowed to peptide-allele associations. It also explicitly contrasts with the sibling calculate_synthetic_population_coverage, so the agent can discriminate without opening either 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?

States the precondition for use ('when the allele restrictions and population IDs are known') and routes the demonstration case to calculate_synthetic_population_coverage explicitly. The LIVE_ONLY/fixture caveat adds a second usage constraint rather than leaving it to 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 cover the read-only and idempotent profile, and the description adds genuine behavioral context: the AlphaFold-only provenance constraint and the rejection of experimental B-factors. It also hints at the output shape (residue scores vs. metric summary with source context), which goes beyond what the annotations declare.

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?

Front-loaded with the primary action and mode, followed by the disambiguation clause, then the return summary. The final sentence largely restates what the output schema already declares, so it is slightly less tight than it could be.

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, and annotations, the description only needs to supply routing and constraint context — which it does. The main omission is untested edge behavior, e.g. what happens if both PDB bytes and confidence metrics are supplied.

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 baseline is 3. The description's framing of the two input modes (PDB bytes vs. caller-supplied metrics) mildly reinforces the branch semantics between structurePdbBase64 and confidenceMetrics, but adds no formats, limits, or mutual-exclusivity rules beyond the schema text.

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 ('Extract per-residue AlphaFold pLDDT') and covers the second mode ('summarize supplied confidence metrics'). It explicitly distinguishes itself from adjacent tools (solvent exposure, epitope probability), so an agent can route correctly 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?

Gives clear context for use ('inspect local model confidence') plus explicit exclusions — not solvent exposure, not epitope probability — and a hard input constraint ('experimental PDB B-factors are not accepted as pLDDT'). It stops short of naming the sibling tools it defers to, so the exclusion is descriptive rather than a direct routing instruction.

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 and idempotentHint, so the description isn't needed for safety. It still adds real context: the live path requires FreeSASA and PDB bytes, and the output is computed accessibility rather than epitope probability. It stops short of saying what happens when FreeSASA is unavailable or how the fixture-replay path is selected, which keeps it off a 5.

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

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

Three tight sentences with no filler: capability and engine first, usage and routing second, prerequisites and output caveat last. Every clause carries information an agent needs to select and invoke correctly.

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

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

With an output schema present, return-value detail is correctly omitted, and the description covers prerequisites, the computed-not-probability caveat, and sibling routing. The one gap is the "replay an exact fixture" mode, which is asserted but never tied to a concrete parameter or condition, leaving the agent to infer how that path is invoked.

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

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

Schema description coverage is 100%, so the parameters are already documented and the baseline is 3. The description does not clarify the weakly-specified `method` parameter (it only echoes the schema's "inspect allowed schema values" and there are no enums) nor how fixture replay is triggered relative to `structurePdbBase64`. It adds little meaning 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 and resource (calculate relative solvent accessibility) plus the engine (FreeSASA) and the two operating modes (live computation on supplied PDB coordinates, or replay of a fixture). It also names the sibling it is not (calculate_structure_confidence for pLDDT), so an agent can distinguish it without reading either 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?

Gives an explicit ordering constraint ("Use after map_epitopes_to_structure when asking whether residues are exposed") and an explicit alternative for the adjacent question ("use calculate_structure_confidence for model pLDDT instead"). Both the when and the when-not are present.

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 and idempotentHint, and the description adds real behavioral context beyond them: the computation is deterministic ('demonstration'), and the result is synthetic regardless of how plausible the numbers look. That last caveat is exactly the kind of misinterpretation risk a mutation-free tool would otherwise leave open. It stops short of describing the numeric output itself, which the output schema covers.

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

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

Three short sentences with zero redundancy: what it does, the use/avoid rule with an alternative, then the output caveat. The critical warning that the output is synthetic is front-loaded and reinforced at the end.

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?

Annotations cover the safety profile, the output schema covers return shape, and the description supplies the one thing structured fields cannot express: that these numbers must never be read as a population estimate. Complete for an agent to call it correctly and interpret it correctly.

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

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

Schema coverage is 100%, so associations, populationIds, runId and classMode are all documented in the schema. The description characterises the input domain ('synthetic HLA-frequency inputs') but adds no per-parameter semantics such as how populationIds resolve against the synthetic dataset versus the authoritative source. Baseline 3 is appropriate when the schema carries the 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 and resource ('Calculate deterministic demonstration coverage') plus the input domain (synthetic HLA-frequency inputs), and explicitly names the sibling it is not — calculate_population_coverage — so an agent can route without opening either 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?

Covers when to use ('teaching or testing the coverage pipeline'), when not to use ('never as a population estimate'), and the concrete alternative ('use calculate_population_coverage for a configured authoritative source'). Nothing is left to 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 establish that this is a read-only, idempotent operation. The description adds meaningful behavioral context: fitted modes depend on real labels, rule-based output is not measured reliability, and metrics are only returned where labels support them. It does not 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?

The description is three tight sentences with the purpose front-loaded and the critical method caveat immediately following. Every sentence adds actionable information with no repetition or filler.

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

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

Given the 5-parameter schema, full schema description coverage, output schema, and read-only annotations, the description covers the key mode-selection and label requirements well. It omits sample-size details, but those are already documented in the schema.

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%, so the schema already documents all parameters. The description adds semantic meaning for the method enum by distinguishing fitted Platt/isotonic behavior from rule-based confidence and by tying fitted modes to calibration and evaluation labels.

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: fitting Platt or isotonic calibration, evaluating on labeled outcomes, or emitting rule-based confidence. It is clear what the tool does, but it does not explicitly differentiate this tool from nearby siblings such as normalize_scores or rank_candidates.

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 clear conditional guidance: fitted modes require real calibration and evaluation labels, while rule-based mode has no measured reliability. That is useful when-to-use context, though it does not name sibling alternatives or state explicit when-not-to-use conditions beyond the reliability caveat.

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 establish readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context by stating the output is deterministic and that categories retain the input evidence boundaries, though it does not discuss validation failures or category edge cases.

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

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

Two compact sentences, front-loaded with the action and result, followed immediately by sequencing and a sibling-tool distinction. There is no wasted text.

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

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

For a complex nested-input tool with an output schema, the description covers purpose, timing, determinism, and routing to the correct sibling. A minor gap is that it does not clarify relationships to adjacent steps like validate_thresholds or apply_constraint_rules, but the output schema handles return-value explanation.

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 all three parameters and their nested structure. The description only echoes the broad input categories ('scores, rules, and thresholds') and adds no parameter-specific semantics beyond that.

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 result ('Assign provisional decision categories and blocking conditions') plus the inputs that drive it ('supplied scores, rules, and thresholds'). It also explicitly separates itself from rank_candidates, which handles numeric ordering rather than category assignment.

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

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

It gives an explicit sequencing condition ('Use after scoring and rule evaluation') and names the alternative tool for a nearby but different need ('use rank_candidates for numeric ordering, not category assignment'). This is exactly the when-to-use / when-not-to-use guidance an agent needs.

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 and idempotentHint, so safety is covered; the description adds the non-obvious prerequisite that LLM mode requires configured model access, which is real operational guidance. 'Bounded agent policy' and 'deterministic mode cites supplied evidence' hint at behavior but stay abstract, so it does not reach a 5.

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

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

Three tight sentences: what it does, when to use it, and the mode constraint — front-loaded with zero filler. The only soft cost is the unexplained phrase 'bounded agent policy', which costs a small amount of clarity without wasting space.

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 description only needs to frame scope and prerequisites — which it does, including the ordering constraint and the LLM-access requirement. The residual gap is that the 'bounded agent policy' governing answers is never defined, so an agent knows the boundary exists but not where it lies.

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%, so the baseline is 3; the description still adds value by contrasting the two agentMode paths (deterministic cites supplied evidence, LLM needs model access) and by stressing that evidenceSummary must already be assembled. It does not explain the shape of the evidenceSummary object, but the schema's additionalProperties leaves that open by design.

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 ('Answer a researcher question from the supplied evidence summary') and immediately bounds the scope. It goes further than most definitions by naming what the tool explicitly does NOT do (retrieve papers, predict epitopes, run the workflow), which cleanly separates it from run_agentic_workflow and the predict_* siblings.

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

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

'Use for an explanation after evidence has been assembled' gives a clear triggering condition and ordering constraint relative to the rest of the workflow. The negative list reinforces when not to use it, but no sibling is named as the explicit alternative for the excluded cases, keeping it short of a 5.

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 and idempotentHint, so the safety profile is covered. The description adds useful behavioral context beyond that: it clarifies that the operation is purely analytical, that direct mode requires matching pose records and PDBQT bytes, and that it returns cluster assignments.

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

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

Three dense sentences carry the purpose, workflow position, exclusion, mode prerequisite, and return shape with no filler. The core action is front-loaded before the caveats.

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 schema coverage, and read-only/idempotent annotations, the description supplies everything an agent needs to decide to call it and how to satisfy direct mode. It stops short of explaining what 'replay an exact fixture' entails, which is a minor semantic gap for the FIXTURE method.

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%, so the schema already documents all six parameters and the enum values. The description still adds value by stating the cross-parameter constraint for direct mode ('matching pose records and PDBQT bytes') and by naming the clustering methods in prose.

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 ('Group supplied Vina ligand poses by coordinate RMSD') and names the supported algorithms. It explicitly distinguishes itself from the sibling run_docking by noting that it 'does not redock or measure affinity', so an agent can tell the two apart 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?

It gives a clear placement in the workflow ('Use after run_docking to summarize pose diversity') and an explicit exclusion ('does not redock or measure affinity'). What is missing is guidance on when to pick DBSCAN versus HIERARCHICAL versus FIXTURE, which is left to the enum 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 and idempotentHint, so the description's added value is scope boundaries: it works only from caller-supplied evidence and does not make a new prediction. That is useful disambiguation for an agent that might expect prediction behavior, but it stops short of noting what happens when required weight is unmet beyond the implied 'completeness' output.

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

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

Two sentences, front-loaded with the action and its outputs, then the sequencing and alternative. Every clause earns its place; no repetition of name or title.

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

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

Output schema exists so return values need no explanation, annotations cover the safety profile, and the schema fully documents all four required parameters. The remaining need for an agent is sequencing and scope, both of which are supplied.

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%, including descriptions for runId, groupKey, observations, and configuredRequiredWeight, so the schema carries parameter meaning. The description only implies that 'group' and 'required weight' must be known before calling and adds no format or constraint 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+resource: combine one candidate group of normalized observations into weighted consensus, agreement, and completeness. It distinguishes itself from compute_consensus_batch by scope (one group vs. several independent groups), so an agent can differentiate without opening schemas.

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 an explicit precondition ('use after normalize_scores when the group and required weight are known') and names the alternative for the multi-group case. Both the when-to-use and the routing rule are stated, nothing left to 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 declare readOnlyHint and idempotentHint, and an output schema exists, so the safety and return-shape burden is largely carried elsewhere. The description still adds real behavioral context: independence of per-group computation and a one-result-per-group contract. It stops short of mentioning failure behavior when required weight is unmet or the ordering of returned results.

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

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

Three sentences, front-loaded with what it does, then when to use it, then the return contract. No restatement of the name and no filler.

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

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

With annotations, a full-coverage input schema, and an output schema, the description covers what an agent needs to select and call the tool. Minor omissions remain, e.g. how a group whose observations fail the configured weight requirement is reported, but nothing essential to invocation is missing.

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 every nested parameter (runId, groupKey, observations, configuredRequiredWeight) is documented in the schema itself. The description's "groups are not pooled" line adds a useful semantic nuance about the groups array but no format or constraint 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 and resource ("Compute weighted consensus") plus the key scope modifier: separately, for multiple candidate groups, in one call. It explicitly contrasts itself with the sibling compute_consensus, so an agent can distinguish the two without opening either 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?

Names the alternative (repeated compute_consensus calls) and the condition that selects this tool (groups are already assembled). It also rules out an incorrect mental model by stating groups are not pooled together, which is exactly the inference an agent would otherwise make.

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

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

With readOnlyHint and idempotentHint already set, the description adds meaningful context: output is HTML bytes and the viewer loads its library from a CDN, a network dependency. It also notes the optional ligand and fixture-reference alternative, though it does not explain when that alternative is returned.

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

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

Three front-loaded sentences with no filler; the scope and exclusion are stated up front. The fixture-reference phrase is slightly opaque but does not bloat the description.

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 side-effect profile, so the description need not explain return values in detail. However, the unexplained 'fixture reference' fallback leaves a behavioral branch underspecified for an otherwise complete definition.

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 all seven parameters and the mode enum. The description only restates protein/ligand coordinates and does not clarify artifactRef versus base64 inputs or mode-specific requirements.

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 ('Package') and resource ('protein and optional ligand PDB coordinates into an interactive Mol* HTML viewer') and explicitly excludes pose calculation. It does not name or contrast the closest visualisation sibling, visualize_results, so sibling differentiation is incomplete.

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 a clear usage context ('after structure or docking work') and an exclusion ('this does not calculate a new pose'). It stops short of naming alternatives or prerequisites such as the required runId and viewId, so it is not a 5.

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 and idempotentHint, so safety is covered; the description adds real value by disclosing the comparison keys, that output is canonical groups, and that input provenance is preserved. It also flags a dependency on live chemistry, which is behavioral context not present in annotations. It doesn't state what happens if the live chemistry call fails, leaving a small gap.

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

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

Three compact clauses with zero filler: the mechanism, the ordering/alternative guidance, and the return/provenance behavior. The distinguishing information against the sibling is front-loaded rather than buried.

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

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

An output schema exists, so return values needn't be explained, and the description nonetheless signals canonical groups plus provenance preservation. For a two-parameter read-only tool this is nearly sufficient; only the failure/fallback behavior of the live-chemistry path is left 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%, so both runId and compounds (including sourceStatus and smiles) are already documented. The description's mention of preserving input provenance lightly reinforces sourceStatus and canonicalization, but adds no syntax, format, or constraint detail beyond the schema — 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 (compare/collapse duplicates) plus resource (compounds) and names the matching criteria (RDKit canonical isomeric SMILES and InChIKey). It explicitly names the sibling it is not — remove_duplicate_candidates, which handles epitope positions — so the agent can disambiguate without opening schemas.

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 an explicit sequencing instruction ("Use after validate_compound") and a condition ("when live chemistry is requested"), plus a clear boundary against remove_duplicate_candidates. It stops short of saying what to do when live chemistry is unavailable or when inputs are already known-unique, so it is strong but not fully exhaustive.

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 and idempotentHint, so the safety profile is covered; the description adds meaningful non-execution semantics ("without running tools," "not a live scientific call") and states what it returns (declared stages and tool permissions). It stops short of describing pagination or how approval gates are represented, which keeps it below a 5.

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

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

Three short sentences, front-loaded with the core action and immediately followed by the usage routing. No redundant restatement of the name or filler content; every clause carries 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 an output schema present and full parameter documentation, the description needn't explain return values, and annotations cover safety. It is nearly complete for a read-only inspection tool; the only thin spot is not clarifying what 'bounded' or 'future interfaces' mean behaviorally.

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 runId, runIntent, and includeFutureInterfaces are already documented in the schema. The description adds no parameter-level meaning (e.g., how includeFutureInterfaces changes the described output), 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?

States a specific verb and resource: describing the bounded workflow manifest, stage permissions, and approval gates. It explicitly distinguishes itself from run_agentic_workflow by noting it does not run tools, so an agent can pick it apart from its execution sibling 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?

"Use to inspect orchestration before run_agentic_workflow" gives both the timing (before execution) and the alternative tool it complements. The clarifying clause "this is a description, not a live scientific call" reinforces when-not-to-expect-execution, leaving little to 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 declare readOnlyHint and idempotentHint, so the safety profile is covered; the description adds the genuinely non-obvious operational requirement that live mode needs the fpocket binary installed plus PDB bytes, and warns that pocket scores are computational descriptors rather than validated affinities. It does not describe failure behavior when the binary is absent or what a fixture replay returns, which keeps it below a 5.

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

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

Three short sentences, front-loaded with purpose, then sequencing/alternative, then operational caveat. No filler and no restatement of the tool name or title.

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

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

With an output schema present, return values needn't be explained, and the description covers the two modes, the prerequisite step, the runtime dependency, and the interpretive caveat on scores. It leaves minor gaps around which mode is default and how artifact refs behave, but nothing that would cause a mis-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?

Schema coverage is 100%, so the baseline is 3, but the description earns extra credit by implying conditional parameter needs: 'Live mode needs the fpocket binary and PDB bytes' effectively ties method=fpocket to structurePdbBase64, a dependency the schema does not state. It stops short of naming the parameters or spelling out what the fixture method requires.

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 ('Run fpocket on supplied PDB coordinates to identify geometric binding pockets') and explicitly covers the second operating mode ('replay an exact fixture'). It is clearly distinguishable from the closest sibling, run_docking, which it names by role.

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

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

Gives an explicit sequencing rule ('Use after structure validation for pocket exploration') and an explicit alternative with its selection condition ('use run_docking to score a prepared receptor-ligand pair'). An agent knows both when to pick this tool and when not to.

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 and idempotentHint, so safety is covered; the description still adds real value by clarifying that the tool reports relationships rather than resolving them (no winner selection, no identity dedup) and that output derives from caller-supplied coordinates rather than external lookup. It does not explain how 'connected components' are formed or how threshold affects grouping, which keeps it from 5.

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

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

Three short sentences: purpose first, then usage/sequencing, then output scope. No filler, no restatement of the tool name, and the key routing constraint appears before the caveats.

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, the description needn't describe return values, and annotations plus full schema coverage handle safety and fields. What remains under-explained is the domain meaning of threshold in this specific operation and the shape of the 'connected components' notion, a modest but real gap for a 3-parameter analysis tool.

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

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

Schema description coverage is 100%, so the schema already documents runId, threshold, and the candidate record fields, making 3 the baseline. The description adds no threshold semantics specific to overlap detection (e.g. what value means strict vs. permissive overlap) and says nothing about candidate ordering or the required nested fields.

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

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

States a concrete verb and resource: "Find positional overlap competitors and connected components among candidate intervals." It also rules out two confusable behaviors (choosing a winner, deduplicating identities), which separates it from remove_duplicate_candidates and rank_candidates, though it does not name those siblings 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?

"Use before apply_constraint_rules when overlaps need review" gives explicit ordering and a triggering condition, and "does not choose a winner or deduplicate identities" implicitly routes deduplication elsewhere. No explicit when-not-to-use case or named alternative tool, so not a 5.

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 and idempotentHint, so the safety profile is covered. The description adds real behavioral context beyond that: results are non-mutating of scientific values, DETERMINISTIC mode consumes only supplied evidence, and LLM_PARAPHRASE requires a configured runtime — a genuine availability caveat.

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

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

Two dense sentences with no filler, front-loaded with what the tool does followed by when to use it. The mode/runtime caveat is reasonably placed, though it slightly crowds the usage sentence.

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

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

With 10 required parameters, an output schema, and full schema coverage, the description only needs to convey intent, sequencing, and mode semantics — which it does. The one gap is that it doesn't characterize how the two explanation modes differ in output, but the output schema likely covers that.

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

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

Schema description coverage is 100% and every parameter carries a description or enum, so the schema does the heavy lifting. The description only restates the input categories at a high level without adding format or constraint detail beyond the schema; 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 — 'Explain a fixed candidate category and score' — and enumerates the exact inputs (component scores, rule outcomes, provenance). The word 'fixed' plus the explicit note that it 'cannot change scientific values' separates it cleanly from siblings like rank_candidates, categorize_candidates, and apply_constraint_rules.

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?

'Use after ranking and constraints when a researcher needs a decision rationale' gives a clear pipeline position and trigger condition. It doesn't name specific alternative siblings to use instead if the agent is upstream of ranking, but the sequencing guidance is concrete.

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 and idempotentHint, so the safety/idempotency profile is covered. The description adds genuine value by clarifying that it outputs file bytes and checksum metadata and produces "not new scientific scores", and that raw and normalized scores stay separate — key behavioral facts an agent won't infer from 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?

Three compact sentences with the purpose, routing, and output nature each front-loaded and no filler. Every sentence carries distinct 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 an output schema present and annotations covering safety, the description needn't explain return values, yet it still summarizes them. It is nearly complete; a small gap is that it doesn't clarify why candidateSnapshot is optional relative to the required filters, but that is covered by the schema.

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%, so all five parameters (runId, categories, format, idempotencyKey, candidateSnapshot) are documented in the schema. The description only echoes format options and the raw/normalized separation; it adds little 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 (serialize) and resource (supplied candidate records) plus the exact output formats (JSON or CSV). It also names the sibling it is not (generate_report produces a broader report), so an agent can distinguish it without inspecting schemas.

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

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

Explicitly says when to use it ("after candidate review for a table export") and names the alternative that covers the other case ("generate_report produces a broader report"). The routing decision is fully specified.

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 and idempotentHint, so the safety profile is covered. The description adds real context beyond that: the output is checksummed, and the tool serializes supplied data rather than deriving it ('serializes supplied evidence and metadata rather than launching predictors or docking') – an important expectation that a missing section cannot be regenerated. It says nothing about failure modes when required sections are absent, which keeps it below 5.

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

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

Three short sentences, front-loaded with what the tool produces, then when to use it, then a scope boundary. No filler and nothing repeated from structured fields.

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 7-parameter tool with deep nested objects, the description covers purpose, timing, the sibling alternative, and the non-computing nature; an output schema exists so return values need no explanation, and the schema documents every field. The remaining gap is behavior when the supplied snapshot is missing a section flagged by an include* boolean, which cannot be inferred from either structured field.

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%, including per-flag text ('Whether to include supplied ... artifacts'), so the schema carries the parameter burden and baseline 3 applies. The phrase 'selected sections' hints that the include* booleans gate package contents, but it adds no format, default, or interaction detail beyond what the schema already documents.

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 artifact ('Build a checksummed research ZIP') plus the inputs it consumes ('supplied package snapshot and selected sections'). The closing clause explicitly separates it from compute tools ('rather than launching predictors or docking') and from generate_report, so an agent can place it 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?

'Use after reports and artifacts are ready for handoff' gives a clear precondition, and 'generate_report exports individual report files' names the nearest alternative with the distinction that selects between them. It does not cover the other export siblings (export_candidates, export_workflow_trace), so the when-not guidance is incomplete rather than absent.

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 and idempotentHint, and the description adds genuinely new behavioral facts: the artifact contains inline bytes plus SHA-256 metadata, and secrets/private reasoning are omitted. It does not state size limits or what happens when traceEvents is empty/omitted, but the redaction and identity behavior are real added value.

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

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

Three tight sentences: purpose first, routing second, return/redaction behavior last. No filler and nothing repeated from the schema verbatim.

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

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

With an output schema present, return values need not be explained, and the safety profile is covered by annotations; the description still adds the redaction and digest guarantees an agent needs to trust the artifact. Minor gaps like handling of an empty or omitted traceEvents are the only omissions.

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 every parameter carries its own description, so the schema does the heavy lifting. The description reinforces the 'supplied ordered' nature of traceEvents and the redaction intent behind redactionProfile, but adds no format or constraint 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 specific verb and artifact ('Serialize ... into a redacted JSON trace artifact') plus the input resource (ordered workflow events). It explicitly contrasts with generate_report, so an agent can distinguish the two without reading schemas.

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?

'Use for audit or reproducibility after a workflow' gives a clear triggering context and the alternative 'generate_report is for the scientific summary' routes the agent away from the wrong sibling. It stops short of naming other nearby siblings such as export_research_package or export_candidates.

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 establish readOnlyHint and idempotentHint, so the safety profile is covered. The description adds genuinely non-structured context: live mode has an external dependency on PLIP, and the call returns structured contacts plus the original XML artifact. It does not say what happens when PLIP is unavailable, which would be the remaining behavioral gap.

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

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

Two sentences, front-loaded with the verb and engine, with no filler. The final clause is packed with three distinct facts (dependency, return shape, artifact) but each is load-bearing.

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

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

Output schema covers return values and annotations cover safety, and the description supplies the upstream sequencing and the PLIP dependency. However, with 4 required parameters and a required `method` whose accepted values are enumerated nowhere, the definition is not quite sufficient for an agent to invoke it without further guessing.

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 parameter meanings are already documented, which sets the baseline at 3. The description hints that `method` selects live-vs-fixture execution and that `complexPdbBase64` comes from a representative pose, but since `method` has no enum values and the schema only says 'inspect allowed schema values', the agent still cannot determine valid values from either source.

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

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

Names a specific engine (PLIP) and a specific resource (protein-ligand complex PDB contacts), and distinguishes the live computation path from a fixture-replay path. It is clearly not any of the docking, pocket-detection, or scoring siblings, though the brief 'or replay an exact fixture' clause leaves the second mode somewhat under-defined.

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?

'Use after run_docking when a representative pose has been exported' gives an explicit ordering constraint and precondition, and 'this does not experimentally measure binding' rules out a misuse (citing it as empirical evidence). It does not name an alternative sibling (e.g. detect_binding_pockets) for the case where no complex PDB exists yet, so it stops short of full when/when-not 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 and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: it mentions source provenance, fallback policy implications (LIVE_ONLY requires access), and that it does not calculate descriptors. It stops short of detailing error or rate-limit 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?

Two tight sentences front-load the core action and end with a key constraint. No filler, though the second sentence could be slightly more structured.

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

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

With annotations covering safety, a full input schema, and an output schema, the description need not explain return values. It provides enough context about sources and fallback to call the tool correctly, though it could more explicitly route to sibling 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%, so the schema already documents all parameters. The description mentions compoundRef, source, and fallbackPolicy in passing but adds little syntax or format detail beyond what the schema 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 specific verb (retrieve) and resource (compound identity and SMILES), names the two source modes (PubChem or fixture), and explicitly excludes descriptor calculation. This clearly distinguishes it from siblings like validate_compound, calculate_molecular_descriptors, and prepare_ligand.

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 says to use this 'with a known compound reference before validation or ligand preparation,' giving a clear context of use, and notes that LIVE_ONLY requires PubChem access. However, it does not explicitly name the alternative tools or state when-not to use it beyond the descriptor exclusion.

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

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

Annotations already declare read-only and idempotent behavior, and the description adds useful context that LIVE_ONLY requires network access. It also notes that results include source provenance and coordinate artifact bytes, though it does not elaborate on cache or fixture 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?

The description is three tight sentences with the main action and source options front-loaded. Every sentence contributes useful routing or behavioral context.

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

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

Given the output schema and complete parameter descriptions, the description supplies enough usage and behavior context to call the tool correctly. It does not fully explain the cache-oriented fallback policies, but the schema carries that detail.

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 all five parameters are already well documented in the schema. The description reinforces source and accession concepts and mentions LIVE_ONLY network access, but adds limited meaning beyond the structured parameter definitions.

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 PDB coordinates, AlphaFold models, or exact fixtures. It distinguishes the tool from sequence prediction, though it does not explicitly contrast with nearby siblings such as validate_structure.

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

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

It clearly says to use this when a structure accession is known and before coordinate-based analyses, and it excludes sequence prediction. It stops short of naming the alternative structure-related tools, but the context is strong.

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 and idempotentHint, and the description is consistent with them (pure enumeration, no scoring). It adds useful behavioral context by clarifying that the output is candidate windows rather than ranked results, but it does not mention edge behavior such as sequences shorter than the requested peptide lengths or invalid residues.

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

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

Three short sentences, front-loaded with what the tool does, then when to use it, then what it returns. No filler and nothing repeated from the schema.

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

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

For a 5-parameter enumeration tool with an output schema, the description covers purpose, ordering, and non-scoring semantics adequately. Minor gaps remain around failure modes (too-short sequence, invalid amino acids) and how many windows are produced, but the output schema carries the return-value burden.

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%, so the baseline is 3, but the description adds genuine semantics beyond the schema: 'one-based' indexing (which the start/end parameters never state) and the peptide/start/end/length shape produced per window. It still doesn't clarify how candidateType interacts with peptideLengths choices.

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 ('Enumerate one-based peptide windows from a supplied protein sequence') with the MHC-I/MHC-II scope. It also explicitly contrasts with the prediction siblings by saying 'this creates candidates, not binding scores', so an agent can distinguish it from predict_mhci/predict_mhcii without opening a 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?

Gives explicit pipeline positioning ('Use after validate_sequence and before prediction'), naming the sibling that precedes it and the class of siblings that follows. It also names the exclusion — this does not produce binding scores — so the boundary against prediction tools is stated, not inferred.

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 and idempotentHint, so safety is covered; the description adds genuinely new behavior: bytes are returned inline with lengths and SHA-256 hashes, and the tool does not independently fetch evidence. It stops short of mentioning payload size limits or what happens on an idempotency key conflict, so not a 5.

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

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

Three sentences, front-loaded with the action, then usage routing, then return behavior. No filler and each sentence carries distinct 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, a full output schema, and 100% schema coverage, the description only needs to add routing and scope, which it does, including the explicit "no evidence retrieval" boundary. The incomplete story is the format list disagreeing with the enum, leaving a small correctness 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%, so the baseline is 3, and the description adds little parameter-level detail beyond naming output formats. The one added detail is wrong: the description advertises Markdown while outputFormats only allows JSON and CSV, which could lead an agent to request an invalid format.

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

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

States a specific verb (render) and resource (approved report snapshot) plus the resulting artifact types, and explicitly distinguishes itself from export_candidates and export_research_package by what those return. An agent can pick the right export tool without opening any 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?

"Use after evidence review when a report is needed" gives an explicit precondition and trigger, and the sentence names both alternatives with their distinguishing outputs (candidate rows vs. ZIP). That is the when-to-use/when-not/alternatives triad in two clauses.

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 and idempotentHint, so the safety profile is covered; the description adds mode-dependent input requirements (direct-coordinate mode needs reference sequence and PDB bytes) and notes that fixture mode replays an exact case. It stops short of saying what happens on misalignment or when a mode's required inputs are missing.

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

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

Three tight sentences, front-loaded with what the tool does, then usage, then input requirements. "Returns mapped positions" is minor filler given an output schema 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?

With six parameters, an output schema, and read-only annotations, the description covers the mode split and prerequisites an agent needs. It leaves unstated how candidates' start/end/chainId are interpreted and whether structureId is required in both modes.

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 mappingMode enum description already states that DIRECT_COORDINATE uses the supplied PDB and reference sequence, so the description's mode/parameter coupling largely restates the schema. It adds no detail on candidate start/end/chainId semantics or how structureId is used in fixture mode.

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

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

States a specific verb+resource: aligning candidate sequence positions to residue coordinates in a PDB structure, plus the alternate fixture-replay mode. It is distinguishable from siblings like validate_structure and calculate_surface_accessibility without opening any 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?

Explicitly places the tool in a workflow ("Use after validate_structure when mapping sequence evidence onto a model") and routes the agent elsewhere for the adjacent task ("use calculate_surface_accessibility for solvent exposure"). Both the trigger condition and the alternative are named.

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 and idempotentHint, so the safety profile is covered; the description adds that the applied transformation is recorded and that normalized observations are returned. It does not say how unknown registry versions or malformed profiles are handled, which would matter for a versioned transform.

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

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

Three tight sentences: purpose first, then workflow position, then an exclusion and return note. No repetition of the schema and nothing that fails to earn 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?

With a full input schema, an output schema, and annotations in place, the description covers what an agent needs to place and call the tool. The remaining gap is guidance on which normalization profile or registry version to pick, which the schema alone does not resolve.

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 all three parameters are already documented, and the description only reinforces that observations are caller-supplied and the registry is versioned. It adds no detail on the profile kinds (IDENTITY, INVERSE_PERCENTILE, FIXED_MIN_MAX, LOGISTIC) or on choosing a registryVersion, so baseline 3 is right.

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?

Specific verb (transform) plus resource (raw observations into unit-interval values) with the mechanism named (versioned normalization registry). It is clearly distinct from the neighboring compute_consensus, rank_candidates, and predict_* tools, which the description explicitly separates itself from.

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?

States explicit workflow placement — 'use after evidence collection and before consensus or ranking' — which routes the agent relative to real siblings. It also names what the tool does not do ('does not fetch predictors or improve source quality'), heading off the most likely misuse.

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

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

Annotations already declare readOnlyHint and idempotentHint, and "seeded" is consistent with that idempotent claim. The description adds genuinely useful context beyond annotations: the result is "a computed proposal, not a validated vaccine construct," which tells the agent how much to trust the output. It stops short of describing convergence behavior or what happens when maximumGenerations is insufficient.

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

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

Three sentences, front-loaded with the action, then routing guidance, then the output caveat. Nothing is repeated from the schema and no sentence is padding.

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 10-parameter, 9-required tool with nested objects, an output schema, and annotation coverage, the description covers purpose, routing, and result trustworthiness. The one gap is the finalRankingSnapshotHash chaining requirement (that candidates must match the ranked snapshot), which is only in the schema and is easy to violate.

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 all ten parameters, including nested candidate fields, are already documented. The description's mention of size, coverage, redundancy, and manufacturability loosely maps to maximumConstructSize, targetCoverage, and populationWeights, but adds no syntax or constraint detail beyond the schema. 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 ("Run seeded genetic-style search over supplied candidates") plus the explicit objective terms it balances (size, coverage, redundancy, manufacturability), and names the sibling it is not (optimize_shortlist_coverage). An agent can distinguish it from the deterministic shortlist optimizer without opening either 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?

Gives an explicit precondition ("Use after final ranking when searching construct arrangements") and an explicit alternative with the condition that selects it ("use optimize_shortlist_coverage for simpler deterministic shortlist selection"). No inference required.

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 and idempotentHint, so safety and repeatability are covered structurally. The description nevertheless adds real value by stating the selection is "deterministic" and, importantly, that the output derives from the caller-supplied coverage matrix and is "not an independently measured population outcome" — a meaningful caveat about how to interpret results, which is not derivable from 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?

Three sentences, front-loaded with purpose, then routing, then the interpretive caveat. Every sentence carries information, though the third sentence is dense and would read better as a short qualifier clause.

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

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

With an output schema present, return values need no explanation, and annotations cover safety. The description supplies purpose, timing, alternative, and a caveat, which is enough for a complex 10-parameter nested-schema tool; only the interaction between optional tuning parameters (targetCoverage, populationWeights, maximumShortlistSize) is left unaddressed.

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 every one of the 10 parameters is documented in the schema itself, which sets the baseline at 3. The description gestures at the key inputs (eligible candidates, population coverage, shortlist size) but adds no syntax, defaults, or interaction rules — e.g. how maximumShortlistSize trades off against targetCoverage — beyond what the schema 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?

The description names a specific verb and resource ("select a deterministic T-cell shortlist") plus the inputs that scope it (eligible ranked candidates, population coverage, construct constraints). It also explicitly contrasts itself with the sibling optimize_construct_genetic, so an agent can distinguish the two without opening a 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?

It states the pipeline position ("use after final ranking"), the decision condition ("when shortlist size or coverage is the decision"), and names the alternative tool plus its selecting condition ("use optimize_construct_genetic for seeded construct search"). Nothing about when to pick this versus its nearest sibling is left to 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 declare read-only and idempotent behavior. The description adds useful operational context beyond annotations: live IEDB access may fail or time out, GraphBepi is fixture-only, and results include residue scores, regions, and provenance.

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

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

The description is front-loaded with the core action and method options, then follows with the method caveat and return/provenance note. Every sentence carries useful information without repetition.

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

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

Given the rich schema and output schema, the description provides enough context to call the tool correctly: what it predicts, which methods exist, how they differ, that live access may fail, and what is returned. Parameter details are adequately delegated to the schema.

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 all six parameters. The description still adds meaning for the methods parameter by naming BepiPred-3.0, Parker, and GraphBepi and warning about their differing availability and nature.

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: score linear B-cell sequence positions. It names the supported prediction methods and clearly distinguishes this B-cell tool from sibling MHC predictors such as predict_mhci and predict_mhcii.

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 clear method-selection guidance: choose explicitly, Parker is a physicochemical proxy, GraphBepi is fixture-only, and live IEDB may fail or time out. It does not explicitly state when not to use this tool versus non-predictor siblings, so it falls short of full alternatives 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 and idempotentHint, and the description goes further by disclosing that LIVE_ONLY forbids fallback substitution, that results carry method and source provenance, and that unavailable sources yield a structured failure rather than an error. That is genuine added context about failure and sourcing behavior; only auth/quota details are missing.

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

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

Three sentences, no filler, with the resource and scope front-loaded ahead of the exclusions. The final sentence is a run-on stacking three separate facts (LIVE_ONLY, provenance, structured failure) with semicolons, which is slightly dense but still readable.

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

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

An output schema exists, so return-value shape need not be explained, and annotations cover the safety profile. What remains for the description to carry — scope, sibling exclusion, source-fallback constraints, and failure behavior — is all present, so an agent has what it needs to call this correctly.

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

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

Schema description coverage is 100%, so every one of the seven parameters, including the fallbackPolicy enum values, is already documented in the schema. The description restates the LIVE_ONLY constraint already present in the fallbackPolicy field description but adds no new semantics for alleles, peptideLengths, methods, or proteinRef. 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 concrete resource (MHC-I peptide-binding observations) scoped to class-I alleles and peptide lengths, and explicitly excludes MHC-II and B-cell evidence, which separates it from predict_mhcii and predict_bcell. The verb 'Get' sits in mild tension with the tool name 'predict', leaving slight ambiguity about whether it retrieves recorded observations or runs a predictor, which keeps it from 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?

'Use for class-I evidence, not MHC-II or B-cell evidence' gives an explicit exclusion and names the competing siblings, so routing between the three predict_* tools is unambiguous. It does not cover when to prefer this over upstream siblings like generate_candidate_peptides or how to choose among the five fallbackPolicy modes, so no 5.

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 and idempotentHint, so the safety profile is covered; the description adds genuinely new behavior: source precedence via the connector/fixture policy, method and source provenance in results, and structured failure when a source is unavailable. That is exactly the kind of runtime expectation an agent needs before calling.

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

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

Three tight sentences: purpose and scope first, sibling routing second, source/failure behavior last. Every clause carries information and nothing is repeated.

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, a full-coverage schema and an output schema present, the remaining burden on the description is routing and runtime expectations — both are covered. An agent knows when to pick this tool, what source ordering implies, and what a failure looks like.

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 per-parameter meaning is already fully documented, and the description adds little beyond restating alleles and peptide lengths. The one added gloss — 'LIVE_ONLY requires the live connector' — largely duplicates the fallbackPolicy enum description already in the schema, 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 names a specific verb and resource ('Get MHC-II peptide-binding observations') plus the scoping inputs (class-II alleles, peptide lengths), and explicitly separates the tool from its siblings predict_mhci and predict_bcell. An agent can select it 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?

'Use for class-II evidence rather than predict_mhci or predict_bcell' gives an explicit alternative and the condition that selects it, and the LIVE_ONLY note flags a prerequisite for a specific configuration. There is no stated case where this tool is inappropriate beyond sibling routing, so it falls just short of a 5.

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 and idempotentHint, and the description reinforces this with 'deterministic' plus the important caveat that output 'is marked synthetic and must not be treated as binding evidence' — a genuine safety disclosure an agent would not get from the schema. The word 'Create' is not a contradiction because it describes computing values, not persisting state, but the description does not state where output goes beyond the output schema.

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

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

Three short sentences: purpose, routing rule, safety caveat — ordered by importance with zero filler. Every sentence carries distinct 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 an output schema present, a fully-described 8-parameter schema, and readOnly/idempotent annotations, the remaining burden is purpose, routing and misuse warnings — all of which the description supplies. Nothing an agent needs to call this correctly is missing.

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 all 8 parameters are already documented in the schema. The description only alludes to 'candidates and alleles' and adds nothing about method/methodVersion/datasetVersion selection, so it sits at the baseline for a fully-documented 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?

Specific verb ('Create'), specific resource ('deterministic synthetic MHC binding values'), and an explicit statement of the domain it applies to ('demos and software tests'). It is immediately distinguishable from predict_mhci/predict_mhcii, which are named in the same breath.

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 an explicit when ('only when teaching or testing the pipeline') and a when-not with the correct alternatives ('use predict_mhci or predict_mhcii for configured scientific prediction'). No inference required from the agent.

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 and idempotentHint, yet the description still adds real behavior: live preparation returns artifact bytes plus hashes, and it fails when a required runtime is absent. It also discloses the fixture-mode branch that returns a reference instead of computing. It stops short of describing pagination/size limits or how fixture mode is chosen.

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

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

Three tight sentences: the primary action comes first, then downstream ordering, then failure and return characteristics. Every clause carries information an agent needs and there is no filler.

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

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

An output schema exists so return values need not be spelled out, and the description still flags artifact bytes/hashes and the missing-runtime failure. What remains thin is how the fixture-mode path is selected and whether repeated calls reuse cached artifacts, despite the idempotent hint.

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 all four parameters are already documented in the schema, including the preparationMethod backend. The description adds only the input-to-output relationship (SMILES in, SDF/PDBQT out) rather than new meaning for individual parameters, 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 concrete resource: generate a 3D SDF and Meeko PDBQT from a SMILES, with a named alternate mode (exact fixture reference). It also differentiates from siblings by naming calculate_molecular_descriptors and run_docking in the same breath.

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 an explicit ordering rule ("Use before run_docking for a ligand") and explicitly excludes the near-miss sibling ("calculate_molecular_descriptors does not produce docking coordinates"). The agent knows both when to pick this tool and when a plausible alternative is wrong.

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 and idempotentHint, so the safety profile is covered; the description then adds genuinely new context: a runtime dependency on Meeko for live preparation, and that the live path returns artifact bytes while the fixture path returns a reference. It does not spell out failure behavior if Meeko is unavailable, which keeps it below a 5.

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

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

Three sentences, each doing distinct work: what it produces, when to call it relative to run_docking/validate_structure, and the runtime/output constraint. The primary operation is front-loaded with no filler.

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

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

For a preparation tool with full schema coverage, annotations, and an output schema, the description supplies the pipeline ordering and the runtime dependency that structured fields cannot express. The dual output form (artifact bytes vs fixture reference) is only lightly explained, leaving a small residual 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%, so all five parameters (including structurePdbBase64 and chainIds) are documented in the schema itself. The description adds only thematic context — chains, coordinates, and the Meeko-vs-fixture backend — rather than per-parameter semantics, 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 transformation: convert protein PDB coordinates plus selected chains into receptor PDBQT via Meeko, with an explicit alternate mode (exact fixture reference). It distinguishes itself from validate_structure by naming what that sibling does not do (charges, PDBQT), so an agent can place it precisely in the pipeline.

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?

"Use before run_docking for the receptor" gives explicit ordering, and "validate_structure checks coordinates but does not prepare charges or PDBQT" names the near-miss alternative and why it is insufficient. The only minor inference left is choosing fixture mode vs live mode, but the preparationMethod parameter and the 'live requires Meeko runtime' note point at that distinction.

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 and idempotentHint, so safety is covered. The description adds real behavioral context beyond them: the tool is a pure function over caller-supplied values, applies a versioned profile, and enforces a phase/completion precondition before final ranking.

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

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

Two sentences, front-loaded with the verb and resource, then the phase rule and the no-predictor caveat. The second sentence is slightly packed, 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?

For a 7-parameter tool with nested candidate unions, an output schema and annotations, the description covers the decisive facts: what is computed, the precondition for FINAL, and that predictors are not invoked. Details of candidate fields and thresholds are left to the schema, which documents them fully.

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 phase, runId, rankingProfileVersion and the completion flags. The description reinforces the phase and profile semantics but adds no meaning for thresholds or for the two distinct candidate shapes (MHC vs BCELL). 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 specific verb and resource: it calculates preliminary scores or final stable ranks from supplied evidence snapshots and completion flags. An agent can distinguish this from compute_consensus or categorize_candidates, though it never names a sibling explicitly to sharpen that contrast.

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 explicit gating: PRELIMINARY before final constraints, FINAL only after base and final constraints are complete. It also rules out a wrong expectation with 'this does not call predictors', which steers the agent to the predict_* tools for that work. No named alternative tool, so not a 5.

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 and idempotentHint, and the description reinforces them with "without changing source evidence" plus the fact that results are returned as canonical/duplicate relationships rather than applied. The disjointness rule (same peptide, different coordinates stays separate) is real behavioral information not derivable from annotations. It doesn't warn about any scale or ordering caveats, so not a 5.

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

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

Three short sentences: what it does, when to use it and the key exclusion, then what it returns and does not mutate. Front-loaded with the core action and zero filler.

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

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

Read-only/idempotent annotations cover the safety profile, the output schema covers return values, and the schema fully documents all three parameters. The description supplies the remaining gaps an agent actually needs: the dedup key, the sequencing relative to apply_constraint_rules, and the non-mutation guarantee.

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 runId, proteinHash and candidates are already documented in the schema, and baseline is 3. The phrase "positional identity" hints that start/end coordinates are the grouping key and "identical peptide strings" ties to the peptide field, but no parameter is named or clarified beyond that.

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

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

States a specific verb pair (group and choose canonical) on a specific resource (candidates) with the deduplication key named: identical positional identity. That key distinguishes it from the sibling deduplicate_compounds and from the broader apply_constraint_rules without either schema being opened.

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?

"Use before apply_constraint_rules" gives explicit ordering and names the downstream sibling, and "identical peptide strings at different coordinates remain separate" defines a scope exclusion so the agent won't over-deduplicate. It stops short of naming a competing dedup alternative or stating failure conditions, so it is strong context rather than a complete when/when-not guide.

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?

Adds substantive behavior beyond the annotations: no autonomous tool invention, approval gates pause instead of self-approving, and a plan-only outcome when toolCalls is empty. That is real operational context. Residual gap: with readOnlyHint=true declared, the description never clarifies whether delegated toolCalls (e.g. export/generate siblings) produce side effects, which is the risk an agent most needs resolved.

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

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

Three sentences, no filler, with the core execute-or-plan behavior front-loaded and the sibling differentiation last. Dense but readable; a short gloss on "bounded stage order" would have made it tighter still.

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

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

Output schema exists, so return values need not be explained, and the description covers modes, gating, and non-autonomy for a 6-parameter orchestrator. What remains thin is failure behavior and the exact meaning of stage bounding, plus the unresolved side-effect question raised by readOnlyHint.

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%, so every parameter is already described in the schema, making 3 the baseline. The description does add one genuinely useful semantic — an empty toolCalls array yields a plan rather than execution — but says nothing about agentMode, approvedToolNames enforcement, or the 46-item call cap.

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

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

Names a specific verb and resource ("Execute caller-supplied approved typed toolCalls in bounded stage order") and adds the fallback mode ("or return a plan if no calls are supplied"), so the dual behavior is unambiguous. It also contrasts itself with describe_agentic_workflow, which only inspects the manifest. The only softness is jargon ("bounded stage order") that isn't unpacked.

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?

"Use when the client has already selected inputs and allowed tools" gives an explicit precondition, and the next clause routes the agent to the correct sibling for manifest inspection. No explicit wrong-case exclusion beyond that, but the gating condition is clear enough to select between the two orchestration 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 only cover readOnly/idempotent, so the description earns credit for disclosing non-obvious traits: runtime can be substantial, scores are computational estimates rather than ground truth, and LIVE_ONLY never silently falls back to a fixture. These are exactly the caveats an agent needs before committing to a long run.

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

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

Three dense sentences with no filler: action first, prerequisite chain second, outputs and runtime caveat last. Every clause carries information an agent would otherwise have to infer.

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 13-parameter, nested-object tool with an output schema and annotations, the description covers prerequisites, fallback semantics, runtime cost, and result nature. It could say more about how the supplied box relates to dockingBoxId, but nothing essential to correct invocation is missing.

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%, so every parameter including the nested box and both enums is already documented. The description only loosely gestures at the box and mode/fallback parameters, adding little beyond what the schema states, 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 — run AutoDock Vina on receptor/ligand PDBQT bytes within a box — plus the alternate FIXTURE replay path. The sibling set (prepare_receptor, prepare_ligand, validate_docking_box) are named as prerequisites, so an agent can immediately place this tool in the docking pipeline.

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

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

Explicitly names the three prerequisite tools and the order to call them, and clarifies that LIVE_ONLY requires real Vina with no silent fixture substitution. It stops short of saying when to choose FIXTURE vs VINA beyond that hint, but the pipeline context is clear.

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 and idempotentHint, so the safety profile is covered. The description adds behavior the annotations cannot express: canonicalization via RDKit and that RDKit unavailability yields a structured failure on the live path. What is not disclosed is whether the fixture path skips RDKit entirely or what 'explicit fixture record' validation entails.

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