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

Annotations already mark this as read-only, and the description goes beyond that by disclosing latency expectations (~4s vs ~15-30s), provider composition (Europe PMC, Semantic Scholar, OpenCitations, Crossref, PubMed), and the fallback rule. It does not describe output structure or pagination, but the safety profile is already covered by 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 dense sentences, with the core purpose front-loaded and each subsequent sentence adding distinct value (mode selection, provider behavior). No filler or redundant restatement of the tool name.

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

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

For a parameterized lookup tool with no output schema, the description covers the main invocation decision (mode and direction) well, but it does not clarify what the returned article/citation payload contains, nor does it resolve the confusing limit/sections parameter. This is adequate but leaves notable gaps.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds some context for citation_mode and provider roles beyond the schema. However, it omits the 'limit' parameter entirely, and that parameter's schema description is inconsistent (integer type but 'sections to include' semantics), leaving a real ambiguity unresolved.

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 and resource: 'Get article by PMID/PMCID/DOI', and enumerates the exact identifier formats accepted. This clearly distinguishes it from sibling article_search, which would be used for queries rather than known identifiers.

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

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

The description establishes the context for use (you have a known identifier) and gives concrete guidance for selecting citation_mode (fast vs full with latency and provider tradeoffs) and the auto-fallback behavior. It does not explicitly name alternatives like article_search or state when not to use this tool, so it stops just short of a 5.

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

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

The description adds behavioral context beyond annotations: it reveals federated search and deduplication. Annotations already indicate read-only and open-world. The description could further explain deduplication logic or result ordering, but its current level is satisfactory.

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 two sentences, front-loads the main purpose, and contains no fluff. Every word 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?

Despite no output schema, the description fails to explain what the tool returns (e.g., list of articles with fields, pagination info). For a search tool with 5 parameters and no output schema, this is a significant 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 coverage is 100%, so parameter descriptions are already present. The main description does not add extra parameter meaning beyond the schema. The limit and dateRange parameter descriptions in the schema are helpful, meeting the baseline threshold.

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 'Search literature across multiple backends with federated search and deduplication' clearly states the action (search), resource (literature), and key differentiators (multiple backends, federated, deduplication). This distinguishes it from siblings like article_get (single article) and other domain-specific searches.

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 it is for cross-source literature search, but provides no explicit guidance on when to use this tool versus alternatives like individual backend tools (e.g., pubmed directly). It lacks when-not advice or when to prefer other search tools among siblings.

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

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

The readOnlyHint annotation already establishes this as a safe read operation, and the description adds the parallel-execution behavior. However, it does not disclose failure modes, partial-result behavior, ordering guarantees, or batch 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?

The description is a single concise sentence with no redundant wording. The core behavior and primary distinguishing trait, parallel retrieval of multiple entities, 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?

There is no output schema, so the description should explain what the tool returns or at least hint at response behavior, but it does not. It also omits guidance on invalid IDs, mixed entity types, or relationship to sibling single-get tools, leaving the agent with only the input schema to work from.

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

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

Schema description coverage is 100%, and the input schema fully documents the 'inputs' array, including required fields, the entity enum, and optional sections. The description adds no extra parameter semantics but also does not need to compensate for a schema 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 states a specific action ('Get') and resource ('multiple entities in parallel'), making the batch nature clear and distinguishing it from the single-entity get_* siblings. It is not fully explicit that the entities are selected by 'id' or that the entity types are limited to the enum, but the input schema supplies that detail.

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 'multiple entities in parallel' implies the tool is for batch retrieval rather than repeated single calls, but the description does not explicitly say when to prefer batch_get over gene_get, variant_get, etc. No exclusions or thresholds are provided.

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

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

Annotations indicate a non-read-only, destructive, idempotent tool, and the description richly expands on these traits: atomic batch writes, null removal semantics, dry-run validation, sensitive-key confirmation, write refusal outside project roots, env masking, and pending-restart behavior. There is no contradiction with 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 long but appropriately so for a tool with three actions, hard rules, and restart semantics. It is structured with clear headings, compact bullet-like action definitions, and illustrative examples; the front-loaded purpose and action summary make it easy to scan.

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 no output schema, the description compensates by explaining what status returns, how filtering works, what happens on invalid writes or dry runs, and how the response guides env-parameter setup. It also covers sensitive keys, project-root refusal, dependency prerequisites, and the post-change verification workflow, making the tool safely callable without additional documentation.

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 schema already describes all six parameters at 100% coverage, the description adds substantial semantic context beyond the schema: valid filter categories and dotted-id prefixes, the meaning of empty values as null-removal, the distinction between feature-section reset and key-list reset, and the behavior of dry_run and confirm_sensitive.

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: inspect and configure biomcp's parameters across feature groups and environment-only settings. It clearly distinguishes this tool from the biomedical query siblings by scoping it to biomcp configuration, and it enumerates the three actions and the config file involved.

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

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

The description gives explicit when-to-use guidance for each action: status for inspection, set for creation/modification, reset for removal, plus filter usage for detailed rows. It also states hard exclusions — environment parameters are never settable here and env var values are never displayed — and provides concrete examples and a restart workflow.

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, indicating safe read operations. The description adds minimal additional behavioral context (e.g., 'free-text concept resolution'), but does not disclose details like result count limits, pagination, or how the resolution works.

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 (two noun phrases), which is efficient but lacks structure. It front-loads the key action but omits any sentences or additional details, making it borderline insufficient.

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 many sibling tools and lack of output schema, the description is incomplete. It does not explain return format, result count, or how discover differs from specific entity searches, leaving the agent uncertain about its utility.

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

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

Schema coverage is 100% and the schema already describes the 'query' parameter with examples. The description's phrase 'free-text query' adds no new meaning beyond the schema, so it meets the baseline without improvement.

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 'Free-text concept resolution - find entities matching a free-text query' clearly identifies the tool's purpose as resolving free-text queries to entities, distinguishing it from specific entity search siblings. However, it does not specify what types of entities (e.g., biomedical concepts) are resolved.

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 like disease_search or drug_search. It does not mention any context or exclusions, leaving the agent to infer usage from the free-text nature.

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=true and openWorldHint=true. The description adds that the data comes from OpenTargets, which is behavioral context but does not disclose other important traits like rate limits, pagination, or data freshness. It does not contradict annotations.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core function.

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?

