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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds real value beyond them: it names the upstream data source ('AlphaFold DB globalMetricValue'), discloses that output is a summary rather than per-residue, and flags the pre-screen's limitations. What it omits is failure behavior for accessions without AlphaFold models, which matters for an openWorld remote lookup.

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

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

One framing sentence plus three tight bullets, each earning its place; the scope caveat (summary, not per-residue) is front-loaded before the enumeration. No filler or restatement of the title.

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

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

An output schema exists, so the description does not need to document return shapes — yet it still gives enough of the result structure and limits to set expectations. The only real gap is the absence of any mention of the required input identifier or of what happens when a structure 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?

The description never mentions the single required input (UniProt accession) or the isoform-suffix form; the schema's own property description carries that load. With reported coverage at 0%, the description does not compensate — but the parameter is a single, semantically obvious identifier, so the gap is modest rather than disabling.

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 ('Analyze AlphaFold structural confidence using pLDDT and PAE') and immediately scopes the output ('structural reliability summary, not a per-residue profile'). This distinguishes it from neighbours like get_protein_structure, score_binding_pocket_geometry and assess_target_druggability without requiring 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?

The 'Druggability pre-screen' bullet explicitly declares what is NOT assessed ('ordered fraction and ligand suitability'), which implicitly routes the agent to assess_target_druggability for that work. However, it never states when to pick this over get_protein_structure or detect_intrinsically_disordered, so the routing guidance is partial rather than complete.

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?

Well beyond the annotations (readOnly/idempotent/openWorld), the description discloses the data sources per signal (ChEMBL, Open Targets, AF2 pLDDT, gnomAD LOEUF) and explicitly delimits their interpretation — pLDDT is 'not binding evidence' and LOEUF is 'not toxicity evidence.' It also flags the score as author-defined and uncalibrated. It stops short of describing behavior under missing/partial signal data or any latency/caching traits.

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 purpose and output taxonomy, then a numbered breakdown that maps one-to-one onto the four signals, closing with the caveat. Slightly verbose with bold formatting and some redundancy between 'author-defined' and 'uncalibrated,' but nearly every line 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?

An output schema exists, so return structure needn't be explained, and annotations cover the safety profile. The description conveys the scoring inputs and their epistemic limits. The remaining gap is operational: no statement about how partial or missing signal coverage is handled, which matters for a composite score with open-world lookups.

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 at the top-level params object is 0% (only a nested object is documented), so the description must carry weight. The mention of 'approved drugs + clinical compounds' implicitly maps to include_clinical_stage, but the description never addresses the params wrapper or the UniProt accession requirement, leaving the inner schema to do the work.

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 ('druggability assessment for a protein target') and immediately names the output artifact (HOT/WARM/COLD/NOT_DRUGGABLE). The enumeration of the four integrated signals distinguishes it from single-signal siblings such as analyze_structural_confidence or score_binding_pocket_geometry.

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

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

Usage is implied by the framing as the integrative/composite scorer and by the caution that it is 'not a validated predictive model, clinical safety result.' However, it never explicitly states when to call this versus running the individual siblings, nor any prerequisites such as data availability for all four signals.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and determinism are covered. The description adds genuine context beyond them: the output is an unvalidated computational draft that requires clinical disease mechanism, inheritance, and criterion-specific validation, which materially affects how an agent should present results. It stops short of describing sources consulted or confidence/limitation reporting detail.

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 action and followed by scope limits and exclusions; no filler. The middle sentence ('Reports computational observations that may inform...') is slightly roundabout but still earns its place by framing the output. Minor tightening would make it a 5.

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 safety, so the description's job is mainly to frame intent and limits, which it does thoroughly, including the explicit disclaimer. The one substantive omission is any treatment of the input parameter contract. Otherwise an agent has enough to call this correctly and interpret the result cautiously.

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 reported as 0%, so the description needs to compensate for parameter meaning, and it does not mention hgvs or inheritance_pattern at all. Nothing is said about HGVS formatting expectations, transcript versioning, or the default 'Unknown' inheritance value. For a single nested-object parameter with no schema coverage, this is a clear gap.

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

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

The description gives a concrete verb and resource: 'Generate a draft ACMG/AMP variant classification framework,' and immediately bounds what that output is (computational observations, not a classification). That is much more specific than a restatement of the title. It does not explicitly distinguish itself from near neighbors such as generate_variant_clinical_report or triage_variant_3d, so it stops short of a 5.

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

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

Strong negative guidance: the tool does not establish criteria or assign a pathogenicity class, and is positioned as input to an expert's later disease-specific review. That effectively tells an agent when this is appropriate (preliminary evidence gathering) and when it is not (authoritative classification). It never names an alternative tool to use instead, which keeps it out of 5 territory.

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, openWorldHint, and idempotentHint, so safety is covered. The description adds the analytical shape (shared vs unique vs Jaccard), but with an output schema present this largely restates return structure rather than disclosing new behavior like computation method, limits, or 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?

Front-loads the verb+resource in the first sentence, then uses a clean 'Returns:' bullet list. The interposed 'a key analysis for drug repurposing...' clause leans slightly toward marketing but still conveys use 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?

