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

Annotations already declare a non-read-only, open-world, non-destructive mutation. The description adds the useful 'running' state constraint, but omits auth needs, reversibility, side effects, and what cancellation does to the underlying transfer.

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 short lines with the core purpose front-loaded and no wasted prose. The second line, 'Available for: default', is vague and does not clearly earn its place.

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

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

The tool is simple, annotations cover its safety profile, and an output schema exists, so the description need not explain return values. Still, it omits usage guidance and any transfer_id semantics, leaving the agent to infer key calling details.

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

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

Schema description coverage is 0% and the single required transfer_id has no schema description. The description adds no format, source, or qualifier for transfer_id, so it does not compensate for the gap, though the param name is fairly self-explanatory.

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 ('Cancel') and resource ('transfer') with the state constraint 'running'. It does not explicitly differentiate from siblings such as get_transfer_status, though no sibling performs cancellation, so it is clear but not fully sibling-routing.

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

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

Provides no when-to-use guidance, prerequisites, or alternatives. 'Available for: default' is cryptic and does not explain when an agent should choose cancellation versus checking transfer status first.

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 no behavioral details beyond the comparison action, such as whether computation is local or remote, permission requirements, or how samples and files interact.

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 short and front-loaded with the core action. The trailing 'Available for: default.' is cryptic and does not clearly earn its place, slightly reducing the otherwise efficient structure.

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

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

For a complex five-parameter tool with an output schema, the description is too sparse. It omits prerequisites, the relationship between the required files array and optional samples, what exactly is compared, and when to prefer this tool over siblings like get_coverage or get_variants.

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

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

Schema description coverage is only 20%, so the description must compensate. It maps the interval, files, and samples inputs, but leaves reference and max_records unexplained and does not clarify what the sample strings represent or how samples relate to the required files array.

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 (Compare) and resource (genotypes/coverage at an interval across files or samples), making the core action clear. However, it does not distinguish the tool from close siblings like get_coverage, get_variants, or get_pileup, so the agent lacks explicit 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 offers no guidance on when to use this tool versus alternatives such as get_coverage or get_variants. The trailing phrase 'Available for: default' does not provide actionable 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, so the safety and network profile is covered. The description's 'with linked entities' adds useful scope about what the read returns. It does not mention auth requirements, source-specific rate limits, or resolution failures for invalid accessions, so it stays at an adequate 3.

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 short sentences with the purpose front-loaded and the source constraint immediately after. Nothing is wasted and nothing is buried.

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

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

An output schema exists, so return-value shape needn't be described, and annotations cover read-only/open-world behavior. The source enumeration compensates for the missing schema descriptions. The main residual gap is accession format guidance, which is minor for a two-parameter read tool.

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

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

Schema description coverage is 0%, so the description must carry the semantics. It partially does: it enumerates the valid source values (ega, ena, encode, geo, ncbi_datasets) and clarifies that accession must be a 'native' accession. It says nothing about accepted accession formats or cross-source ID distinctions, so compensation is incomplete.

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?

Clear verb+resource: 'Describe a study/dataset by native accession, with linked entities.' The source list scopes what data it applies to, which helps separate it from search_datasets. However, it never explicitly contrasts itself with that sibling, so an agent must infer the difference between describing one dataset and searching many.

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 'Available for: ega, ena, encode, geo, ncbi_datasets' line acts as an applicability constraint, implying usage is limited to those sources. But there is no explicit when-to-use statement and no mention of search_datasets or resolve_identifier as alternatives for other cases, leaving routing 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely new behavioral context: the download is bounded, it also grabs the index, it is asynchronous (returns a transfer job), and the size limit requires budget_bytes. It omits failure/retry semantics and whether re-issuing is idempotent, so not a 5.

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

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

Two efficient, front-loaded sentences with no filler; the core action and return type come first. The trailing 'Available for: default' is cryptic and slightly dilutes the otherwise tight structure.

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

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

