biocontext

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

With no annotations present, the description carries the full burden. 'Fetch' implies read-only and it discloses the return shape (MF/BP/CC JSON with evidence codes), which is useful, but it says nothing about rate limits, authentication, network/API dependencies, or behavior when the gene is unknown.

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 purpose sentence followed by compact Args/Returns blocks; every line adds information. Slightly bulky for a simple fetch, but no filler.

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

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

An output schema exists, so the Returns section is redundant but harmless. All four parameters are explained despite 0% schema coverage, and the aspect filter values are spelled out. The only real gap is the absence of usage routing against the many sibling finder/lookup tools.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains query accepts a symbol, alias, or UniProt accession with concrete examples, gives the default for taxon_id (9606), enumerates the three valid aspect values, and defines limit as 'maximum annotations per aspect'. This exceeds what the bare schema provides.

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

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

States a specific verb and resource ('Fetch Gene Ontology functional annotations... for a gene or protein') and scopes it to MF/BP/CC, which separates it from siblings like get_go_term (term metadata) and get_pathways. It does not name any sibling explicitly, so an agent must infer the boundary rather than being routed.

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 arguments (aspect filter, taxon_id, limit) rather than stated: there is no 'use this when you want X, use get_go_term when you want Y' guidance. No exclusions, no prerequisites, no mention of what to do for non-model organisms or ambiguous symbols.

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

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

No annotations are provided, so the description carries the full burden. It does add useful behavioral context — concurrency control, performance metrics, a success rate in the return — which hints at partial-failure semantics. However it says nothing about rate limits, required auth, or how failed individual queries are reported.

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

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

The one-line summary is front-loaded and the Args block is tight. The Returns section is partly redundant given an output schema exists, but it is short and states the summary/success-rate/resolved-entity shape.

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 3-parameter tool with an output schema, the description covers inputs thoroughly and touches outcomes. The remaining gap is batch-specific failure behavior (what happens when some identifiers do not resolve), which is not addressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it documents all three parameters, explains taxon_id as an NCBI Taxonomy ID with the human default, and gives concrete query examples spanning symbols, aliases, Entrez IDs (7157) and UniProt IDs (P04637) — meaning the schema does not convey.

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

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

States a specific verb and resource ('resolve a list of gene identifiers/aliases in batch'), naming the batch scope that separates it from the sibling resolve_gene. An agent can route between the two without opening either schema.

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

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

Usage is implied by 'in batch' and the concurrency parameter, but there is no explicit statement of when to prefer this over resolve_gene or the other resolution siblings, nor any prerequisites. The agent must infer the batch-vs-single split.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the output shape (nodes, edges, weights, provenance), which tells the agent this is a computational read rather than a mutation. However, it never states whether anything is persisted, what the relative cost/latency of the multi-source fan-out is, or how failures in one source are handled.

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 purpose followed by a scannable layer list and standard Args/Returns blocks. The Args section largely restates the parameter names and repeats defaults already present in the schema, which is mild redundancy, but nothing is buried or padded.

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 six-parameter multi-source aggregation tool with an output schema present, the description covers the data provenance and each parameter's effect, so the agent knows what it will get and how to shape it. The notable gap is the absence of any runtime/cost expectation, which matters for a tool that orchestrates six external queries.

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

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

Schema description coverage is 0% and the schema carries only bare titles, so the description does the documenting work: it explains query as a gene symbol or alias with concrete examples, taxon_id as an NCBI Taxonomy ID defaulting to 9606, and states which data source each include_* flag toggles. It does not clarify how flags interact or whether disabling all of them still returns something useful.

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 (Construct) and resource (ontological Knowledge Subgraph centered on a biological entity) and enumerates exactly which layers get connected (UniProt proteins, Ensembl transcripts, Reactome pathways, GO terms, Open Targets diseases, Europe PMC literature). This distinguishes it from siblings like traverse_biological_graph or get_pathways, which retrieve slices rather than assemble a multi-layer subgraph.

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 layer list, but there is no explicit statement of when to use this aggregate builder versus the many narrower siblings (traverse_biological_graph, get_pathways, get_target_diseases, get_supporting_publications). No preconditions, no cost/latency warning despite this clearly fanning out to six external sources, and no exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the upstream source (Ensembl) and the shape of the result (identity and relation type), but says nothing about whether the call is read-only (it is), authentication requirements, error behavior for unknown genes, or rate limits.

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

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