While the tool is simple with two parameters and no output schema, the description lacks information about the expected output format or any caveats. Given the large number of sibling tools, more context on when this tool is appropriate would improve completeness.

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 provides minimal descriptions for disease_id ('Disease ID') and limit (just 'limit'), with 50% coverage. The tool description does not add any additional explanation about the parameters, leaving their meaning and usage unclear, especially for 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?

The description clearly states that the tool retrieves drugs for a given disease via OpenTargets, using a specific action verb and resource. It distinguishes itself from sibling tools like disease_trials or gene_drugs by specifying the data source and relationship.

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 the tool should be used when drug information for a disease is needed, referencing OpenTargets as the data source. However, it does not explicitly state when to prefer this tool over alternatives like gene_drugs or disease_trials, nor does it provide exclusions.

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

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

Annotations already provide readOnlyHint and openWorldHint, so the safety profile is known. The description adds that the response is 'detailed,' but it does not explain how sections or limit affect the returned data or what the response shape looks like. It adds some context without being fully transparent.

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 concise sentence with no redundant wording. The key selector, 'by ID,' is placed at the end but the overall structure is clear and 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?

This is a simple read-only lookup with one required parameter, and the schema covers the important inputs. With no output schema, 'detailed disease information' gives a reasonable expectation of the return value. The description is complete enough for this level of tool 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?

Two of the three parameters (disease_id and sections) already have useful schema descriptions, and the description reiterates the central role of the ID. However, the limit parameter is undocumented in both the schema and the description, and the tool description itself adds no further parameter insight.

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 ('Get'), a specific resource ('detailed disease information'), and the key access pattern ('by ID'). This makes the tool's purpose immediately clear and distinguishes it from disease_search and other disease_* siblings.

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

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

The phrase 'by ID' clearly communicates when this tool should be used: when the agent already has a disease identifier. It does not explicitly name alternative tools or list exclusion cases, so it stops just short of full 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?

With annotations declaring readOnlyHint and openWorldHint, the safety profile is already covered; the description does not contradict it. It does not add details such as result ordering, empty-result behavior, or pagination behavior beyond the schema's limit/offset fields.

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

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

A single, front-loaded sentence with no filler. Every word contributes to identifying the operation and the accepted query types.

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

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

For a simple read-only search tool, the description plus fully documented parameters and safety annotations are enough to invoke it correctly. The main omission is how results feed into disease_get/disease_drugs, but that is not required to make a valid call.

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

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

Schema description coverage is 100%, and the query property already explains the search input in the same terms as the tool description. The description adds no additional meaning to limit or offset beyond their schema text.

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

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

The description names a specific action ('Search'), a resource ('diseases'), and the input modes ('name, phenotype, or keyword'), so a model can see this is the fuzzy/query entry point for diseases. It is clear, but it does not explicitly contrast with disease_get or other sibling search 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?

There is no guidance about when to choose this over gene_search, drug_search, or disease_get, and no exclusions are given. The description only states what the tool does, leaving selection 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?

Annotations already declare readOnlyHint and openWorldHint. The description adds no further behavioral context (e.g., data freshness, pagination, or authentication needs). Consistent but not additive.

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?

Single sentence, very concise. No fluff, but could be slightly more structured (e.g., specifying that it returns a list of trials). Appropriate length.

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 no output schema and many sibling tools, the description lacks details about return format, pagination (limit param), or how this differs from 'trial_search'. Incomplete for effective tool selection.

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

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

Schema has 50% parameter description coverage (disease_id described, limit lacks description). The description does not elaborate on parameter semantics beyond the schema, missing an opportunity to clarify the limit parameter.

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 'Get clinical trials for a disease' with a specific verb and resource, and it distinguishes from sibling tools like 'trial_search' or 'drug_trials'.

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

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

No guidance on when to use this tool versus alternatives like 'trial_search' or 'disease_drugs'. The description does not mention any prerequisites or conditions.

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 and openWorldHint, so the safety profile is covered. The description adds little behavioral context beyond that: it does not state return shape, exact-match behavior, or how sections and limit affect output.

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

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

The description is a single, front-loaded sentence with no wasted words. 'Detailed' is slightly generic, but the structure is clear and easy to parse.

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 get-by-name tool, the description plus schema and annotations are mostly sufficient. Missing pieces include any indication of what the response looks like or what happens when a drug is not found, but the tool's simplicity reduces the severity of these omissions.

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

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

The schema already documents the 'name' and 'sections' parameters well, including the meaning of the adverse_events section and that limit applies to reaction rows. The description only restates the name parameter; it adds no meaning beyond what the 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?

The description clearly states the verb ('Get') and resource ('detailed drug information') with a lookup key ('by name'). It is more specific than a vague tool description, but it does not explicitly contrast itself with sibling tools like drug_search or drug_trials.

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 'by name' implies this is for exact-name lookups rather than keyword search, which is useful usage context. However, no explicit guidance is given about when to choose this tool over drug_search or other drug-related alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the search scope but not additional behavioral context such as result ordering, pagination behavior, or open-world matching caveats.

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

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

A single, front-loaded sentence states the verb, resource, and search dimensions with no filler or redundancy. Every word 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?

For a simple read-only search tool, the combination of description, input schema, and annotations gives an agent enough to invoke it correctly. The lack of an output schema means return format is not explicit, but the search semantics are clear.

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

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

The schema already describes query as 'Drug name, mechanism, or keyword to search' and documents limit and offset defaults/ranges, so high schema coverage carries the parameter burden. The description essentially restates the query meaning without adding new parameter detail.

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

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