The nested schema is well documented and an output schema exists, so the description need not enumerate return fields — yet it does, giving the agent a clear picture of shared/unique/Jaccard outputs. It is broadly complete for a read-only comparison 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?

The description only refers to 'two diseases' and adds no meaning beyond the schema, which itself documents mondo_id_a (with example), mondo_id_b, and target_limit's 1–50 range. Parameter semantics are adequately covered by the nested schema descriptions, so a baseline 3 is warranted.

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 — 'Compare the protein target landscapes of two diseases' — and the sub-bullet clarifies the output construct ('shared and unique targets'). It doesn't explicitly differentiate from similar siblings such as get_common_disease_targets or compare_proteins_topologically, so an agent must infer the distinction.

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

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

The phrase 'a key analysis for drug repurposing, identifying shared mechanisms, and understanding comorbidity' implies when the tool is valuable, but it offers no explicit when-not guidance and does not name the closely related sibling get_common_disease_targets as the alternative. Usage is implied rather than prescribed.

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

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

Annotations already indicate readOnlyHint and idempotentHint, reducing the burden. The description adds value by explaining the output is a pairwise distance matrix, the metric details, and emphasizing it is not Wasserstein. No contradiction with annotations, and it provides useful behavioral context beyond them.

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 concise (approx. 150 words), well-structured with purpose, metric details, applications, and caveats. Each sentence adds value, front-loaded with the core action. No redundancy or filler.

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

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

Given the tool complexity, presence of output schema, and annotations, the description covers purpose, metric, applications, and limitations thoroughly. It provides sufficient context for an agent to decide when to use it and interpret results, without needing to replicate schema or output details.

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

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

Schema description coverage is 0% per context, so the description should compensate. It mentions 'provided proteins' but adds no details about uniprot_ids beyond what the schema already states (list of UniProt accessions, 2-10). Without additional format or validation info, it fails to compensate for low schema coverage.

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 explicitly states the tool compares multiple proteins using TDA-fingerprint distance, specifies the distance metric (L2 on 64-dim vectors), and contrasts with Wasserstein distance. It distinguishes from sibling tools like compute_topology_fingerprint by focusing on pairwise comparison. This is specific, with a clear verb and resource.

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

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

The description lists applications (drug-repurposing triage, off-target screening, cross-species comparison) and states it is not a functional or sequence-similarity measure, guiding appropriate use. However, it does not explicitly advise against using it for other purposes or compare with specific sibling tools, missing some discrimination.

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?

Goes well past the annotations (readOnly/idempotent/closed-world) by disclosing H0/H1 at a 15-Å Vietoris-Rips 2-skeleton, that H2 is NOT computed, the 4-Å fallback behavior, and that the result flags which method ran. It also covers external dependency (fetching the AlphaFold model) and the no-structure case, which is exactly the kind of behavioral context structured fields can't convey.

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

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

The function is front-loaded in the first sentence and the caveat stack follows in a sensible order. There is some redundancy — the GUDHI-vs-fallback story is stated twice (once mid-paragraph, again in the 'Full persistent homology needs the optional [tda] extra' sentence) — which could be collapsed.

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 single-parameter tool an agent could trivially misuse as a general structural-biology answer, the description supplies the failure modes (no AlphaFold model), the degraded-mode flag, the dimensionality, and the scientific limits. Return values are already covered by the output schema, so nothing an agent needs before calling 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?

Only one parameter, and the schema itself fully documents it with a format description and a strict accession/isoform regex, so the description's baseline of 3 is appropriate. The description merely echoes 'uniprot_id' in backticks without adding resolution, isoform, or lookup-failure semantics 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 ('Compute a rotation-invariant topological fingerprint of a protein's fold') and pins down the concrete output (an exploratory 64-dimensional geometric/topological feature vector from Cα coordinates), so the agent knows exactly what it gets. It never names the obvious close sibling 'compare_proteins_topologically' (or 'get_protein_structure'), so the pairwise-vs-single-protein distinction must be inferred.

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?

Clear context for use: the agent is told the full homology path requires the optional [tda]/gudhi extra, that a coarse fallback runs otherwise, and that the tool is explicitly NOT a substitute for sequence alignment, RMSD, or functional-homology assessment. That rules out several misuses, but it stops short of naming the sibling tool to choose instead when a comparative topological analysis is actually wanted.

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, idempotent, closed-world, but the description goes well beyond them: it discloses the 50-pLDDT cutoff, the data source (PDB C-alpha), that PDB numbering is not SIFTS-mapped to full-length UniProt, that legacy fields are deprecated aliases, and repeatedly that outputs are not validated disorder calls. This is exactly the ambiguity-reducing context a caller needs.

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

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

The key caveat is front-loaded well, but the text is long for a one-parameter tool and repeats the same disclaimer three times (labels describe model geometry, legacy fields are not validated assays, this is not a validated predictor). The literature citation at the end is also marginal for tool selection and could be trimmed.

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 need not enumerate return values, and it still characterizes them (residue indices, PDB chain/residue IDs, run positions). Caveats and deprecation notes are thorough; the only gap is the lack of explicit routing against the similar structural-confidence sibling.

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

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

