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

No annotations exist, so the description carries the full burden, and it does disclose the bulk/export nature and both output encodings. It says nothing about result-size limits, truncation or streaming behavior, whether 'export' produces a file path versus inline payload, or any permission requirements — meaningful gaps for a bulk retrieval tool. Annotations are absent but an output schema exists, which softens the return-value gap.

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

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

Front-loaded with purpose and usage in two sentences, then a compact per-parameter list; every line adds information. The Args block restates parameter names already present in the schema, a minor redundancy, but the grouping is scannable and waste-free.

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 8 parameters, zero annotation coverage, and only one required field, the description gives an agent enough to construct a call: purpose, scale-oriented usage, and an example-bearing description for every parameter. Return values are covered by the output schema, so the remaining gap is behavioral (size limits, query syntax) rather than structural.

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 description compensates by documenting all eight parameters with concrete examples ('telomerase', 'hsa-mir-126', 'HOTAIR'; 'miRBase', 'GENCODE', 'Ensembl') and units for the length bounds. It falls short on the most important parameter — the query's syntax/matching semantics (free text, exact ID, boolean?) are not specified, nor are the allowed values for format constrained beyond an example.

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 ('Export bulk RNA sequences matching a query') plus the output formats, which is far more than a tautology. It does not name the sibling it differs from (search_sequence, query_rnacentral), so an agent must infer the boundary itself, keeping it 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?

'Use this for large-scale data retrieval (e.g., ML dataset generation)' gives a real usage cue that implicitly contrasts with the single-record search siblings. However it never names an alternative tool or states when NOT to use it (e.g., for a single sequence lookup use search_sequence), leaving the routing decision to inference.

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

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

With no annotations, the description must carry the behavioral load. It usefully discloses that gene_symbol is resolved to coordinates via Ensembl (an external dependency and latency/ambiguity source), and 'Get' implies a read-only operation. But it omits what 'overlapping' means (boundary/strand semantics), any result limits or pagination, and species validation 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?

Front-loaded with the purpose, then a scannable either/or constraint and an Args list. The either/or block partially duplicates the chromosome/start/end/gene_symbol entries in Args, which is minor redundancy but reinforces the critical 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?

An output schema exists, so return values need not be explained, and all parameters are described. For a region-overlap lookup tool this is nearly complete; the remaining gap is the meaning of 'overlapping' and the required-status of species, both of which affect correctness of calls.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: all five parameters are documented with examples, including accepted chromosome forms ('1', 'X', 'chr1') and both species naming conventions ('human' vs 'homo_sapiens'). It does not state which parameters are required (species) or the coordinate convention, which the schema alone cannot convey.

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

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

States a specific verb and resource ('Get non-coding RNAs overlapping a genomic region or a specific gene') with an explicit two-mode scope (region vs. gene). This clearly separates it from siblings like search_sequence or query_rnacentral, though it never names those alternatives to reinforce the distinction.

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

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

The 'You must provide EITHER chromosome/start/end OR gene_symbol' block is strong invocation guidance that prevents malformed calls. However, it gives no guidance on when to prefer this tool over sibling tools such as query_rnacentral or search_sequence, and no exclusions or prerequisites beyond the either/or constraint.

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

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

With no annotations, the description carries the full burden; it does disclose the read-only nature ('Get') and that the result is a literature-based summary rather than raw sequence. It does not disclose what happens when an RNA has no curated description, whether a remote lookup can fail or be slow, or any error behavior — material gaps for a lookup tool.

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

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

Front-loaded one-line purpose followed by conventional Args/Returns blocks with no filler. The Args section mostly restates the schema, so it is slightly redundant, but nothing is verbose or 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?

The output schema already documents the return type, and the description is appropriately short for a one-parameter tool. The missing pieces are operational: ID format prerequisites and behavior for RNAs lacking a literature description, neither of which structured fields cover.

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 single parameter has 0% schema description coverage, so the description must compensate; the example ('mmu-mir-191') usefully conveys ID format. However it never states whether this must be an RNAcentral-native ID or whether external IDs need map_rna_id first, which is the key semantic ambiguity.

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: retrieves a literature-derived textual description of an RNA sequence from RNAcentral. This is clearly distinct from siblings like get_secondary_structure_svg or search_sequence, though the description never names a sibling to contrast with.

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

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

Usage is only implied by the purpose statement — there is no explicit 'use this when...' and no mention of when to prefer map_rna_id or query_rnacentral instead. The 'e.g. mmu-mir-191' example hints at expected ID form but is not framed as a requirement.

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

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

No annotations are supplied, so the description carries the full burden. It says the result is SVG but never clarifies whether that is raw SVG markup, a file/URL, or base64, nor what happens when no secondary structure exists (error, empty, fallback). For a no-annotation tool this is a real gap.

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

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

Two short lines with the purpose front-loaded and no filler. The 'Args:' block slightly repeats the schema but is minimal and readable.

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

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

For a one-parameter read tool with no annotations and no output schema, the description covers what the tool fetches but not the return shape or failure modes. An agent could call it, but not predict the response payload or handle the no-structure case.

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 schema only exposes a bare 'Urs Id' string, so the description is doing the work: it identifies the value as an RNAcentral URS ID and supplies a concrete example format ('URS0000049E57'). That is genuine added meaning beyond the schema, though it doesn't state whether the ID must already be mapped/canonical.

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

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