The description uses a specific verb ('Search') and resource ('drugs') and names the search dimensions (name, mechanism, keyword), making the tool's purpose clear. It does not explicitly contrast with sibling search tools, but the drug resource is unambiguous.

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

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

The description implies use for drug-related keyword searches, which is sufficient context. It does not state when to prefer this tool over an alternative or list exclusions, though sibling names suggest this is the only drug-specific search.

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, so the description needs no additional read-only disclosure. However, the description adds no other behavioral context (e.g., result scope, pagination, phase filtering). It is adequate for a simple tool but lacks depth.

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

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

The description is a single, efficient phrase with no extraneous words. It is front-loaded and 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 simplicity (one required param, no output schema), the description is mostly complete. However, it could benefit from clarifying the scope of trials (e.g., all phases) or how results are ordered. Sibling differentiation is also missing.

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

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

Schema coverage is 100% with the parameter described as 'Drug name'. The tool description adds 'for a drug' but does not provide additional meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description specifies the action ('Find') and resource ('clinical trials') and indicates the input ('for a drug'). It clearly distinguishes from sibling tools like 'trial_search' or 'disease_trials' by focusing on drug-based lookup.

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 for drug-based trial lookup but does not explicitly contrast with sibling tools like 'trial_search' (for broader criteria) or 'disease_trials'. No when-not-to-use or alternative guidance is provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description enriches this by explaining on-demand VEP behavior, that novel variants work, that non-human species are supported, and what results look like (most severe consequence, per-transcript effects, co-located variants). It also discloses the caveat that rsID resolution via dbSNP can yield less specific consequences. 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?

Four focused sentences, each earning its place: scope, input forms and preferences, return contents, sibling routing. The core purpose is front-loaded, and the alternative-tool guidance is saved for the end. No filler or redundant restatement of schema fields.

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

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

For a tool with no output schema, the description sufficiently explains return values, including impact, codon/amino-acid change, SIFT/PolyPhen, and co-located variant metadata. It also covers input formats, species support, novel-variant behavior, rsID caveats, and when to choose variant_get. Nothing critical for an agent to call this tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents variant, species, and limit. The description adds meaningful value beyond this: concrete HGVS notation examples (NM_004333:c.1799T>A, ENST00000288602:c.1799T>A), the c./p./g. notation forms, and a clear preference rule for HGVS over rsIDs. This is more than the schema alone provides, though not every parameter nuance is expanded.

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 a specific verb ('Predict'), a clear resource ('functional consequence of a variant via Ensembl VEP'), and immediately distinguishes itself from variant_get by noting that variant_get is preferred for known human variants. It also highlights unique capabilities (novel variants, non-human species) that make it easy to differentiate from 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?

Explicitly tells the agent when to use this tool: for novel variants, non-human species, and general VEP-based consequence prediction. It also provides concrete routing guidance: prefer variant_get for known human variants when deep pre-computed scores are needed, and prefer HGVS notation over rsIDs when both are available.

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 and openWorldHint=true, and the description adds useful behavioral detail: returns target stable IDs, species, taxonomy level, and percent identity, sorted by identity. This goes beyond the structured annotations by describing the result shape and ordering without contradicting the read-only hint.

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: the first sentence front-loads purpose and domain, the second covers return values and scoping, and the third gives user intent. Every sentence earns its place with no filler.

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

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

There is no output schema, but the description supplies return fields and sort order, which covers what an agent needs to interpret results. The required gene parameter and key optional scope parameters are explained with examples, making the tool complete for a read-only cross-species lookup.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining accepted gene input formats (HGNC symbol vs Ensembl gene ID) and by giving concrete examples for target_species ('mouse') and target_taxon (10090).

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 starts with a specific verb and resource: 'Find orthologues or paralogues of a gene across species (Ensembl Compara)'. It also explicitly labels itself 'the cros-species gene mapping source in biomcp', which clearly distinguishes it from gene_search, ensembl_lookup, and other 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?

It gives explicit use-case guidance: conservation questions and the example 'what is the mouse orthologue of BRAF?'. It does not name alternative tools to avoid, but the cross-species positioning and usage examples make the appropriate context 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?

The annotations already signal readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context: expand=true returns all transcripts with translation/protein IDs, versioned IDs are resolved to the current record, and species aliases are accepted. 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 front-loaded with the core purpose and output, followed by input formats and then a clear alternative routing. Each sentence earns its place and the examples make the syntax immediately usable 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?

With no output schema, the description correctly takes responsibility for explaining return values: stable ID, symbol↔ID mapping, versioned identifier, canonical transcript, coordinates, and expanded transcript details. It does not cover edge-case behavior such as not-found handling or exact default output, but for a read-only lookup tool this is largely sufficient.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that versioned IDs are resolved to the current record, that species accepts scientific names or aliases like 'homo_sapiens'/'human', and what expand=true changes about the response.

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

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

The description opens with a clear verb-resource pair: 'Resolve a gene in Ensembl terms' and enumerates the exact outputs (stable ID, symbol↔ID mapping, versioned identifier, canonical transcript, coordinates). It also distinguishes itself from gene_get by declaring that it is the identifier/structure authority.

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 tells the agent when to use a different tool: 'For rich human gene annotation (summary, pathways, drugs, diseases) use gene_get instead.' It also defines its own role as the identifier/structure authority, giving clear selection guidance among siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context beyond this: output is capped at the limit with a truncated marker, the current assembly is specified as GRCh38 for human, and spans should be kept modest. It does not contradict the annotations and gives the agent practical knowledge about response 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?

The description is compact and front-loaded: the first sentence states purpose and payload, the second gives a concrete use case, and the third provides operational guidance and sibling routing. Every sentence earns its place with zero repetition of schema content.

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

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

For a 4-parameter read-only tool with no output schema, the description covers what is returned, how output is truncated, which assembly is used, and when to choose alternatives. It does not describe the exact response format, but the field-level detail (stable IDs, rsIDs, consequence terms) plus the truncation note make the tool sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, so the structured schema already documents all parameters. The description adds contextual nuance (assembly, span caution, output cap) that enriches the region parameter semantics, but does not materially expand on limit, species, or features beyond what the schema provides. This matches the baseline-3 expectation for fully covered schemas.

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

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