An output schema exists, so return-value detail is appropriately omitted and 'Returns a transfer job' suffices. However, for a 5-parameter mutation/transfer tool with 0% schema description coverage, the description should at least clarify prepare and verify_checksum, which it does not.

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?

Top-level schema description coverage is 0%, so the description must compensate. It adds meaning for budget_bytes (the size-limit override) and include_index (the '(and index)' clause), but leaves prepare and verify_checksum entirely unexplained in both schema and description.

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

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

States a specific verb+resource ('Start a bounded download of a file (and index) to the local work dir') and the return shape ('Returns a transfer job'). It is distinguishable from siblings like get_transfer_status and cancel_transfer, though it never names them or any alternative explicitly.

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

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

Implies usage (download a file locally, e.g. before read-level tools that require local data) but never states when to use this vs. the sibling access tools. The only concrete guidance is the conditional 'files above the default limit need budget_bytes', and 'Available for: default' is opaque.

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, so the safety profile is covered. The description adds real behavioral value by disclosing the default filtering (excludes UNMAP, SECONDARY, QCFAIL, DUP), which explains the opaque exclude_flags=1796 default in the schema. It does not mention failure modes (e.g. index_required) or output shape.

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

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

Two tight sentences, front-loading the operation and its scope, with the format constraint appended. No filler, though the samtools reference could have been used to clarify sibling choice instead.

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

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

An output schema exists so return values needn't be explained, and annotations cover the read-only safety profile. However, for an 8-parameter tool with 13% schema coverage, the description is thin on optional parameters and locus-readiness requirements.

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

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

Schema description coverage is only 13% across 8 parameters. The description accounts for the default exclude_flags behavior but says nothing about bin_size, min_base_quality, min_mapping_quality, max_records, or reference, leaving most parameters undocumented in both places.

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

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

States a specific verb+resource+scope (read depth over an interval from indexed BAM/CRAM) and anchors it with a familiar analogue ('like samtools depth'). It does not differentiate itself from close siblings like get_pileup, get_reads, or get_signal, which an agent would need to choose among.

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?

'Available for: bam, cram' gives a format constraint, so usage is implied rather than spelled out. There is no explicit when-to-use vs get_pileup/get_reads, and no mention of index prerequisites beyond the word 'indexed'.

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 useful nuance that the source must be 'indexed' and enumerates supported formats, but says nothing about what happens when the index is missing, whether results are truncated, or how large result sets are limited.

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 short sentences with no filler, and the core operation is front-loaded before the format list. It is efficient, though terse to the point of under-specification for a tool with four parameters.

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

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

An output schema exists, so return values needn't be described, but for a four-parameter genomic tool with a nested FileRef and an Interval requiring an explicit assembly, the description leaves the two optional parameters, result limiting, and index/assembly prerequisites unaddressed.

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

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

Schema description coverage is only 25% across 4 parameters. The description clarifies the interval/file-format dimension, but 'max_records' and 'feature_types' are completely undocumented in both the schema and the description, so the description does not compensate for the coverage 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 verb+resource ('Features overlapping an interval') and the file formats it applies to (BED/GFF3/GTF/bigBed), so an agent can tell what it returns. It does not distinguish itself from siblings like get_variants, get_signal, or get_coverage, which also read interval-scoped data, so it stops short of a 5.

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

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

The 'Available for: bed, bigbed, gff3, gtf' clause implicitly tells the agent the tool only applies to those formats, which is useful routing guidance. However, it never names the alternative tools for other formats or data types, nor states prerequisites (e.g. index required) beyond the word 'indexed'.

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, so safety is covered. The description adds a real behavioral constraint (requires indexed BAM/CRAM) and the output nature, but says nothing about auth, rate limits, or what happens with low-quality/flagged reads.

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, no filler, with the core output statement front-loaded before the format constraint. 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 an 8-parameter tool with very low schema coverage and no output-schema gap, the description is too sparse: it provides no usage routing and no parameter semantics, leaving an agent under-equipped to call it correctly versus siblings like get_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 only 13% across 8 parameters, so the description should compensate heavily. It mentions only 'interval' and implicitly the file, leaving max_depth, exclude_flags, min_base_quality, min_mapping_quality, max_records, and reference entirely unexplained beyond their bare schema defaults.

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 the output precisely: per-position base counts over an interval, restricted to BAM/CRAM. This distinguishes it from coverage-depth or read-listing tools, but it never names a sibling such as get_coverage or get_reads, leaving the agent to infer the boundary.

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

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