Front-loaded purpose sentence followed by clean Args/Returns structure; nothing is padded. Minor redundancy in restating schema defaults and return values that the output schema already covers.

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 3-parameter read tool with an output schema and no annotations, the description covers purpose, all parameters, and return semantics. What is missing is workflow guidance (when this beats resolve_gene) and failure/edge-case behavior for unrecognized gene symbols or species.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains query accepts either a gene symbol or Ensembl Gene ID with examples for both, and documents both species parameters with their defaults and example values ('mus_musculus', 'danio_rerio'). It stops short of defining the accepted naming convention or the full species list.

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 ('Identify corresponding orthologous genes across species') plus the data source ('via Ensembl'). This is clearly distinct from every sibling (resolve_gene, get_transcripts, get_mouse_gene), so an agent can select it without opening the schema.

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

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

Usage is implied by the documented defaults (source homo_sapiens -> target mus_musculus), which telegraphs the typical cross-species lookup. However, there is no explicit when-to-use, when-not, or naming of alternatives such as resolve_gene or get_mouse_gene.

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

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

No annotations are provided, so the description carries the disclosure burden. 'Fetch' and the Returns section imply a safe read-only lookup with no side effects, but it does not state behavior on invalid/nonexistent GO IDs or any rate limits. Adequate but thin for a tool with zero annotation coverage.

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 one-line purpose followed by compact Args/Returns sections; no wasted prose. The Returns block partially duplicates the output schema, but it is short and harmless.

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 read lookup with an output schema, the definition covers purpose, argument format, and anticipated return content. The main gap is the absence of any usage routing against the numerous sibling tools, which is a moderate shortfall rather than a critical one.

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

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

Schema description coverage is 0% and the schema gives only a bare 'Go Id' string, so the description must compensate. It does so by naming the parameter, specifying its meaning ('Gene Ontology identifier'), and giving a concrete format example ('GO:0006915'). This meaningfully exceeds 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 ('Fetch') and resource ('Gene Ontology (GO) term ID') with the kind of data returned (metadata and functional definition). This clearly separates it from the many gene/pathway/publication siblings, which operate on different resources.

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

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

There is no guidance on when to use this tool versus alternatives such as get_pathway_details or annotate_function, and no mention of prerequisites or when it should not be used. The agent must infer usage purely from the resource name.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that this is a resolution/lookup operation returning a JSON string containing the gene entity and MGI identifier, which is the minimum viable disclosure, but says nothing about ambiguity handling, multi-match behavior, or error cases.

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

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

Front-loaded purpose sentence followed by tight Args/Returns blocks with no filler. Every line carries information an agent needs, and the example values are compact and useful.

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

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

An output schema exists, so return values needn't be fully explained, and the single parameter is well covered. The one real gap is guidance on when to choose this over resolve_gene or batch_resolve_genes, which for a crowded sibling set leaves an agent guessing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it enumerates three accepted identifier forms (gene symbol like 'Trp53', MGI ID like 'MGI:98834', or Ensembl ID). This is genuinely more informative than the bare 'Query' property in the schema.

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

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

States a specific verb (resolve) and resource (mouse gene details and MGI identifiers) with an explicit species qualifier (Mus musculus), which implicitly separates it from the human-oriented resolve_gene sibling. However, it never names that sibling, so the differentiation is inferable 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?

No when-to-use or when-not-to-use guidance is given. The presence of resolve_gene, find_orthologs, and batch_resolve_genes among siblings makes a routing hint valuable, and the description provides none — the query-format notes are input syntax, not usage context.

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

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

No annotations are provided, so the description carries the burden. It implicitly signals a read-only lookup ('Fetch') and discloses the returned fields, but says nothing about missing-ID behavior, error handling, or any access constraints. Adequate for a simple single-argument read, but thin on behavioral 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?

The purpose sentence is front-loaded and the Args/Returns block is compact and scannable. The Returns section is somewhat redundant given an output schema exists, but it costs little and adds no noise.

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

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