The description opens with a specific verb and resource ('Query what lives in a genomic interval') and enumerates exact content: genes/transcripts with stable IDs, symbols, biotypes, and variants with rsIDs, alleles, consequence terms, and clinical significance. It also explicitly distinguishes itself from siblings like genbank_get and gene_get/variant_get, making its 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?

Provides a clear use case ('Ideal for locus triage — what genes and known variants sit in this GWAS hit interval?'), a recommendation ('Keep spans modest (<1 Mb recommended)'), and explicit routing to alternatives ('For sequence text use genbank_get; for entity-level annotation chain IDs into gene_get / variant_get').

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 and openWorldHint=true, covering safety. The description adds valuable behavioral detail: it uses the elink nuccore→gene mechanism and returns entrezgene IDs that are directly compatible with MyGene-backed tools. This goes beyond just saying 'maps an accession.'

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, with the core mapping stated first and supporting detail (returned ID type, downstream compatibility) second. No wasted words or redundant restatement of the tool name.

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

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

For a single-parameter read-only lookup with no output schema, the description covers the essential points: what input is expected, how the mapping happens, what the output is (gene IDs), and how those IDs can be used. Minor gaps like zero/multiple hit behavior and exact response shape are not disclosed, but the description is complete enough for correct invocation.

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

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

Schema coverage is 100% and the parameter description already includes examples ('NG_017013.2, NC_000023.11') and versioning detail. The description repeats the GenBank/RefSeq context but doesn't add meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Map a GenBank/RefSeq nucleotide accession to its NCBI Gene IDs.' This clearly distinguishes it from sibling tools like genbank_search/genbank_get (which retrieve sequence records) and gene_search (which searches for genes by other criteria).

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 'Useful bridge from a sequence record to gene-level annotation' gives clear context for when to use this tool. It does not explicitly state alternatives or when not to use it, but the mapping purpose is distinctive enough that an agent can infer the appropriate 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?

The annotations provide readOnlyHint and openWorldHint, and the description adds substantial operational detail beyond those: the 2,000,000 bp cap, 10 Mb region span, reverse-strand semantics, region echo behavior, NCBI complement notation, 200,000-character truncation, and the max_response_bytes error behavior. There is no contradiction with the read-only annotation.

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 first sentence gives a crisp purpose statement, and the second paragraph packs multiple complex rules into compact prose with no filler. Every sentence contributes to correct invocation, and the most important scope-limiting facts appear early.

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

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

The description covers every edge case that could cause a failed or misleading call: record-size caps, region span limits, strand semantics, truncation behavior, and the max_response_bytes hard cap. Since there is no output schema, the description's detail about the returned text and its truncation behavior is especially valuable for an agent deciding whether a request will succeed.

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

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

The schema covers all six parameters with 100% description coverage, and the description goes well beyond it by explaining 1-based inclusive coordinates, the cap that makes seq_start/seq_stop required, the strand=2 reverse-slice usage, and the truncation guard that motivates max_response_bytes. This transforms the parameter names into actionable invocation knowledge.

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, 'Fetch a GenBank/RefSeq nucleotide record as text (GenBank flat file or FASTA)', names a specific verb, a precise resource, and the output formats. This clearly distinguishes genbank_get from genbank_search, which is about discovery, and from genbank_genes, which targets gene records rather than nucleotide records.

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

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

The description gives detailed operational conditions: whole-record fetches are capped at 2,000,000 bp, larger records require seq_start/seq_stop, and strand=2 is needed for reverse-strand slices. However, it does not explicitly state when to choose this tool over alternatives such as genbank_search, gene_get, or ensembl_region; that guidance is implied by the tool name rather than stated.

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

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

The annotations already declare the operation as read-only and open-world, so the safety profile is covered. The description adds useful behavioral context beyond that: it supports multiple query formats and enumerates the result fields (accession.version, definition, length_bp, organism, topology). This is especially valuable because there is no 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 compact and well-structured. The first sentence states the core purpose, the second provides query guidance and result details, and the final clause gives actionable chaining advice. 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?

The description is complete enough for an agent to invoke the tool correctly. There is no output schema, but the description compensates by listing the returned fields. It also explains accepted query forms and suggests downstream uses, so the agent knows what to do with the results.

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 100% parameter descriptions, so the baseline is 3. The description adds concrete query syntax examples and mentions result fields, but it does not add meaning to specific parameters beyond what the schema already states.

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

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

The description identifies a specific verb ('Search'), a specific resource (NCBI nucleotide records, explicitly GenBank/RefSeq/INSDC), and clearly distinguishes it from related tools by naming the nucleotide database. It also differentiates itself from sibling searches like gene_search and variant_search by stating its domain.

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 tells the agent which query forms are accepted, including plain terms, accessions, and NCBI field syntax, with concrete examples. It also gives guidance on next steps by chaining accessions into genbank_get or genbank_genes, but it does not explicitly state when not to use this tool or name alternatives for exclusion.

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

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

Annotations already declare readOnlyHint=true, so description does not need to restate. It adds no additional behavioral context beyond the 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?

Extremely concise at 4 words. Front-loaded and to the point, though it could be slightly more descriptive without losing efficiency.

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

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

Given the simplicity of the tool (single required parameter, read-only annotation), the description is adequate but does not mention the nature of the output (e.g., list of article IDs or abstracts).

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

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

Schema coverage is 100% (one parameter with description). The description 'about a gene' aligns with the 'symbol' parameter but adds no extra meaning beyond the schema.

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

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

Description clearly states verb 'Find' and resource 'articles about a gene', distinguishing it from general article or gene tools. However, it does not specify that it returns a list or any additional details.

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

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

No guidance on when to use this tool versus siblings like article_search, article_get, or gene_get. The description is too brief to indicate its specific niche.

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 adds behavioral context beyond annotations: it requires an environment variable and has a data source fallback. Annotations already indicate readOnly and openWorld, and the description does not contradict 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?