There is only one parameter and the property carries its own description of the accession/isoform format, so the schema does most of the work. The description contributes one genuinely useful input-level fact — that residue indices are model-local PDB numbering and are not mapped to full-length UniProt — which affects how the caller must interpret the input/output correspondence.

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 opening sentence gives a specific verb and object (flag low-confidence modeled regions as disorder candidates) and the following sentence explains the exact mechanism: pLDDT from PDB C-alpha records, contiguous runs below 50. It is clear what the tool computes, though it never names a sibling such as analyze_structural_confidence, which plausibly operates on the same pLDDT data, so the differentiation is implicit rather than stated.

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

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

Usage context is implied ('screening heuristic', 'disorder candidates') and there is explicit guidance on which output fields to trust ('Prefer low_plddt_* fields'), but there is no statement of when to choose this over the clearly related sibling analyze_structural_confidence or get_protein_structure, and no prerequisites beyond the UniProt accession.

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. The description adds return format and example usage, but does not disclose pagination, error handling, or auth requirements. Adds modest value beyond 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 concise with a clear front-loaded purpose statement, bullet lists, and a helpful code example. Slightly longer due to example but earns its place.

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

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

Given the tool's complexity (nested params, output schema exists), the description covers purpose, use cases, and provides an example. It does not need to detail return values since output schema exists. Adequately complete.

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

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

Schema already provides descriptions for both parameters (tables and limit_per_table). The description includes an example using the 'tables' parameter but adds no new semantic meaning. Baseline 3 applies as schema coverage is sufficient.

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

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

The description clearly states the tool exports knowledge-graph data for downstream analysis, with specific verb 'Export' and resource 'knowledge-graph data'. It distinguishes from sibling lookup/query tools by focusing on bulk export.

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

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

The description provides explicit use cases (loading into pandas, R, etc.) implying when to use. However, it does not explicitly state when not to use or name alternative tools, though sibling tools are distinct.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavioral context by explaining the per-seed resolution rules and warning that graph contents depend on ingestion or retained historical versions. It does not mention pagination, size limits, or what an empty/partial neighbourhood looks like, but the core caveat about data provenance is the most valuable part.

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

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

One-line purpose statement up front, followed by a single dense sentence enumerating the three resolution branches. Nearly every clause carries information; the only slight waste is the semi-related note about where the store came from, which is valuable but could be trimmed.

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

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

An output schema exists, so return-value detail is unnecessary, and the description covers seed handling, traversal scope, and data provenance. One residual tension: it says it expands the 'immediate neighbourhood' while max_hops defaults to 2 with a maximum of 3, leaving unclear whether a 2-hop default exceeds 'immediate'.

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?

Although the coverage metric reports 0%, the schema itself carries a rich 'seed' description with three concrete examples and a min/max/default-annotated 'max_hops'. The description still adds real meaning beyond that by stating what each seed kind resolves to (gene symbol to proteins and variants, UniProt to its stored protein record, MONDO to indicated drugs), which is not derivable from the schema examples.

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 leads with a specific verb+resource ('Traverse the local knowledge graph from a seed entity') and then defines exactly what the traversal returns for each of three entity types, which is far more precise than the title's 'Drug-Gene-Disease Network'. It does not explicitly name the sibling it replaces (e.g. map_disease_drug_landscape or get_disease_targets), so differentiation remains inferential.

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

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

The seed-type breakdown implicitly tells an agent when this tool applies, and 'the store is populated by the storage API, or retained from historical database versions' signals that results are bounded by what was ingested. However, there is no explicit when-not guidance and no alternative tool is named for broader or live queries.

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

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

The description goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) by detailing the ranking algorithm, scoring formula, candidate list size, empty result behavior, and caveats about the composite score. This provides comprehensive behavioral insight.

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 well-structured and front-loaded with the core purpose. While it is relatively long, every sentence adds value given the tool's complexity. There is no redundancy, so it earns a 4.

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

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

Given the tool's complexity and the presence of an output schema, the description is remarkably complete. It covers purpose, usage, algorithm, return structure, edge cases, and caveats, ensuring the agent has all necessary context.

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

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

The input schema already provides clear descriptions for all three parameters with defaults and constraints. The tool description does not add new parameter-level semantics; it only references parameters in the algorithm. With schema coverage at 0% (description adds no param info), the baseline of 3 is appropriate.

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

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

The description clearly states it ranks clinical-stage drugs as repurposing candidates for a disease, and explicitly distinguishes from the sibling tool map_disease_drug_landscape. This meets the criteria for a specific verb+resource+scope with sibling differentiation.

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

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

The description provides explicit guidance: use this tool for repurposing candidates; for the full drug picture use map_disease_drug_landscape instead. This qualifies as explicit when/when-not/alternatives.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds meaningful interpretive context: the distances are exploratory, the GUDHI and geometric-proxy methods are distinguished per result, and there is deliberately no cross-method conservation ranking. This is valuable disclosure beyond the annotations.

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

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