For a one-parameter read tool with an output schema present, the definition covers purpose, argument format via example, and output shape. The only meaningful gap is the absence of routing guidance relative to get_pathways, which is a minor omission at this complexity.

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

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

Schema description coverage is 0% and the single st_id property carries no description, so the description must compensate. It does: it names the parameter, defines it as a Reactome pathway stable ID, and supplies a concrete example ('R-HSA-5357801'), which is enough to format the argument correctly.

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

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

The description states a specific verb and resource: fetch detailed info for a Reactome pathway, scoped to lookup 'by its stable identifier'. That scoping implicitly separates it from the sibling get_pathways, but the alternative is never named, so the differentiation is inferred 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 is only implied: the tool takes a stable ID, so an agent can infer it is for retrieving details on an already-known pathway rather than discovering one. No explicit when-to-use, when-not-to-use, or pointer to get_pathways for lookup-by-name is given.

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

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

No annotations are provided, so the description bears full disclosure duty. 'Fetch' implies a read-only lookup and it describes the return payload (names, stable IDs, Reactome links), which is useful. However it says nothing about rate limits, network/auth requirements, error behavior, or pagination, leaving gaps for a tool with no annotation coverage.

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 purpose, then a clean Args/Returns structure. The formatting is verbose but every line carries information; the Args block is arguably redundant with the schema, but as plain text it remains readable and scannable.

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 a full return description is not required, yet the summary of returned fields adds orientation. For a read-only lookup with four well-documented params, the definition covers what an agent needs, with the only real gap being usage routing relative to siblings.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does: it gives the query format with concrete examples ('TP53', 'P04637'), explains taxon_id as an NCBI ID with the human default, and gives defaults for species and limit. This is more than the bare schema provides.

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

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

States a specific verb and resource ('Fetch biological pathways involving a gene or protein from Reactome'), so an agent immediately knows what it does. It does not explicitly distinguish itself from the sibling get_pathway_details (which presumably takes a pathway ID rather than a gene query), so it stops short of a 5.

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

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

The description says nothing about when to use this tool versus alternatives like resolve_gene, get_pathway_details, or annotate_function. It only documents parameters and defaults, leaving the routing decision entirely to inference.

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

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

With no annotations, the description carries the behavioral disclosure burden. It states the operation, the data source, and the exact JSON return shape including protein name, gene, length, mass, and organism. It does not mention error handling for invalid accessions, but for a simple read-only retriever this is a minor gap.

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

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

The description is compact and well-structured with Args and Returns sections. No sentence is wasted, and the most important information—what the tool fetches and what it returns—is front-loaded.

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-required-parameter read-only tool with an output schema available, this description is complete. It specifies the input format, gives a realistic example, and describes the returned payload, so an agent has everything needed to select and invoke it correctly.

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

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

Schema coverage is 0%, but the description fully compensates by defining the parameter as a 'UniProt accession ID' and giving a concrete example (P04637). This gives an agent enough information to construct a valid call despite the schema providing no parameter documentation.

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 ('Fetch') and resource ('structured protein details from UniProt by primary accession'), which clearly distinguishes it from the sibling gene-resolution tools. It also previews the returned fields, making the scope unambiguous.

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

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

The description makes the intended use clear: provide a UniProt primary accession and receive protein details. It does not explicitly contrast with resolve_gene or batch_resolve_genes, but the 'by primary accession' phrasing and the sibling names make the appropriate context inferable.

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

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

With no annotations, the description carries the full behavioral burden. It partially meets that: it discloses the result shape ('JSON string containing full paper metadata, abstract, and direct web links') and that lookup is identifier-keyed, which implies a read-only operation. It says nothing about permissions, rate limits, or what happens on an unresolved identifier (error vs. empty result), so gaps remain for a zero-annotation tool.

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 core purpose is front-loaded in a single sentence, followed by compact Args/Returns blocks. Every line contributes (identifier formats, return contents), though the Returns block partially duplicates the output schema and could be trimmed without loss.

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

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