States a concrete verb and resource — 'Get the secondary structure (2D diagram) for an RNA sequence' — plus the output format (SVG). It is clearly distinguishable from siblings like search_sequence and map_rna_id, though it never names an alternative explicitly, which keeps it 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?

There is no when-to-use guidance, no mention of alternatives, and no stated preconditions such as whether the URS ID must correspond to a sequence with a known/predicted structure. The only usage signal is implicit in the purpose statement.

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

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

With no annotations, the description carries the burden well: it discloses that the tool is a polling endpoint, that it returns progress mid-run and a markdown hit summary on completion, and that the caller should re-poll after a delay. It omits what happens on an invalid or expired job_id, which keeps it from a 5.

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

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

The key behavior is front-loaded in the first sentence, followed by the return-state distinction and the retry cadence. The Args block is mildly redundant but small, and every remaining sentence carries real information.

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

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

An output schema exists, so the description need not explain return shapes; the polling loop and the progress-vs-final distinction are the essential missing pieces and both are present. Only failure-mode behavior (expired/unknown job) is unaddressed for this complexity level.

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 is only typed as 'string', so the description must supply meaning — it identifies job_id as the ID returned by search_sequence, which is exactly the linkage an agent needs. It does not state format or validity constraints.

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 — 'Check a sequence search job started by search_sequence' — and names the sibling tool that creates the job. An agent can distinguish this poller from search_sequence and the other siblings without reading any schema.

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

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

Explicitly says to use this after search_sequence and gives concrete polling guidance ('wait e.g. 30-60s and call again') when the job is still running. It lacks any exclusion or termination/error guidance, so it falls short of a full when/when-not statement.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the bidirectional mapping behavior, but says nothing about what happens with ambiguous identifiers (one ID mapping to many external IDs), unmatched IDs, or result cardinality — an output schema exists but the description does not frame the semantics of multiple matches.

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

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

Two short front-loaded sentences establish purpose, followed by a compact Args block. The second sentence slightly restates the first but earns its place by naming the specific identifier namespaces.

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 two parameters, an output schema, and no annotations, the core is covered, but an agent still cannot predict behavior for ambiguous or unknown IDs and how the taxon narrows results. The gap is moderate rather than severe.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it states that identifier accepts either a URS ID (with example "URS0000759B6D") or an external ID ("MIMAT0000062"), and that taxon accepts a name or NCBI Taxonomy ID with a preference for scientific names. Only the taxon's effect on filtering results is left unstated.

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: bidirectional mapping between RNAcentral URS IDs and external database identifiers. This is clearly distinct from siblings like search_sequence or query_rnacentral, though it never names those alternatives.

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

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

"Bidirectional" implies the tool is used whenever an ID must be converted in either direction, but there is no explicit when-to-use versus when-not-to-use guidance and no mention of an alternative tool for resolution or lookup. Usage is only inferable.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that results merge text-search hits with metadata sources (Rfam, GO, 2D structure) and that limit is capped at 20, but says nothing about result ranking, pagination, whether results are deduplicated, or error behavior — significant gaps for a six-parameter search tool with zero annotation coverage.

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

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

Front-loaded summary sentence followed by a compact per-argument block; each line adds information and there is no filler. Slightly verbose in restating parameter titles, but the structure is 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?

An output schema exists, so return values need not be described, and all six parameters are documented despite 0% schema coverage. The remaining gap is the absence of any routing guidance relative to the several similar sibling search tools.

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

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

Schema description coverage is 0%, so the description must do all the work, and it largely does: every parameter is explained with examples, taxon guidance recommends scientific names over common names, and the limit cap of 20 is added beyond the schema's bare default of 10. Only rna_type and expert_db lack enumerated accepted 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?

States a specific verb and resource ('Comprehensive search for RNA sequences') and names the data sources (EBI Search, RNAcentral) plus the metadata dimensions returned (Rfam, GO, 2D structure). It does not explicitly distinguish itself from siblings like search_sequence or get_rna_description, so an agent must 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?

Usage is only implied by the phrase 'Comprehensive search' and the example query terms; there is no explicit when-to-use versus when-to-use-a-sibling guidance, no stated prerequisites, and no note on when the optional filters should be applied.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the operation is asynchronous, returns immediately with a job ID, and can take minutes to hours under load. It omits permission/auth requirements and any rate-limit or failure-mode detail, but the latency and non-blocking behavior are exactly the traits an agent most needs.

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

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

Front-loaded with the action and the async contract, then structured Args/Returns sections. There is minor redundancy: "Returns a job ID immediately" is restated in the Returns block, and the output schema already declares the return shape.

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

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

For a two-parameter async search tool with no annotations, the description supplies the full call-and-poll workflow, the latency expectation, and both parameter meanings. Nothing an agent needs in order to invoke it correctly and follow up 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 0%, so the description must compensate, and it does: both parameters are explained, including that databases is optional, is a list of specific databases, and defaults to all databases. It does not give valid database name examples or sequence format constraints, which is the remaining 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 and resource ("Start a background search of the RNAcentral database for a given RNA sequence") and immediately makes the async job model explicit, which distinguishes it from the sibling get_sequence_search_results that only retrieves results. An agent can tell the two apart without opening either schema.

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

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

Gives clear operational guidance: call this to start, then poll get_sequence_search_results with the returned job ID until results appear. It does not address when to prefer the sibling query_rnacentral instead, nor any exclusion for short/ambiguous sequences, so it falls short of full when/when-not coverage.

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