The only guidance is a format restriction ('Available for: bam, cram'). There is no explicit when-to-use, when-not-to-use, or routing to alternatives like get_reads or get_coverage, which share the same locus/interval domain.

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 usefully adds that CRAM requires a matching reference unless self-contained and that flag filters mirror samtools -f/-F, but says nothing about record limits, error behavior, or paging.

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

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

Three tight sentences, front-loaded with the core operation before the format constraint and the CRAM caveat. No filler, though the samtools flag note could be folded into the flag parameters rather than the top-level description.

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

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

For an 8-parameter, read-only tool with an output schema, the description covers the operation, applicability, and the key CRAM prerequisite. Given the very low schema coverage it still leaves several parameters and any limit/error semantics unexplained, so it is adequate but not complete.

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

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

Schema description coverage is only 13%, so the description must carry weight: it does explain the flag semantics (mapping to exclude_flags/require_flags) and the reference requirement. But max_records, include_sequence, and min_mapping_quality get no mention, leaving part of the parameter set undocumented.

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?

Specifies the verb+resource ('alignments overlapping an interval') and the applicable formats ('indexed BAM/CRAM'), which cleanly distinguishes it from get_sequence, get_features, and get_pileup. It never names a sibling explicitly, so it stops just short of a 5.

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

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

'Available for: bam, cram' states applicability by file type, and the CRAM reference caveat is a genuine prerequisite. However, there is no guidance on when to choose this over get_pileup, get_coverage, or get_variants, leaving alternatives 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=true and openWorldHint=true, so safety and external reach are covered. The phrase 'exactly as supplied by the source' adds meaningful fidelity context (no normalization/reinterpretation), but no auth, rate-limit, or failure behavior is disclosed.

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: the purpose leads and the applicability constraint follows. No filler, no redundancy with 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?

The output schema exists, so return values need no explanation, and the source enumeration helps. However, for a two-required-parameter tool with zero schema descriptions, leaving 'accession' entirely unspecified is a real gap.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by enumerating accepted 'source' values, but the required 'accession' parameter is left completely undefined (format, identifier namespace, whether it must match the source).

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

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