For a one-parameter, read-only lookup with an output schema present, the essentials are covered: what is fetched, which identifier formats are valid, and the rough shape of the response. The main omission is guidance relative to the overlapping publication sibling and any failure-mode behavior, which matters because no annotations exist to fill that in.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it enumerates the three accepted identifier namespaces (PMID, PMCID, DOI) with concrete example values for each. That is meaningful semantic content the bare schema ('identifier: string') does not provide. It is docked only because it does not say whether formats are mutually exclusive or how ambiguity/invalid formats are handled.

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

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

The description states a specific verb and resource ('Fetch detailed metadata for a specific scientific paper') and names the three accepted identifier types, so the agent can immediately tell this is a publication lookup rather than a gene/pathway/disease tool. It does not, however, distinguish itself from the close sibling get_supporting_publications, which also returns paper-related data.

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 rather than stated: it is clearly the tool for retrieving one specific paper given an identifier, and the inline identifier examples make invocation conditions inferable. There is no explicit when-to-use guidance, no statement of when-not to use it, and no named alternative (e.g. get_supporting_publications) for the adjacent publication-retrieval scenario.

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

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It discloses the data sources (Europe PMC / PubMed) and the returned fields, but it does not mention rate limits, authentication requirements, pagination, or whether the query is substring/relevance-based. For a read-only fetch tool this is adequate but not rich.

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

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

The description is front-loaded with purpose and then uses clear Args/Returns sections. It is appropriately sized with almost no waste, though the Returns section is somewhat redundant because an output schema exists.

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

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

For a simple publication-search tool with an output schema, the description gives enough information to invoke it correctly: source, parameter semantics, and return content. The main gap is the lack of sibling routing guidance, particularly versus 'get_publication_details', but that is already penalized under usage guidelines.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains that 'query' can be a gene symbol, disease name, or scientific query string, and that 'limit' is the maximum number of peer-reviewed publications to return. Both parameters are given meaning beyond the bare schema types.

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

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

The description states a specific verb ('Fetch') and resource ('authoritative supporting scientific literature from Europe PMC / PubMed'), making the tool's basic purpose clear. It does not explicitly distinguish this tool from the sibling 'get_publication_details' or explain how the two differ in granularity or use case.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any conditions, prerequisites, or exclusions. The reader must infer that it is for literature searches simply from the tool name and 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape (diseases, 0.0-1.0 evidence scores, datatype breakdowns) and the read-only nature is implied by 'Fetch', but it says nothing about permissions, rate limits, or evidence-source details.

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

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

Well-structured and front-loaded, with the purpose sentence first and Args/Returns sections clearly delineated. Slightly verbose in the Args/Returns restatement but each line earns its place by covering the 0%-coverage schema.

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

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

For a 2-parameter read tool with an output schema present, this is nearly complete: it documents both params and even summarizes returns (redundant with the output schema but harmless). The only missing piece is any guidance on selection relative to sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate and it does: 'gene' is explained as a symbol or Ensembl Gene ID with concrete examples ('TP53', 'BRAF', 'ENSG00000141510'), and 'limit' is defined as the maximum top associations with its default. Full coverage of both parameters.

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

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

States a specific verb (Fetch) plus a precise resource (evidence-backed therapeutic target-disease associations) and names the source (Open Targets Platform). This clearly distinguishes it from siblings like get_pathways, get_go_term, and get_supporting_publications.

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 purpose (retrieve disease associations for a given gene), but there is no explicit when-to-use / when-not-to-use guidance and no named alternatives among the many sibling tools. Adequate but with a clear gap.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Fetch' implies a read operation, but the description does not disclose permissions, rate limits, authentication needs, or error behavior. The return information largely duplicates the output schema.

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

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

The description is well-structured and front-loaded: one sentence states the purpose, followed by Args and Returns sections. Every sentence is useful and there is no filler.

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

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

Given a simple two-parameter fetch tool with an output schema, the description covers the purpose, both parameters, and the return shape. The main missing piece is usage context relative to sibling tools, which prevents a perfect score.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: query is documented as an Ensembl Gene ID or gene symbol with examples, and species is documented with a default and example alternatives. It stops short of clarifying whether species accepts values beyond the two mentioned.

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: 'Fetch transcripts, canonical isoform, and exon structures from Ensembl.' It clearly states what data is returned. However, it does not explicitly distinguish this tool from siblings such as resolve_gene or get_protein_info, so it falls short of the top score.

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

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