Two precise sentences with no wasted words. First sentence states purpose, second provides crucial configuration info.

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

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

The description covers the main functionality and a key dependency (env var). However, it does not describe the return format or structure, which could be helpful given no output schema.

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

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

Schema coverage is 50% (symbol described, limit not). The description adds no new parameter information beyond what's in the schema, such as the limit parameter's purpose or default behavior.

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 retrieves diseases associated with a gene, using the verb 'Get' and resource 'diseases'. It distinguishes from sibling tools like gene_articles, gene_drugs, etc., by specifying the output type.

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 usage context by mentioning the DISGENET_API_KEY requirement and fallback to OpenTargets. However, it does not explicitly contrast with sibling tools for when to use this tool instead of others.

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, and the description ('Find') is consistent but does not add further behavioral details such as potential limits, data source, or any side effects. The description carries little additional transparency beyond the annotation.

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

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

A single sentence with no unnecessary words, directly conveying the tool's purpose. Highly concise and 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 simple one-parameter tool with annotations, the description is minimal but sufficient. However, it lacks information about output format or limitations, which would be helpful for completeness. Score reflects adequate but not exceptional coverage.

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

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

Schema description coverage is 100% for the single parameter 'symbol', which already includes examples. The description adds no extra meaning beyond what the schema provides, so baseline score 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?

Description clearly states 'Find drugs targeting a gene' which is a specific verb-resource combination. It distinguishes from sibling tools like 'drug_search' (general drug search) and 'disease_drugs' (drugs for a disease) by specifying the relation to a gene.

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 explicit guidance on when to use this tool versus alternatives such as 'disease_drugs' or 'drug_search'. The description does not provide context for when not to use it or mention any conditions 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?

The annotations already declare readOnlyHint=true, indicating a read operation. The description adds little beyond stating the analysis nature. It does not disclose computational behavior, dependencies, or output specifics, but with annotations covering the safety profile, the description is adequate but not enriched.

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

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

The description is a single, concise sentence that immediately communicates the tool's function. There is no extraneous information, and it is front-loaded with the action and target.

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 only one parameter and annotations present, the description is minimal. It lacks details about the output or return format, which is important since there is no output schema. For a complex analysis tool, additional context about the analysis method or result type would improve completeness.

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

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

Schema coverage is 100% for the single parameter, with a clear description ('List of HGNC gene symbols'). The tool description does not add further details about parameter constraints, formatting, or validation rules, so it scores at the baseline.

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

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

The description clearly identifies the action ('perform pathway enrichment analysis') and the resource ('a gene list'). This is distinct from sibling tools that retrieve or search for individual gene-related data, making the purpose specific and 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 states what the tool does but does not provide explicit guidance on when to use it versus alternatives or when not to use it. It implies enrichment analysis as opposed to simple gene lookup, but lacks explicit context or exclusions.

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

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

Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true (variable results). Description adds no additional behavioral context such as error handling, rate limits, or data scope beyond 'detailed', offering minimal extra transparency.

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?

Five-word sentence is extremely concise but includes the core action and resource. Could elaborate slightly without losing efficiency, but overall well-structured.

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

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

Given 4 parameters, no output schema, and complexity of gene data, the minimal description fails to convey the scope of information returned (e.g., sections, smart resolution) or any usage nuances. Incomplete for effective tool selection.

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

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

Schema description coverage is high (75%), but description provides zero additional parameter-level explanation. It does not compensate for 'limit' lacking schema description, and adds no semantics beyond the symbol parameter documented in 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 clearly states verb 'Get' and resource 'detailed gene information by symbol', distinguishing it from sibling tools like gene_search or gene_articles which serve different retrieval purposes.

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

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

No guidance on when to use this tool vs. alternatives (e.g., gene_search for partial matches, gene_articles for literature). No when-not or context provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description's search semantics are consistent with those. The description adds no additional behavioral context such as result ordering, pagination behavior, or match semantics, but it does not contradict the annotated safety profile.

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

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

The description is a single concise sentence with no unnecessary words. The core action and input types are front-loaded, making it easy for an agent to parse quickly.

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?

This is a simple read-only search tool with four parameters, all fully documented in the schema and no output schema. The description gives enough context for a basic call; the only minor gap is the absence of any note about return format or behavior when no matches are found.

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

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

Schema description coverage is 100%, so every parameter (query, limit, offset, chromosome) is already documented in the schema. The description mainly restates the query parameter's purpose and adds no new semantic detail beyond the schema.

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

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

The description uses the specific verb 'Search' with the resource 'genes' and specifies the query types: symbol, name, or keyword. It clearly communicates the tool's role and is distinct from gene_get in intent, though it does not explicitly differentiate from sibling search 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?

The description implies the tool should be used when searching for genes by symbol, name, or keyword, but it provides no explicit guidance on when to prefer it over gene_get or other sibling search tools. No alternatives or exclusions are mentioned.

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, indicating a safe operation. The description adds no further behavioral details (e.g., what is returned or limitations), but it does not contradict the annotations.

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

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

A single, concise sentence that is front-loaded and immediately conveys the tool's purpose. It is appropriately sized for a simple 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?

Given the low complexity (one parameter, no output schema), the description adequately explains what the tool does. It could mention that it uses HGNC symbols for searching, but the schema already clarifies that.

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

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

The input schema has 100% coverage for the single parameter 'symbol' with a description. The tool description adds no additional meaning beyond what the 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?

The description 'Find clinical trials for a gene' uses a specific verb ('Find') and resource ('clinical trials'), clearly distinguishing it from sibling tools like gene_articles or gene_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?

No guidance is provided on when to use this tool versus alternatives such as disease_trials or drug_trials, nor are there any prerequisites or disclaimers.

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 discloses the main non-read-only behavior outside the annotations: download=true saves the first supplementary file to a local temp path and returns path/size/source URL, capped by max_bytes. This goes beyond readOnlyHint=false and openWorldHint=true, and it is consistent with 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 organized with a front-loaded core purpose, a compact enumeration of series-level return fields, and a separate sentence for the opt-in download behavior. Every sentence contributes either scope, chaining context, or side-effect disclosure, with no filler.

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

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