The description is compact and front-loads the core reporting purpose before adding important caveats about interpretation and method distinction. It is appropriately sized, though the line breaks split closely related caveats rather than organizing them into a more scannable structure.

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

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

The presence of an output schema reduces the need to explain return values, and the annotations cover safety and open-world behavior. However, for a specialized cross-species structural tool, the description is missing explicit usage routing and parameter guidance, leaving it only minimally complete.

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

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

The description does not explain the required gene_symbol parameter or the optional target_species parameter, including the Ensembl naming expectation or the maxItems limit. Given the low schema description coverage signal, the description fails to compensate for parameter documentation gaps.

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

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

The description states a specific reporting purpose: ortholog sequence identity plus exploratory structural distances. It also clarifies that distances are not calibrated evolutionary, functional, binding, or cross-reactivity measures, which distinguishes it conceptually from more interpretive structural-comparison tools, though it does not explicitly contrast sibling tools.

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

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

Usage is implied through terms like 'exploratory structural distances' and explicit caveats that the results are not calibrated for evolutionary, functional, binding, or antibody cross-reactivity conclusions. However, it never explicitly states when to choose this tool over alternatives such as compare_proteins_topologically or analyze_structural_confidence.

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 safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description adds real behavioral context beyond them: it preserves source classifications and computational observations separately rather than fusing them, and it explicitly labels ACMG-related signals as 'unassessed' and out of scope for tier assignment. Not disclosed: latency/cost of hitting seven databases, behavior on unresolved or invalid HGVS, or partial-source failure handling.

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

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

Front-loaded with the core claim, then scope, then a scannable numbered source list, then two negative boundaries. The seven-item list is long but each entry adds real information about coverage. Minor redundancy between the closing sentences and the earlier 'does not assign an independent clinical tier' statement.

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 read-only aggregation tool with a populated output schema, the description supplies what the structured fields cannot: the exact source coverage, the separation of source classification from computed signal, and the two claims the tool deliberately does not make. Return values needn't be explained given the output schema, and no destructive or permission behavior needs stating for a readOnly 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?

The description never mentions any parameter by name — include_drug_context, include_population_breakdown, include_literature_evidence, and the UniProt accession/residue pair are only discoverable in the schema. The seven-source enumeration does implicitly signal that drug context (ChEMBL) and literature evidence are opt-in surfaces, but no defaults or gating logic are conveyed. Nested property descriptions are detailed, so the schema carries the semantics and a 3 baseline 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 first sentence names a specific verb and artifact ('Generate a multi-source variant interpretation report') and the second scopes it to 'a single HGVS variant' aggregating seven named upstream sources. It also draws explicit negative boundaries against siblings — no independent clinical tier / ACMG criteria (classify_variant_acmg) and no 3D structural impact (triage_variant_3d) — so an agent can separate it from the aggregator-vs-classifier-vs-structural tools 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?

It clearly establishes the use case: one HGVS variant, research-grade aggregation across seven databases, with exclusions for ACMG tiering and structural computation. What is missing is a positive routing statement naming which tool to use instead when the agent does want a clinical classification or structural triage; the boundaries are conveyed by negation rather than by naming the alternative.

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 provide readOnlyHint and idempotentHint. The description adds that it queries Open Targets live, returns a JSON string with error handling (per-disease errors inline, not raised), and returns a JSON error object for invalid categories or filters. No contradiction with annotations.

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

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

The description is concise and well-structured. The first sentence states the core purpose, followed by usage guidelines, limitations, and behavior. Every sentence adds value without redundancy.

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

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

Given the existing annotations and output schema (not shown but present), the description is complete. It explains the return format (JSON string with category, disease count, profile object), error behavior, and alternative tools, leaving no critical gaps for agent usage.

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

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

The input schema already provides descriptions for all three parameters, so the description doesn't need to add much. It mentions the 'category' parameter with an example and the 'disease_name' filter, but does not add new syntax or format details beyond the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool profiles top drug targets for a curated set of common diseases in one call, using verb 'profile' and specifying the resource. It distinguishes itself from the sibling tool 'get_disease_targets' by noting it is the category-level multi-disease counterpart.

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 'Use this for a fast landscape scan across a whole disease area' and contrasts with 'get_disease_targets' for single diseases. It also states what not to do: 'does not accept a raw MONDO ID', providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds real value beyond them: it defines the 0–1 evidence-score scale per data type and explains that drug_count and tractable are per-row observed values that are null only when the source omits them.

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 purpose and example are front-loaded, which is good, but the seven-bullet evidence-type glossary is reference material that likely duplicates the output schema and dilutes the operative guidance. Roughly half the text is data dictionary rather than call guidance.

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

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

With an output schema present, the description need not explain return values, and annotations cover safety. What an agent needs to call correctly — ID formats accepted, score semantics, default filtering behavior, and an end-to-end example — is all present.

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

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

The schema itself documents all four parameters, so the schema-coverage signal understates the situation. The description still adds meaning: it clarifies what the score threshold (min_score) is measuring via the per-data-type breakdown, defines 'tractable' as any Open Targets tractability bucket, and gives a worked example with a concrete MONDO ID and limit.

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

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