States a specific verb and resource ('Get one sample's metadata and phenotype values'), scoped to a single sample, which implicitly separates it from list_samples and compare_samples. It stops short of naming any sibling explicitly, so the differentiation is inferable rather than stated.

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

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

The 'Available for: ega, ena, encode, geo, ncbi_datasets' line usefully constrains when this tool applies and enumerates valid source values, but there is no when-not guidance and no named alternative for retrieving metadata in bulk.

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 that the operation targets an indexed FASTA and is available only for fasta, but it does not disclose error behavior, indexing prerequisites, auth considerations, or other operational traits. This is useful scoping context, not rich behavioral detail.

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

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

Very short and front-loaded: the core retrieval purpose comes first, followed by the fasta availability note. No filler or redundant sentences; every fragment contributes to scoping the 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?

An output schema exists, and the nested input schema documents Interval and FileRef in detail, so return values and field constraints need not be repeated. However, the description is thin on when to choose this tool over sibling genomic tools and gives minimal invocation context, leaving clear 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 description coverage is reported as 0%, so the description must compensate, but it does not document the file or interval parameters beyond the word 'interval' and 'indexed FASTA.' It omits required assembly, 0-based half-open coordinate semantics, contig naming, and file requirements such as index availability.

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 the specific resource returned: reference sequence for an interval from an indexed FASTA. 'Available for: fasta' scopes it to FASTA sources, distinguishing it from siblings like get_reads, get_variants, get_coverage, and get_features. An agent can identify this as sequence retrieval without opening the schema.

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

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

Only states availability for fasta; it gives no explicit guidance on when to use this tool versus alternatives like get_reads, get_coverage, or inspect_locus. No when-not conditions or routing cues are provided, leaving usage selection 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=true and openWorldHint=true, so the safety profile is covered. The description adds the bigWig-only constraint and the binned-summary capability, but says nothing about aggregation defaults, record limits, or what the returned signal looks like.

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 short sentences, front-loaded with the core capability. No filler, though the 'Available for: bigwig' line is terse enough that it could carry slightly more useful constraint detail.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. However, with 20% schema coverage the thin parameter documentation leaves meaningful gaps for bins, summary, and max_records semantics.

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

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

Schema description coverage is only 20% across 5 parameters, so the description must compensate and largely does not. It alludes to 'binned summaries over an interval' (bins, interval) but leaves the summary enum options (mean/min/max/coverage/std/sum) and max_records unexplained.

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

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

States a specific verb and resource: retrieving signal values or binned summaries over an interval, scoped to bigWig files. An agent can distinguish this from siblings like get_coverage or get_pileup by the 'signal values from bigWig' framing, though those alternatives are never named explicitly.

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

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

'Available for: bigwig' implies the precondition (file must be bigWig format), which is useful, but there is no explicit when-to-use versus get_coverage, get_pileup, or get_reads. Usage is only weakly implied.

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 that this is a follow-up to fetch_file, but omits whether the result is terminal, whether polling is expected, or what states exist. An output schema exists, so return values need not be described here.

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

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

Two short sentences, front-loaded with the purpose and the originating tool. The trailing 'Available for: default.' is boilerplate that adds little, but overall there is no waste.

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

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

With an output schema present, return values are adequately delegated. However, for a transfer-status poller the description says nothing about lifecycle states, polling cadence, or expiry, which an agent likely needs to use it correctly.

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

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

Schema coverage is 0% and the single parameter (transfer_id) has no inline description, so the description carries some burden. It implies the id originates from fetch_file, which is genuinely useful, but gives no format, type, or validity details.

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

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

States a specific verb+resource ('Get progress/result of a transfer') and explicitly ties it to the fetch_file tool that creates transfers, which distinguishes it from generic getters among its siblings. It does not, however, differentiate itself from cancel_transfer or other transfer-related siblings explicitly.

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

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

The phrase 'started by fetch_file' implies the usage context (poll after initiating a transfer), giving more than pure tautology. But there is no explicit statement of when to use it versus cancel_transfer, whether it must be polled repeatedly, or what to do once complete.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-access behavior are covered. The description adds format availability and that genotypes are optional, but omits behavioral details like pagination, record limits, or required file readiness.

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 short, front-loaded sentences with no filler. The core operation is stated first, followed by a concise format constraint.

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

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

Although an output schema exists and reduces the need to explain return values, the description is too sparse for a 6-parameter tool with low schema coverage. It omits guidance on alternatives, filtering, and the roles of most optional parameters, so an agent would need to inspect the schema heavily 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?

Schema description coverage is only 17%, so the description must carry more weight but does not. It mentions interval and optional genotypes, but says nothing about samples, pass_only, max_records, or include_genotypes, leaving most parameters semantically opaque.

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

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

The description clearly identifies the resource (variant records), scope (overlapping an interval), and supported formats (VCF/BCF). It distinguishes itself from most siblings like get_sequence and get_features, though it does not explicitly contrast with closely related tools such as lookup_variant or normalize_variant.

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

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

The phrase 'Available for: bcf, vcf' gives a format eligibility constraint, which implies when the tool can be used. However, it provides no guidance on when to choose this over sibling tools like lookup_variant or get_features, leaving selection to inference.

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

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

Annotations already cover read-only and open-world traits, but the description adds a non-obvious privacy gate: values derived from private files only leave the machine when allow_external_annotation is true. That is genuinely valuable behavioral context beyond the structured fields, though nothing is said about record capping or failure modes.

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 short sentences, front-loaded with the core purpose and immediately followed by the caveat that governs whether the call is safe to make. 'Available for: default' adds little but costs almost nothing.

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

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

An output schema exists so return values need not be described, and the key privacy caveat is present. However, for a 6-parameter locus-aggregation tool the description omits operational essentials such as how multiple files/assemblies are reconciled and how max_records affects 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 coverage is only 33%, so the description is expected to compensate. It does explain the privacy meaning of allow_external_annotation (whose schema entry has no description), but leaves interval, files, reference, and max_records semantics to the schema, so it only partially fills the 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?

States a specific verb (combine) and resource (data from several files at one locus, plus public evidence), which clearly separates it from single-source siblings like get_variants or get_coverage. It does not explicitly name which siblings it overlaps or supersedes, so it stops short of a 5.

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

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

There is no explicit statement of when to use this versus alternatives such as get_features, get_variants, or get_coverage at the same locus – the aggregation intent is only implied by 'combine data from several files'. 'Available for: default' is operational metadata, not usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the returned-field inventory (checksums, index, readiness) and the supported-source constraint, but says nothing about pagination via cursor, authentication per source, or rate limits.

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

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

Two short sentences with the core purpose front-loaded and the source constraint immediately after. No filler, no restatement of the tool name.

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

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

An output schema exists, so return values need not be described, and the source enumeration is useful. Still, for a 6-parameter tool with 17% schema coverage, the pagination cursor and storage_profile parameters are left entirely undocumented.

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

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

Schema coverage is only 17%, so the description must carry more, and it partially does: it enumerates valid source values that the schema leaves as a bare string. But accession, cursor, storage_profile, formats filtering, and max_records semantics remain unexplained in both places.

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 (list) and resource (files of a study/dataset) plus the fields returned (format, size, checksums, index, readiness). It is clearly distinct from siblings like list_samples, list_sources, and describe_dataset, though it never names an alternative explicitly.

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

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

The 'Available for: ega, ena, encode, geo, local, ncbi_datasets, s3' line gives real context about when this tool applies, which is more than nothing. However, there is no when-not guidance, no mention of how this differs from describe_dataset, and no routing advice for choosing among sources.

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 and network profile is covered. The description's 'as supplied by the source' hints that results are raw/unmodified from the upstream repository, but adds no detail on pagination, auth, or rate limits beyond that.

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 short, front-loaded sentences with no filler; the source enumeration is the most actionable part. Slightly terse for a multi-source, paginated listing tool, but nothing is wasted.

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

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

The presence of an output schema means return values need not be described, and the source list is helpful. Still, with three of four parameters undocumented and no routing guidance among many siblings, the definition is only minimally complete for the tool's complexity.

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

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

Schema description coverage is only 25% (just 'Lower the record limit.' on max_records), so source, accession, and cursor are undocumented in the schema. The description compensates only indirectly by naming the valid source values, and says nothing about cursor or accession semantics.

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

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

States a specific verb and resource ('List samples of a study/dataset') with the scoping qualifier 'as supplied by the source'. However, it does not differentiate from near-siblings such as get_sample_metadata or compare_samples, so an agent must infer which sample-oriented tool is appropriate.

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?

'Available for: ega, ena, encode, geo, ncbi_datasets' gives the applicable source domains, which is useful context. But there is no when-to-use vs when-not guidance relative to the many sibling tools (e.g. get_sample_metadata, list_files), leaving usage implied only.

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 safety is covered. The description adds that results carry state and supported operations per source, which is useful context, but it says nothing about permissions, pagination, or result size for a read across external sources.

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 filler, and the resource plus returned attributes are front-loaded. It is arguably under-specified rather than padded, but structurally it is clean.

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

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

An output schema exists, so return values need not be described, and the read-only annotations cover safety. However, for a tool whose only parameter is an undocumented enum filter, the description leaves the primary narrowing mechanism invisible, which is a real gap for an agent deciding how to call it.

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

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

Schema coverage is 0% and the single 'kind' parameter is never mentioned. The enum values (archive, catalog, reference, storage, local) are left entirely unexplained, so the caller cannot know that results can be filtered by source kind, even though 'reference' hints at one of them.

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

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

States a clear verb (List) and resource (data and reference sources) and even previews what comes back (state, supported operations). It does not differentiate itself from siblings like list_samples or list_files, which also enumerate resources, so the purpose is clear but not uniquely scoped.

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

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

The description gives no when-to-use guidance, no prerequisites, and names no alternative among the many sibling list/search tools. An agent must infer that this is the discovery step for sources rather than samples or files.

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 by structured data. The description adds nothing beyond that — no auth requirements, no coverage/rate notes, no explanation of what 'source-attributed' means operationally or what happens when a gene is absent.

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

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

It is short and the content-bearing fragment comes first, but the second fragment ('Available for: default') consumes space without conveying usable information. Brevity here reflects under-specification rather than disciplined conciseness.

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

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

An output schema exists, so return values need not be described, but with four parameters at 25% coverage and no usage context, an agent lacks enough to call this correctly. The definition is incomplete for a tool embedded among many similar lookup_* siblings.

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

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

Schema description coverage is only 25% (only 'sources'), and the description does not compensate: it never explains what 'gene' accepts (symbol, ID, accession?), what 'include' selects, or what 'assembly' should be. 'Source-attributed' faintly gestures at the sources parameter but gives no format or allowed values.

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 the resources involved (gene identifiers, transcripts, source-attributed annotations) but is a noun fragment with no verb, so the action (retrieve) is only implied. It does loosely distinguish itself from lookup_variant/lookup_protein by naming gene-centric data, but an agent must infer the actual operation.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternatives such as resolve_identifier or lookup_variant. The phrase 'Available for: default' is opaque and does not tell the agent which context or assembly selects this tool.

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 useful provenance context ('from UniProt and cross-references'), which goes slightly beyond the annotations, but it omits rate limits, authentication needs, and what 'cross-references' entails.

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

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

The description is short and front-loads the core purpose. However, the second sentence 'Available for: default.' is cryptic and does not earn its place, while the useful first sentence could provide more precise scope.

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

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

An output schema exists, so return format is covered, and annotations cover the safety profile. Still, the definition lacks usage guidance and does not explain the required protein input, leaving gaps for an agent choosing between multiple lookup tools.

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

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

Schema coverage is 50%: 'sources' is documented in the schema, but the required 'protein' parameter has only a title and no description. The description does not explain accepted protein identifier formats or how 'sources' constrains cross-references, so it fails to compensate for the missing 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?

States a specific lookup operation on proteins, including the data returned (identity, function, features) and the source domain (UniProt and cross-references). It distinguishes itself implicitly from lookup_gene and lookup_variant by resource, but does not explicitly contrast with close siblings like get_features or get_sequence.

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

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

There is no explicit when-to-use guidance, no alternatives named, and no prerequisites or exclusions. The phrase 'Available for: default.' is not actionable usage guidance.

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

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

Annotations already cover read-only and open-world behavior. The description adds useful context about source attribution and the absence of a clinical verdict, plus optional Atlas as a source. It does not add auth, rate-limit, or return-format details, but the output schema exists.

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 short and front-loaded, quickly stating what evidence is returned and which sources are involved. The final fragment 'Available for: default' is vague filler, but the overall text is 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?

Given six optional parameters and multiple identifier modes, the description omits critical invocation guidance, such as whether hgvs, rsid, or a variant spec must be supplied. The output schema mitigates return-value concerns, but input completeness is poor.

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

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

Schema description coverage is only 17%, so the description must compensate and does not. It never explains accepted variant identifiers (hgvs, rsid, variant spec), include, or assembly; it only indirectly names possible sources, leaving most parameter semantics opaque.

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

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

The description clearly states the resource: source-attributed evidence for a variant, with named sources (ClinVar, gnomAD, Ensembl, optional Atlas). It also distinguishes the output from a consensus or clinical verdict. However, it does not explicitly differentiate from siblings such as normalize_variant or get_variants.

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

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

There is no guidance on when to use this tool versus alternatives like normalize_variant, get_variants, or resolve_identifier. The phrase 'Available for: default' is cryptic and provides no actionable usage context or prerequisites.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds only the vague phrase 'with a trace' plus 'on an explicit assembly'. It never says what the trace contains, whether remote source lookups occur, or what a failed normalization looks like — gaps that matter for an open-world, multi-source resolver.

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

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

The core sentence is tight and front-loaded with the action, which is good. The appended 'Available for: default' clause is unexplained boilerplate that adds noise without information.

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

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

With six optional parameters and three apparently alternative input forms, the description never states that you supply exactly one of variant/hgvs/rsid, nor how assembly applies to each. An output schema exists so return values need not be described, but the invocation contract is left ambiguous.

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

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

Schema description coverage is only 17%, so the burden largely falls on the description. It helpfully maps the recognized input forms (VCF-style/HGVS/rsID) onto variant/hgvs/rsid and flags the assembly requirement, but says nothing about whether inputs are mutually exclusive, how rsid is resolved, or what the reference FileRef is for.

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

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

States a clear verb+resource ('Normalize a variant') and enumerates the accepted input forms (VCF-style, HGVS, rsID), which is genuinely informative. It does not differentiate from close siblings such as lookup_variant or resolve_identifier, which likely overlap in purpose, so it falls short of a 5.

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

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

No statement of when to use this over lookup_variant, resolve_identifier, or inspect_locus, and no prerequisites or exclusions. The trailing 'Available for: default' is boilerplate that gives an agent no routing signal.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that it 'reports ambiguity' rather than failing — but says nothing about resolution precedence, source selection behavior, or multi-match 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?

Two tight clauses, front-loaded with the verb and resource; nothing is padded. The trailing 'Available for: default' reads as auto-generated boilerplate that adds no information but costs little.

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

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

An output schema exists, so return values need not be explained. However, for a 4-parameter cross-entity resolver with 25% schema coverage and overlapping siblings, the description leaves the agent without enough to pick sources/assembly or to know how ambiguity is surfaced.

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

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

Schema description coverage is only 25%: 'sources' is documented but 'assembly', 'target_types', and 'identifier' lack schema descriptions. The description implies the accepted identifier types (mapping loosely to target_types) but never explains assembly selection or source scoping, so it does not compensate for the coverage 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?

States a specific verb+resource ('Resolve a ... identifier') and names the identifier kinds it covers (gene/transcript/protein/variant), plus the behavioral outcome ('reports ambiguity'). It is clear but never distinguishes itself from siblings like lookup_gene, lookup_protein, or lookup_variant, which plausibly overlap.

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

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

The only usage signal is the boilerplate 'Available for: default', which gives no context. There is no guidance on when to use this generic resolver versus the type-specific lookup_gene/lookup_protein/lookup_variant siblings, nor any prerequisite or 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 establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the search is limited to one archive/catalog and lists valid sources, which is useful context beyond the annotations, but it does not describe pagination, rate limits, or result behavior.

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

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

The description is two short sentences, front-loaded with the core action and followed by the source constraint. There is no filler or repetition, and every sentence contributes useful 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 six parameters, low schema coverage, and no explicit routing guidance, the description is not complete enough. It covers the required query and source values, but omits how optional filters and pagination work and does not help an agent choose this tool over its siblings.

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

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

Schema description coverage is only 17%, so the description must compensate for missing parameter semantics. It clarifies the required query as text search and lists allowed source values, which is valuable. But it says nothing about cursor, assembly, organism, or max_records beyond the schema's minimal note, leaving most optional parameters undocumented.

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: search one archive/catalog for studies or datasets by text query. It also enumerates valid source values (ega, ena, encode, geo, ncbi_datasets), which helps an agent understand scope. However, it does not clearly differentiate this tool from adjacent retrieval tools such as describe_dataset or list_sources.

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 a source availability list, but no explicit guidance on when to use this tool versus alternatives like describe_dataset, list_sources, or list_files. It lacks when-not-to-use conditions and does not explain the role of optional filters or pagination.

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