With no output schema, the description adequately covers return contents for series lookups and the download path, and it explains the tool's role in chaining across siblings. It is slightly less complete for sample/platform return shapes, but the 'full SOFT record details' framing plus the series example gives sufficient context for an agent to invoke it correctly.

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

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

The schema already fully describes all three parameters, so this is at baseline 3. The description adds value by clarifying accepted accession patterns, download file extensions (.gz/.csv/.txt), and the non-boolean effect of download, which strengthens the parameter story.

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

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

The description opens with a specific verb and resource: 'Get the full SOFT record details for a GEO entry', and enumerates the accession types (GSE/GSM/GPL). It clearly distinguishes this lookup tool from search-oriented siblings like geo_search by emphasizing full record details and chaining cross-references.

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 rather than explicit: the description explains what series/sample/platform lookups return and shows chaining paths (sra_get, article_get, geo_get), but it never states when to prefer geo_get over geo_search, batch_get, or other GET tools. A clear when-to-use statement is missing.

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

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

With readOnlyHint and openWorldHint annotations already covering safety and non-exhaustiveness, the description adds useful behavioral detail: accepted query syntax (plain terms vs NCBI field syntax) and that each result carries cross-links for chaining to sra_get, article_get, and geo_get. 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?

Three compact sentences convey purpose, query syntax, and result chaining. The description is front-loaded with the core action and contains no filler or redundant restatement of the schema.

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

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

For a search tool with no output schema, the description covers scope, accepted query forms, and result linkage, while the input schema fully documents all parameters. It could go one step further by describing the shape of individual search results, but the cross-link details and schema coverage make it complete enough for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra semantics for the query parameter by showing that it accepts both plain language and structured NCBI fields, with concrete examples like 'GSE183947[Accession]'.

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

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

The description opens with a specific verb-resource-object construction: 'Search NCBI GEO ... for functional genomics studies'. It lists concrete content types and query examples, and differentiates itself from geo_get by noting 'accession → geo_get for full details'.

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

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

The description gives clear context: use this tool to search GEO by terms or NCBI field syntax, then chain to related tools via cross-links. It names geo_get as the follow-up for full details, but does not explicitly exclude overlapping search siblings such as sra_search or genbank_search.

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

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

Annotations already establish readOnly and openWorld intent. The description adds meaningful behavior: exact output fields, p-value sort order, GTEx v10 data source, and the required tissue constraint. This goes well beyond annotations, though it does not discuss pagination or significance threshold semantics.

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

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

Two compact sentences with no filler. The core action, output shape, and sort order are front-loaded; the required parameter note is placed at the end. 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?

For a modest list-style query with a well-documented schema and read-only annotations, the description fully supports correct invocation: what the tool returns, how results are sorted, what the required tissue value should look like, and what gene identifiers are acceptable. No critical gap remains.

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 covers all three parameters with clear descriptions and a required array. The description reinforces tissue formatting with examples, but does not materially extend parameter meaning beyond what the schema already provides. Baseline 3 applies.

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

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

States a specific verb ('Get'), a specific resource ('significant cis-eQTL associations for a gene in a specific GTEx tissue'), and useful operational details (output fields, sorting order, data version). This clearly distinguishes it from sibling tools such as gtex_expression or gene-level lookups.

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 clear context for use: it is for cis-eQTL associations in a specified GTEx tissue. It explicitly notes that tissue uses a tissueSiteDetailId and gives examples. It does not explicitly name alternatives or when-not-to-use conditions, so it misses the top bar.

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, so safety is covered. The description adds meaningful behavioral detail beyond annotations: GTEx Analysis v10, 54 tissue sites, TPM units, highest-first sorting, accepted identifier formats, and tissue filter semantics. This provides useful expectations without contradicting 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 two short, front-loaded paragraphs: the first states the core function and key details, the second explains accepted inputs and optional filtering. Every sentence adds information, with no filler or 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?

For a simple read-only lookup tool with full schema coverage and clear annotations, the description covers the essential context: data source, units, sort order, identifier acceptance, and filtering. There is no output schema, but the first sentence implies the return shape (per-tissue median expression sorted high to low), which is sufficient for this tool.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description reinforces the meaning of gene and tissue with examples but does not add substantial new semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Get median gene expression across GTEx tissues', further specifying version, tissue count, units, and sort order. This clearly distinguishes it from sibling tools like gtex_eqtl and the gene_* family, which cover different biological 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?

The description gives clear usage context: accept an HGNC symbol or Ensembl gene ID, optionally filter by tissue, and return a limited number of top-expressing tissues. It does not explicitly name alternatives or state when not to use the tool, but the context is specific enough for an agent to select it appropriately.

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 mark the tool read-only and open-world; the description adds useful behavioral details: it enumerates available sections, notes that US fulltext comes via USPTO Public Search while EP/WO uses EPO OPS, and specifies that citations include backward and forward directions. This goes beyond the schema without contradicting the read-only and open-world hints.

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

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

The description is a single information-dense sentence that front-loads the primary action and identifier format, then efficiently lists section semantics. There is no fluff or repetition of schema details.

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

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

For a read-only detail lookup with three simple parameters, the description covers the essential input format, available sections, and source caveats. The schema handles defaults and limits, so nothing an agent needs to call the tool 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 coverage is 100%, so the baseline is 3, but the description adds value by giving realistic patent_id examples and clarifying the content and source of each section. For instance, the claim-source caveat and citation directionality are not in the schema descriptions.

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

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