States a specific verb and resource — 'Return top protein targets for a disease' with Open Targets evidence scores — which is far more precise than the bare name. It doesn't, however, explicitly distinguish itself from the directionally-opposite or overlapping siblings get_target_diseases, get_common_disease_targets, and compare_disease_target_overlap.

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

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

Usage is only implied: the example call shows invocation syntax, but nothing says when to prefer this over get_target_diseases (gene→disease direction) or get_common_disease_targets (multi-disease). No prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds behavioral detail about the output (HPO phenotypes, constraint scores, interpretation) beyond what annotations provide.

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?

Description is structured with a clear first sentence, a usage sentence, a bullet list of returns, and an example. It is relatively concise but the bullet list partially repeats the first 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?

Given the presence of annotations and output schema, the description covers purpose, usage context, and output structure. It omits explicit mention of the boolean parameter's default behavior (though schema covers it) and does not clarify the return format.

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 already describes gene_symbol with examples and include_constraint with default and description, so parameter semantics are well-covered. The description adds only a code example, which is helpful but does not significantly increase understanding 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?

Description states 'Return all HPO phenotypes associated with a gene, plus gnomAD constraint.' This is a specific verb+resource combination that clearly distinguishes it from sibling tools like lookup_phenotype or search_diseases.

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?

Description includes 'Useful for understanding the clinical consequences of variants in a gene before requesting structural context,' which provides clear context and workflow positioning. However, it does not explicitly mention when not to use the tool or list alternatives.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds useful specifics about what statistics are returned (entity counts, size, activity) without contradicting 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?

Two sentences, front-loaded with purpose, no wasted words. Every sentence earns its place.

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

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

No parameters, annotations cover safety and idempotency, output schema covers return values. Description adds the remaining context about what stats are included, making it fully complete.

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

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

No parameters exist, baseline 4. Description adds meaning by specifying what the returned statistics cover, which is valuable for understanding the tool's output.

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?

Description clearly states it returns statistics about the local knowledge graph, listing entity counts, database size, and last activity. This distinguishes it from sibling tools which perform more specific analyses or queries.

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?

Description indicates usefulness for understanding current contents and coverage, providing clear context for when to use. Does not explicitly state when not to use, but no sibling serves the same stats purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, so safety is covered; the description goes further by enumerating returned fields (entry ID, pLDDT, download URLs), flagging the legacy-only PAE image URL, warning that coordinates are large, and documenting the structure_available:false coverage-gap behavior. That is meaningful context beyond the structured fields.

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

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

Front-loaded with the core purpose and the key routing rule, then returns and edge cases. Every section earns its place, though the field enumeration and the four-sibling list make it longer than strictly necessary for a single-parameter read tool.

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

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

With annotations, an output schema, and nested params already present, the remaining burden is edge-case behavior and routing — both covered (structure_available:false, legacy PAE image caveat, non-overlapping sibling scopes). 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 reported as 0% at the top level, but the nested parameter descriptions are actually informative; the description reinforces include_coordinates by explaining it embeds the full PDB coordinate text and that it is large. It adds size/behavior guidance beyond a bare boolean, though it does not add anything about uniprot_id 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?