There is no guidance on when to use this tool versus alternatives. It lists arguments and return format but does not mention prerequisites, when-not-to-use cases, or sibling tools like resolve_gene or find_orthologs.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the return content (MONDO IDs, definitions, cross-references), but says nothing about matching behavior (exact vs fuzzy), permissions, rate limits, or what happens with zero/ambiguous matches.

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 one-line purpose followed by clearly labeled Args and Returns sections; every line earns its place. Slight redundancy in restating return values that an output schema already covers.

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 two-parameter resolution tool with a required query and an existing output schema, the description gives enough to invoke correctly. It could add ambiguity-handling behavior, which is the main remaining gap.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: it explains the query accepts a name, synonym, or MONDO ID with concrete examples, and defines limit as the maximum matches with its default of 5.

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 (resolve) and resource (disease name/synonym/MONDO ID against the MONDO ontology), which clearly separates it from the gene-oriented siblings (resolve_gene, batch_resolve_genes, get_mouse_gene). An agent can distinguish it without opening the schema.

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

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

The description implies when to use it via the query semantics (name, synonym, or ID), but never states exclusions or alternatives such as when to prefer resolve_gene or batch resolution. Usage is inferable but not explicitly guided.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It does explain the return format (JSON string with canonical entity, cross-references, and match audit trail), but it does not describe what happens on no match, multiple ambiguous hits, or whether the operation is read-only. This is a moderate gap for an otherwise straightforward lookup tool.

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

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

The description is front-loaded with the purpose sentence, followed by a compact Args list and Returns line. Every sentence adds useful information and there is no filler, though the structure is slightly verbose with the docstring-style sections.

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 moderate complexity, all four parameters are documented and an output schema is present, so return structure is already covered. The description lacks explicit error/edge-case behavior and sibling differentiation, but it is otherwise complete enough for an agent to call it correctly.

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

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

Schema description coverage is 0%, yet the description fully compensates by adding meaning to every parameter: query examples (TP53, HER2, p53), default taxon_id with human-specific context, chromosome format examples, and locus_type biotype examples. Each parameter is more actionable than the bare schema types provide.

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

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

The opening sentence uses a specific verb ('Resolve') and states the exact resource and ambiguity condition: gene symbols, aliases, or accessions are mapped to an authoritative entity. This clearly differentiates the tool from batch_resolve_genes (single vs batch) and get_protein_info (resolution vs protein information).

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 a query is ambiguous and needs authoritative resolution, and it hints at optional disambiguation arguments. However, it does not explicitly state when to prefer batch_resolve_genes for multiple queries or when get_protein_info would be more appropriate, so the guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that hops report source database and score, that scores are products of weights and NOT probabilities, and that literature edges are keyword hits. It stops short of permissions, limits, or performance characteristics, but the semantic caveats are valuable.

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 purpose followed by clearly separated Args and Returns sections; each line carries information. The '(PRD-22)' tag is extraneous, but overall the structure is efficient and scannable.

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 five-parameter traversal tool with no annotations, the description covers inputs, scoring semantics, edge provenance, and the return shape. It is nearly sufficient, missing only guidance on result size/pagination and how to choose among competing graph tools.

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

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

Schema description coverage is 0% for all five parameters, yet the description documents each with an example or format ('TP53', 'MONDO:0005575', 'colorectal cancer'), numeric ranges (1 to 6, 0.0 to 1.0), defaults, and the full target_type vocabulary — fully compensating for the empty schema.

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

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

The definition states a specific verb and resource ('Enumerate graph paths from a source gene to a target entity') with the scope of traversal clearly bounded by source and target. It is largely distinguishable from siblings such as build_entity_subgraph, though it never explicitly contrasts itself with that close alternative.

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 source-to-target framing, and one conditional rule is given ('Literature edges ... are only used when target_type is publication'). However, there is no explicit guidance on when to prefer this over build_entity_subgraph or other graph/pathway siblings, leaving tool selection to inference.

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