The description opens with a specific verb and resource: 'Get patent details by publication number,' and includes concrete accepted formats for the identifier. The listed sections (abstract, claims, citations, family, classifications) make it unmistakable that this is a fetch-by-ID tool rather than a search tool like patent_search.

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 'by publication number' sets a clear prerequisite: use this tool when you already have a patent publication number and need its details. It does not explicitly name alternatives such as patent_search for query-based lookup, but the usage context is clear and no 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses auth requirements (EPO_OPS_CONSUMER_KEY/SECRET, USPTO_API_KEY), backend reliability (google_patents 'often unavailable'), concurrency and failure behavior (auto mode queries worldwide + ppubs concurrently, falls back to uspto_odp once tagged with _note), and latency cost (~5-30s for seminal). It also reveals ranking defaults and that sort_by only affects ppubs. This is exactly the operational context an agent cannot 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 densely informative with the core purpose front-loaded and zero filler sentences — every clause carries operational substance. However, the four backend profiles are crammed into a single pipe-separated run-on that is harder to scan than a structured list would be, and the auto-mode/fallback behavior is buried mid-paragraph rather than given its own 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?

For a tool with 11 parameters, four backends, a fallback contract, and a co-citation feature, the description covers nearly every invocation-relevant behavior. The one gap is the shape of the returned result entries, which matters more because no output schema exists; mentioning seminal_prior_art and the _note tag partially compensates by naming the non-obvious return fields. Overall this is complete enough for an agent to call and interpret the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: what each source enum value actually does (coverage scope, credential needs, availability), why quoting matters for the query param, and how the seminal flag produces seminal_prior_art via co-citation mining. It correctly notes that sort_by affects only the ppubs backend, reinforcing the schema. It doesn't walk all 11 params, but with full schema coverage it doesn't need to.

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 states a specific verb and resource with explicit scope: 'Search patents worldwide (US, EP, WO, JP, and 100+ authorities).' The detailed backend breakdown (ppubs, ops, uspto_odp, google_patents) reinforces that this is a broad multi-source search facility, clearly distinct from patent_get and the other domain-specific search siblings. Nothing about the tool's purpose is left vague or implied.

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

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

The description gives explicit conditions for backend selection: ppubs is keyless and the default US backend, ops requires EPO_OPS credentials, uspto_odp requires USPTO_API_KEY, and google_patents is 'often unavailable' — plus the auto-mode fallback rule. It also prescribes how to form queries ('Quote exact multi-word concepts... to avoid off-topic matches'). However, it never explicitly routes to sibling tools such as patent_get for ID-based retrieval, so exclusions are inferable rather than stated.

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

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

Annotations convey openWorldHint=true and readOnlyHint=false, and the description adds context about the download side effect (saving a file to disk). This clarifies behavioral traits beyond the structured annotations. No contradictions.

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, using three short sentences to convey three modes of operation. It is front-loaded with the tool's purpose and uses line breaks for readability. No superfluous 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?

Given the tool has 7 parameters and no output schema, the description partially compensates by explaining parameter usage for each mode. However, it does not specify the return format for search and get results (e.g., what data structure is returned) or error handling. This leaves some ambiguity for an AI 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?

Input schema has 100% description coverage, so baseline is 3. The description adds significant value by grouping parameters into modes (SEARCH, GET, DOWNLOAD) and explaining inter-parameter dependencies (e.g., download only used with pdb_id). This enhances understanding beyond individual parameter descriptions.

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

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

The description clearly states it accesses the Protein Data Bank for macromolecular structure data and enumerates three distinct operations (SEARCH, GET, DOWNLOAD) with specific verbs and resources. It distinguishes itself from siblings which focus on other data types like articles, diseases, etc.

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

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

The description provides explicit mapping of parameters to operations: query for searching, pdb_id for get/download, and download=true for saving files. It explains when to omit parameters. However, it does not explicitly state when not to use this tool or alternative tools, though the sibling context makes it implicit.

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 adds value beyond the readOnlyHint/openWorldHint annotations by specifying what details are returned per accession type and that ERP/ERR/DRP/DRR are not indexed. It does not describe the response envelope or pagination, but for a read-only retrieval with this detail level the disclosure is strong.

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 carry all essential information, with the primary action and scope front-loaded before chain/alternative guidance. No filler or redundant restatement.

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

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

For a one-parameter read-only tool without an output schema, the description covers what can be retrieved, accepted formats, upstream callers, and unsupported accessions. An agent has everything needed to decide whether and how to invoke it.

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

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

The schema already documents the single parameter at 100% coverage, so the baseline is 3. The description adds accepted prefix list (SRP/SRX/SRR/SRS) and a concrete example (SRR14432476), giving the agent format guidance 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 ('Get full details') and a precise resource ('NCBI SRA accession'), then enumerates the four accession types and the fields returned for each. This clearly separates it from sibling sra_search, which finds accessions rather than retrieving details.

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

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

Explicitly names upstream tools (geo_get, sra_search) and the fields to chain from, and explicitly excludes European/DDBJ accessions with a pointer to ENA. This gives an agent both the workflow and the when-not-to-use condition, meeting the 5-level bar.

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 and openWorldHint=true, covering the safety profile. The description adds behavioral value by disclosing the accepted input forms (accessions, field syntax), the returned fields, and the presense of first_run_accession for chaining. This goes beyond the annotation-only picture and gives the agent a realistic expecation of the response.

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 has two focused sentences: one front-loaded purpose statement and one detailed-but-compact explanation of query forms and output fields. No fluff or repition. Every sentence serves a distinct purpose.

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 search tool with no output schema, the description covers accepted query syntax, accession types, and the result field list, which is sufficient for invoking and interpreting results. It could add explicit pagination notes or caveats about open-world searhes, but those are partly conveyed by annotations and the parameter schema. Minor gap, not a blocker.

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

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

Schema description coverage is 100%, so the schema already defines query, limit, and offset with descriptions, defaults, and constraints. The tool description retsates much of the query semantics and adds one example, but does not meaningfully extend parameter understanding beyond the schema. This is the baseline-3 case where schema carries the load.

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

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

The description opens with a specific verb and resource: 'Search NCBI's Sequence Read Archive (SRA) for sequencing experiments and runs.' It clearly differentiates this search tool from its sibling sra_get by noting the results are meant for chaining into sra_get. The scope is precise and the tool's role is unmistakable.

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

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