Starts with a specific verb+resource ('Retrieve a protein's AlphaFold model') and explicitly calls itself 'the single entry point for getting the predicted structure itself,' which cleanly separates it from siblings that interpret structures. An agent can identify this as the retrieval tool 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?

States the when-to-use rule directly ('use the sibling structure tools for interpretation rather than retrieval') and names four alternatives with their distinct scopes: analyze_structural_confidence, score_binding_pocket_geometry, compute_topology_fingerprint, detect_intrinsically_disordered. This is explicit routing, not 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 readOnly, idempotent, and openWorld hints. The description adds that it uses Open Targets and returns a 'full disease landscape,' but does not clarify that the 'limit' parameter may restrict results (creating a minor inconsistency). Overall, behavioral traits are well communicated.

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

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

The description is three sentences: purpose, use case, and example. It is concise, front-loaded, and every sentence adds value.

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 output schema and annotations, the description covers key aspects: input, output, and example. However, it does not address the 'limit' parameter's effect on completeness (calling it 'full' but limit applies), which is a minor 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?

The input schema provides detailed descriptions for each parameter (e.g., limit, ensembl_id, uniprot_id), so the description does not need to repeat. The description adds a usage example but no extra semantic value. Baseline of 3 is appropriate due to high schema coverage.

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

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

The description clearly states the tool's function: 'Return all diseases associated with a protein target via Open Targets.' It specifies the input (UniProt accession) and output ('full disease landscape'), and distinguishes it from siblings like get_disease_targets by focusing on target-to-disease mapping.

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

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

The description indicates usage context: 'essential for target-validation and indication-expansion.' While it does not explicitly compare to alternatives or state when not to use, the purpose is clear enough to guide appropriate selection.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the useful detail of what the payload contains (synonyms, cross-refs, hierarchy), but says nothing about behavior when the ID is unknown/invalid or about the hierarchy toggle's effect — and since an output schema exists, the return-field list is partly redundant.

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 core action, then a tight bulleted field list and one concrete example. Efficient and scannable, with only the example sentence being arguably redundant for an agent that already sees 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?

With annotations covering safety and an output schema covering return shape, the description needs only to state what is fetched and from where, which it does thoroughly. The remaining gaps — not-found/error behavior and the include_hierarchy flag — are minor for a single-ID read tool.

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

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

Schema description coverage is reported as 0%, so the description must carry the load. It supplies the MONDO ID format via the worked example ('MONDO:0005010'), which helps, but it never names include_hierarchy or explains that hierarchy retrieval is optional and defaults on — it merely asserts the output includes parent/child terms.

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 ('Retrieve a disease record from the MONDO unified disease ontology') and enumerates exactly what the record contains. It is distinguishable from search_diseases by being an ID-based single-record fetch, but it never names that sibling explicitly to make the contrast airtight.

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

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

Usage is only implied: the reader infers 'use when you already hold a MONDO ID.' There is no explicit when-to-use/when-not statement, no mention of resolve_icd10_to_mondo or search_diseases as the path to take when you don't yet have an ID, and no prerequisites listed.

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, openWorldHint, and idempotentHint, which cover core behavioral expectations (safe, idempotent, open-ended results). The description adds useful context about returned content (phenotype label, definition, diseases, parent terms) and an approximate result size. However, it does not disclose any potential limitations, rate limits, or authentication requirements, leaving the agent to infer from annotations alone.

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

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

The description is extremely concise: three sentences of core info plus a concrete example. No redundant or vague language. It front-loads the purpose and then lists return fields in a clear bullet-like manner. Every sentence earns its place.

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

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

Given that the tool has an output schema (not shown but indicated), the description need not detail return format. It covers the main return categories (phenotype label, definition, synonyms, diseases, parent terms) and provides an illustrative example. However, it omits error handling (invalid HPO ID) or pagination details for disease_limit, which would enhance completeness for an agent.

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

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

The input schema provides descriptions for all three parameters (hpo_id, disease_limit, include_diseases) with types, defaults, and constraints. Since schema description coverage is effectively 100%, the description adds no extra semantic value for parameters beyond the example usage. Per guidelines, baseline is 3, and the description does not enhance 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 clearly states the action ('Retrieve an HPO phenotype term') and the resource ('with associated disease annotations'), and lists specific return fields. The example with a concrete HPO ID and expected result ('~400 associated diseases') solidifies understanding. It naturally distinguishes itself from sibling tools like lookup_disease or search_diseases.

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

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

The description implies usage when you have an HPO ID and want phenotype details plus associated diseases. However, it provides no explicit guidance on when to choose this tool over alternatives (e.g., lookup_disease, search_diseases), nor does it mention prerequisites or exclusion criteria. The default disease_limit and parameters hint at typical use, but direct comparison is 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 readOnly/openWorld/idempotent, so the safety profile is covered. The description does add value beyond them by disclosing the underlying sources (Open Targets, ChEMBL, MONDO hierarchy) and calling the result 'bounded' and 'source-attributed', but it never explains what 'bounded' actually constrains, how expensive/long-running the multi-source aggregation is, or what happens when a disease has no approved drugs or targets.

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 title and first paragraph are well front-loaded with the verb, resource, and scope. However, the final sentence about business development and R&D portfolio decisions is marketing padding that adds nothing an agent can act on, and the output list is split awkwardly between the first and second sentences.

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

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

An output schema exists, so return values need not be described, and the tool's read-only, idempotent nature is annotated. What remains thin is operational: no indication of aggregation cost, partial-failure behavior across three external sources, or expected result size for a broad disease – gaps that matter for an openWorld composite tool but are not fatal.

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?

Coverage is reported as 0%, so the description is the only prose channel, and it only says 'for a given MONDO disease' – it does not restate the MONDO:\d{7} format, note that the single required param is mandatory, or warn that non-MONDO identifiers will fail. The schema's regex pattern does most of the work here, keeping this at a minimum-viable 3 rather than lower.

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 ('Map ... therapeutic landscape for a disease') and enumerates concrete outputs: approved drugs, pipeline agents, druggable targets, and a summary. It implicitly separates itself from lookup-style siblings, but never names the neighbors an agent might confuse it with (get_disease_targets, find_drug_repurposing_candidates, compare_disease_target_overlap).

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

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

The closing sentence ('used in business development, competitive intelligence, and R&D portfolio decisions') hints at the intended context but is audience framing, not invocation guidance. There is no explicit when-to-use / when-not-to-use, and no criterion distinguishing this composite landscape tool from the narrower sibling tools that return subsets of the same data.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint. Description adds behavioral context: pipeline steps, resolution from phenotype to diseases to targets, and that it returns UniProt IDs for AlphaFold retrieval. Consistent with annotations. Could mention potential time/network dependency but not required.

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?

Reasonably concise with bullet points and an example. No wasted sentences, but could be slightly tightened (e.g., combine first two lines). Still very usable.

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

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

Given the tool's complexity (multi-step pipeline, three parameters, output schema exists), the description explains the complete workflow, provides an example, and references a follow-up tool. Output details are covered by output schema. No gaps.

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

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

Schema descriptions already cover all parameters (hpo_id format, disease_limit and targets_per_disease ranges). Description adds value by showing how parameters fit into the pipeline and provides a concrete example, making the interaction understandable beyond raw 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?

Clearly states the tool maps a clinical phenotype to protein structures of disease targets. The pipeline explanation (HPO → diseases → targets → UniProt IDs) makes the specific verb and resource unambiguous. Distinguished from siblings by its multi-step mapping nature.

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

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

Provides an example and mentions using the returned UniProt IDs with analyze_structural_confidence, but does not explicitly state when to use this tool versus alternatives like lookup_disease or get_disease_targets. No when-not-to-use guidance for the many sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, but the description adds genuinely new behavioral context: no upstream API is called, results are bounded to what was previously written, and empty output has a specific meaning. It does not mention pagination behavior or whether the query costs anything, which keeps it from 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?

Front-loaded with the core definition and the local-vs-live distinction, with no filler sentences. It is slightly verbose, with a parenthetical about earlier database versions and repeated empty-result framing, but every element contributes.

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 and an output schema covers the return shape, so the description's remaining job is disambiguation and empty-result interpretation, both of which it handles thoroughly. For a read-only filtered-list tool, nothing an agent needs to call it 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?

Context reports 0% schema description coverage (the filters are nested under the required `params` wrapper), so the description must compensate, and it does explain the key non-obvious semantics: filters AND together and an omitted filter leaves that dimension unconstrained. It never names the individual filters (limit, min_plddt, druggability_tier) or their ranges, so an agent still needs the schema for the actual knobs.

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 ('Recall proteins already stored in the local knowledge graph') and immediately scopes it as local-recall rather than live lookup. It names the specific siblings it is not (assess_target_druggability, analyze_structural_confidence), so it is distinguishable from the 29 other tools 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 an explicit when/when-not split: use this for stored proteins, use the two named live-source tools for proteins that may not be stored yet. It also states that an empty result means 'not in local store,' not 'absent from biology,' which prevents a common misuse of the result.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so the bar is lower, but the description adds real value beyond them: no upstream API calls, data served from local SQLite, population only via the knowledge-graph write API, and an explicit caveat that legacy rows may be illustrative rather than verified biology. That provenance warning is exactly the kind of context annotations cannot carry.

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?

Four short sentences, front-loaded with the action, then reading behavior, then the provenance caveat an agent most needs before trusting results. Nothing is repeated from the schema or annotations.

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 shape need not be explained, and the read-only annotations carry the safety profile. The description covers the source-of-truth question well; the only omission is anything about result ordering, empty-result meaning, or how the nested filters interact.

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

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

The top-level 'params' wrapper has no schema description (reported coverage 0% at that level), and the description says nothing about any filter — gene, tier, min_am_score, max_gnomad_af, clinvar_class, limit — nor how filters combine. It does not compensate for the coverage gap; an agent must read the nested properties to learn anything. Nested property descriptions exist, which prevents a score of 1.

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 first sentence states a specific verb and resource ('Search the local knowledge graph for stored variants') and the second restates the return behavior. This clearly separates it from compute-oriented siblings like triage_variant_3d or classify_variant_acmg, though no sibling is named 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?

Usage is only implied: the note that data is local and populated only through explicit writes tells an agent that a miss means nothing was stored rather than that the query was wrong. There is no explicit when-to-use versus when-to-use-an-alternative guidance, and no exclusion of other variant tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds context about the mapping purpose and provides an example, but does not disclose any additional behavioral traits such as error behavior or rate limits. With strong annotations, the description is adequate.

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 4 sentences, starting with the core purpose, followed by context and an example. It is appropriately sized with no superfluous text, though the example could be more compactly integrated.

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 presence of an output schema (not shown but indicated as true), the description does not need to explain return values. It covers purpose, integration context, and usage example. It lacks information about error handling or code format validation, but for a simple mapping tool with annotations, it is sufficiently complete.

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

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

The input schema already includes a description for 'icd10_code' with format and example values. The description reinforces this with an example call but does not add new meaning beyond the schema. Schema coverage is effectively high due to the inline description.

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

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

The description clearly states the action ('Resolve'), the source resource ('ICD-10 clinical code'), and the target resource ('MONDO disease ontology terms'). It distinguishes itself from sibling tools which focus on other disease/target/phenotype operations like 'analyze_structural_confidence' or 'search_diseases'.

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

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

The description explains the context of use: 'integration between clinical / EHR data (which uses ICD-10) and the research-grade MONDO ontology'. It does not explicitly state when not to use or mention alternatives, but the sibling list provides implicit differentiation.

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?

Goes well beyond annotations by describing the pocket-detection heuristic, residue thresholds, cluster growth, pLDDT cutoff, reported metrics, uncalibrated scoring, and limitations such as centroid offset not measuring solvent exposure or ligand binding. This gives the agent rich behavioral context for a read-only, idempotent computation.

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-loads the purpose, then moves efficiently through algorithm, output metrics, scoring, and limitations. The length is justified by the scientific complexity, and no sentence is wasted.

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

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

For a complex structural-bioinformatics scoring tool, the description is complete enough: annotations cover read-only/idempotent/closed-world behavior, an output schema exists, and the description explains the heuristic, thresholds, scoring, caveats, and intended use.

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

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

The description clarifies that min_pocket_residues is a membership threshold for retaining a putative pocket, adding meaning beyond the schema field name. It does not explain the UniProt accession format, default/range behavior, or other parameter constraints, so compensation for low schema-description coverage is only partial.

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: identifying and scoring putative binding pockets from AlphaFold geometry. It clearly scopes the tool as a geometry-only pre-screen, though it does not explicitly distinguish it from related siblings such as assess_target_druggability.

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 usage context: a fast, dependency-free, reproducible pre-screen for AlphaFold coordinates, not a substitute for validated pocket detectors like fpocket or P2Rank. It does not, however, name sibling tools or explicitly state when to choose this over assess_target_druggability.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, openWorldHint=true. Description adds that results are ranked and include MONDO IDs and cross-references, providing useful behavioral context beyond 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 and an example, no wasted words. Front-loaded with purpose, then use case, then example. Highly efficient.

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

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

For a simple search tool with two well-described parameters and an output schema (implied), the description explains return format (ranked list, MONDO IDs, cross-references) and use case, making it fully adequate.

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?

Input schema descriptions cover both parameters fully (query and limit), but the description adds an example call with typical values, which aids understanding. Schema coverage is high, so baseline is 3; the example provides additional value.

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?

Clearly states the tool searches for diseases by name or keyword using the MONDO ontology, distinguishing it from lookup_disease which likely requires an exact ID. The verb 'search' and resource 'diseases (MONDO)' are specific.

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

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

Provides explicit use case: 'resolving a clinical term to a canonical identifier before querying targets or phenotypes.' Does not explicitly state when not to use or list alternatives, but 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?

Beyond the annotations, the description discloses that the tool composes upstream records and author-defined heuristics across seven sources and does not issue clinical conclusions. This adds useful provenance and scope context, though it does not address cost, latency, or why idempotentHint is false.

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

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

The description is three sentences and front-loads the core action and output. Every sentence adds relevant scope or behavioral context 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?

For a complex aggregation tool with an output schema, the description covers major evidence sources, the single-protein scope, and the non-clinical limitation. It is nearly complete, with the main remaining gap being explicit guidance on choosing this tool over composing sibling calls.

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

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

The description only says the dossier is for 'one protein' and does not explain the required UniProt accession, HGNC symbol, or the depth enum. Although nested schema fields have descriptions, the top-level parameter coverage is effectively undocumented in the description and the description does not compensate.

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

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

The description uses a specific verb and resource: generating a complete protein intelligence dossier from seven data sources, with named evidence categories. It is distinguishable from single-source siblings such as query_protein_database or generate_variant_clinical_report, though it does not explicitly name alternatives.

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

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

Usage is implied: this is the aggregate tool for one protein when a consolidated dossier is needed rather than individual queries. However, the description gives no explicit when-to-use/when-not guidance and does not mention alternatives or prerequisites.

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

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

Annotations cover safety (readOnly/idempotent/openWorld), and the description goes well beyond them: it discloses that alphamissense fields are always null, that pathogenicity_tier is returned as NOT_ASSESSED, that the structural and disease sections are stubs, and that gene-relative candidates stay unverified and the output is not a calibrated risk estimate. That is unusually candid disclosure of degraded/degrading behaviour.

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 purpose is front-loaded and the numbered structure is scannable, but the text is padded with repetition: AlphaMissense is disclaimed three separate times and 'Wave-3 roadmap' is repeated across items 3 and 4. Roughly a third of the prose restates earlier 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?

An output schema exists, so return values need no elaboration; what the description must supply is the trust profile of the report, and it does: which sections are real, which are stubs, which fields are always null, and how to get the missing data via siblings. Nothing needed to call or interpret it correctly is absent.

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?

Reported schema coverage is 0%, but the description compensates: it gives a worked HGVS example, clarifies that gene-only coordinates cannot verify allele identity, and explains what each flag actually yields (LOEUF/pLI only, a pointer note, a placeholder note). This meaningfully extends the schema, though it never discusses the undocumented 'params' wrapper.

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 opening sentence names a specific verb and resource ('Retrieve source-reported variant evidence') and the numbered list enumerates exactly which signals are fused into the report. It is clearly separable from generate_variant_clinical_report and analyze_structural_confidence, though the '3-D Structural' title oversells a tool whose structural component is only a pointer note.

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

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

It explicitly routes each missing capability to the correct sibling: AlphaMissense scoring to generate_variant_clinical_report, structural confidence to analyze_structural_confidence (with the note to resolve a UniProt accession first), and disease context to get_target_diseases(). It does not state the positive case for choosing this tool over query_variant_database or classify_variant_acmg.

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