The description gives concrete context on when to use the tool: any query that is free text, an accession, or NCBI field syntax. It also names the downstream tool (sra_get) for chaining, implying when a more specific retrieval is needed. It lacks explicit exclusions or 'use X instead' wording, but the context is clear enough for an agent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and variability. The description adds 'detailed trial information' but does not elaborate on response structure, pagination, or potential errors. With annotations providing the core behavioral disclosure, the description offers minimal extra value.

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

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

The description is a single sentence, immediate, and wastes no words. However, it could be slightly expanded to include more context without losing conciseness.

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

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

Given there is no output schema, the description could explain what 'detailed information' entails (e.g., sections, fields returned). The description is minimal and leaves the agent to infer the response structure from the 'sections' parameter. This is adequate but not comprehensive.

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 provide any additional meaning beyond the input schema. While the schema covers 67% of parameters with descriptions, the 'limit' parameter lacks a schema description and the tool description does not compensate. No parameter details are elaborated.

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 verb 'Get', the resource 'trial information', and the required identifier 'by NCT ID'. It effectively distinguishes this tool from sibling tools like 'trial_search' which would be used for searching without a known ID.

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 an NCT ID is known, but does not explicitly state when to use this tool versus alternatives like 'trial_search' or other get tools. There is no mention of prerequisites or when not to use it.

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

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

Annotations already indicate read-only and open-world hints. The description does not add behavioral context 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?

Single sentence, no unnecessary words, efficiently conveys the core purpose.

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 output schema is provided, and the description omits information about return values, pagination behavior, or result format. For a search tool with many siblings, more context is needed.

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

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

The input schema has 100% coverage with detailed descriptions for all parameters. The tool description does not add semantic value 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?

The description clearly states the tool searches clinical trials by condition, intervention, or keyword. It is straightforward but does not differentiate from sibling tools like disease_trials or drug_trials.

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 like disease_trials or gene_trials. No exclusions or context are 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations by explaining that core data is always returned at the top level and that sections request additional data, helping the agent anticipate response structure even without an 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 two sentences, front-loads the core action, and wastes no words. The key facts—core data always returned and sections optional—are presented efficiently in the very 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?

The tool has no output schema, so the description bears responsibility for explaining return behavior; it does so partially by mentioning top-level core fields and optional sections. However, it omits limit semantics, section-level output detail, and route selection among siblings, leaving meaningful gaps for an agent deciding how to call the tool and interpret results.

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 67%, with id and sections already documented in the schema. The description mentions 'sections' generically and names core response fields, but it does not clarify the semantics of the limit parameter, whose role remains ambiguous despite having defaults and bounds. Thus the description provides only partial value 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?

The description uses a specific verb ('Get') and resource ('detailed variant information'), and it clarifies that core fields are always returned while sections are optional. This distinguishes it from search-like siblings but does not explicitly contrast it with variant_oncokb or variant_trials, so it falls short of full 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 explains that sections are optional and that core data is always returned, but it provides no guidance on when to use this tool versus alternatives like variant_search or variant_oncokb. There is no explicit when-to-use, when-not-to-use, or alternative routing, which leaves the agent to infer 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the token requirement, which is useful but does not reveal other behavioral details (e.g., rate limits, error handling, return format).

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 two short sentences: the purpose and a single prerequisite. No superfluous text, and the purpose 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?

The tool has no output schema, so the description could have explained return values (e.g., mutation effect, drug associations). It is adequate for a simple lookup but leaves some gaps.

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

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

Schema coverage is 100% with clear descriptions for both parameters ('Gene symbol' and 'Protein change'). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the action ('Get') and resource ('OncoKB annotations for a variant in a cancer gene'). It distinguishes itself from sibling tools like variant_get and variant_search by specifying 'OncoKB annotations' rather than general variant info.

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 mentions the 'ONCOKB_TOKEN' prerequisite but provides no guidance on when to use this tool versus alternatives like variant_get or variant_search. No explicit when-to-use or when-not-to-use context 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?

Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds behavior beyond annotations by explaining correct query patterns and discouraging compound queries. No contradictions, but does not elaborate on response format or pagination.

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?

Concise single paragraph with bullet-like structure. Efficiently conveys purpose, examples, and warnings. No extraneous information; 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?

Given 11 optional parameters and no output schema, the description covers main search types and warnings. It could mention pagination (limit/offset) or result format, but those are in schema. Sufficient for a search tool.

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

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

Schema coverage is 91% with descriptions, but the description adds significant value by providing concrete examples (e.g., 'query="NM_004333.4:c.1799T>A"'), showing how to combine gene and hgvsp, and emphasizing the prohibition of compound free-text.

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

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

The description clearly states 'Search for variants' and provides specific examples of valid queries (rsid, HGVS, gene filter, ClinVar significance). It differentiates from sibling tools like variant_get by focusing on search with structured parameters.

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?

Explicit guidelines on when to use structured parameters vs. compound free-text, with examples and a direct warning against using 'BRAF V600E' as free-text. Provides clear context for proper usage.

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

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

Annotations provide readOnlyHint=true, so the description adds minimal value by confirming a read operation. No additional behavioral details like pagination, result format, or scope are given.

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

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

The description is a single short sentence, which is concise. However, it lacks sufficient detail to be highly effective, slightly lowering the score.

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?

Despite low complexity and good annotations, the description does not indicate what the tool returns (e.g., list of trials). With no output schema, this is a significant gap.

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

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

Schema description coverage is 100%, with clear parameter description 'Variant ID (rsID, HGVS, or variant ID)'. The tool description adds no new meaning beyond the schema, meeting baseline expectations.

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 verb 'find' and the resource 'clinical trials for a variant', which is specific and distinct from sibling tools like trial_search or variant_get.

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

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

No guidance on when to use this tool versus alternatives such as trial_search or variant_get. The description leaves the agent without context for selection among many siblings.

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