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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does not mention read-only status, side effects, permissions, rate limits, or error conditions. The verb 'Fetch' implies a read operation, but this is not explicit.

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

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

The description is concise, starts with the primary action, and avoids unnecessary fluff. The enumeration of annotation types is slightly redundant with the schema, but overall it is well-structured and to the point.

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

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

Given the moderate complexity (multiple annotation types, pagination), the description is adequate but not complete. It does not mention output format, pagination behavior, or any caveats, though the schema provides some of this detail. The description covers the core purpose but leaves 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?

The schema already provides descriptions for accession and annotation_type, including the meaning of each enum value. The description repeats the enum and adds a helpful 'Pick...' recommendation, but does not significantly expand on the schema's parameter semantics. The optional page and size parameters are not addressed in the description.

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

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

The description clearly states the action ('Fetch') and the resource ('typed annotation table for an analysis'), and it enumerates the valid annotation types. It does not explicitly name or contrast sibling tools, but the purpose is unmistakable.

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

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

The description gives partial usage guidance by recommending which annotation_type to choose (e.g., 'Pick taxonomies__ssu for 16S/18S ribosomal taxonomy, pfams for protein-family annotation'). However, it does not explain when to use this tool as opposed to related tools like mgnify_get_analysis or mgnify_run_analyses.

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 provided, the description carries the full burden of behavioral disclosure. It adds value by listing response fields (pipeline_version, downloads, results_dir), which hints at the return structure. However, it does not disclose authentication requirements, error handling, rate limits, or whether the operation is read-only, though 'Get' implies it. The added field list is useful but not comprehensive.

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

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

The description is a single sentence with no redundant phrases. The core purpose is front-loaded, and the additional field list is concise. It earns a high score for brevity, though the lack of usage guidance means it is not maximally informative.

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

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

Given the tool's simplicity (one parameter, simple get operation) and the presence of an output schema, the description is largely sufficient. It states the purpose, gives an accession example, and hints at the response contents. The only gap is explicit usage context versus siblings, but that is addressed under usage_guidelines. For an agent to invoke the tool correctly, it has enough information.

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

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

The schema already describes the only parameter 'accession' with an example ('MGYA00012345'). The tool description repeats this example but adds no new semantic constraints, format details, or edge-case behavior. Since schema description coverage is 0% from the tool text, the description should compensate, but it does not go beyond what the schema provides, offering minimal extra meaning.

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

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

The description clearly states the action ('Get') and the resource ('one analysis by MGnify accession'), with a concrete example format. It distinguishes itself from sibling tools like mgnify_get_genome or mgnify_get_run by explicitly targeting analyses by accession. The mention of included fields (pipeline_version, downloads, results_dir) further clarifies the scope.

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

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

No explicit guidance is given on when to use this tool versus alternatives such as mgnify_study_analyses or mgnify_run_analyses. The description only states what the tool does, leaving the agent to infer selection based on the name. There is no mention of exclusions or scenarios where other tools are preferred.

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 communicate behavior. It says 'Returns length, completeness, taxon_lineage, etc.', indicating a read-only retrieval, but it does not mention possible error cases, absence of a genome, or any side effects. The basic behavior is clear, but not fully transparent.

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

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

The description is a single concise sentence with no redundant words. It states the action, the key parameter, and the primary return fields without unnecessary elaboration.

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

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

For a simple single-resource retrieval tool, the description includes enough context: the identifier format, an example, and expected return fields. It does not document all possible output details, but the essentials are present and sufficient for selecting and invoking the tool.

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

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

The only parameter, accession, is already fully documented in the schema with a description and example. The tool description reinforces this by repeating the example. No additional parameter meaning is needed, though the description adds no new detail beyond the schema.

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

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

The description clearly states the tool fetches one genome by MGnify accession, provides an example accession, and indicates the kind of data returned (length, completeness, taxon_lineage). This unambiguously distinguishes it from listing operations among sibling tools.

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

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

The description implies use when a single genome is needed by accession, but it does not explicitly state when to prefer this over sibling tools like mgnify_list_genomes or how to handle multiple genomes. Some guidance is inferable, but not directly stated.

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

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

The description gives no information about side effects, read-only nature, or any behavioral expectations. With no annotations to cover this, the agent is left without any statement about whether this operation is safe, destructive, or otherwise.

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

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

The description is a single, succinct sentence with no redundant words or information. It is highly efficient and easy to parse.

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

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

The description lacks context about the expected response structure, typical usage scenarios, or how this tool relates to sibling tools (e.g., mgnify_list_genome_catalogues). Even though an output schema exists, the description does not prepare the agent on what to do with the result or when to prefer this tool.

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

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

Although the description provides example values for the catalogue id, it does not explain the meaning, provenance, or how to obtain a valid id beyond what the schema already states. Given the schema description coverage is 0%, the description fails to compensate adequately.

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

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

The description clearly states the action 'Get', the resource 'genome catalogue', and the identification method 'by id' with concrete examples ('human-gut-v2-0-2', 'marine-v2-0'), making the purpose immediately unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives like mgnify_list_genome_catalogues, nor any conditions, prerequisites, or typical scenarios. The description gives no explicit indication of when this tool is the appropriate choice.

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 provided, the description carries the full burden of behavioral disclosure. It only states the basic 'Get' action without mentioning read-only nature, error handling, or any side effects. For a simple getter this may suffice, but it does not add any context beyond the obvious.

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

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

The description is a single, efficient sentence with zero fluff. It immediately conveys the purpose without unnecessary words, achieving high conciseness and proper front-loading.

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

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

The tool has an output schema, so return values are documented elsewhere. The description is adequate for a simple getter, though it does not mention not-found behavior or usage context. Minor gap, but acceptable given the tool's simplicity.

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

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

The schema already provides a description for the pubmed_id parameter (with an example). The description's mention of 'by PubMed id' adds minimal value, merely restating the parameter. Given the schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the action (Get), the resource (publication), and the distinguishing key (PubMed id). This immediately differentiates it from sibling tools like mgnify_list_publications (list all) and mgnify_study_publications (publications per study).

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

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

The description implies usage when you have a specific PubMed id, but does not explicitly state when to use this tool versus alternatives such as mgnify_list_publications or mgnify_study_publications. The context is clear but not explicit, so it earns a 3.

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 provided, the description carries the burden of disclosing behavior (e.g., read-only nature, error handling, or rate limits). It merely states the operation and gives no information about side effects, return structure, 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?

The description is a single, well-formed sentence that is immediately comprehensible. It is concise and to the point with no unnecessary words.

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

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

For a simple 'get by ID' operation, the description is minimal and lacks any mention of the output format, potential errors, or how this fits into the broader API context. Given the absence of annotations, more context would be expected.

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

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

The description mentions 'accession' and gives an example, but this is identical to the schema's own parameter description. It adds no new semantic meaning beyond what the schema already provides, so its contribution is redundant.

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

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

The description clearly states the action ('Get') and the resource ('one run'), and provides a concrete example of an accession ('ERR1234567'), making the tool's purpose unambiguous.

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

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

The description does not explicitly differentiate when to use this tool versus the sibling tools such as mgnify_list_runs or mgnify_sample_runs. It only implies specificity with 'one run,' but offers no direct guidance on selection criteria.

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 provided, the description carries the full burden of transparency. It mentions the return fields but does not explicitly state that the operation is read-only or has no side effects. As a 'get' operation this is somewhat implied, but not 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?

The description is two sentences that are concise and front-load the primary action. It efficiently conveys the purpose and expected output without extraneous 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?

The description lists the return fields (title, biome, metadata, related studies), which provides useful context. Since there is an output schema (though not shown), and this is a simple single-sample fetch, the description is adequately complete, though it omits any mention of error conditions.

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 parameter 'accession' already has a clear description in the schema (e.g., 'ERS123456' or 'SRS123456'), and the tool description repeats this example. This adds little beyond the schema, so the parameter semantics are adequately covered but not enhanced.

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

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

The description clearly states the action 'Get one sample' and specifies the resource type and identifier format with an example. It is specific enough to distinguish from other sample-related tools, though it does not explicitly name sibling 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?

The description lacks explicit guidance on when to use this tool versus alternatives (e.g., when you need a single sample by accession vs. listing samples). It provides an example but no context about prerequisites or conditions that make this the appropriate choice.

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 full responsibility for disclosing behavior. It does not mention that the operation is read-only, potential error conditions, or any other side effects. The description only states the returned fields without elaborating on behavioral nuances.

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

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

The description is a single, focused sentence with no redundancy. It efficiently conveys the core action, the parameter, and the expected return fields.

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

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

For a simple retrieval tool, the description provides enough context: it names the returned fields and gives an example accession. Combined with the existing input schema, an agent can invoke the tool correctly. It does not cover error handling or detailed return format, but that is adequately handled by the output schema (not shown here).

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

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

The input schema already includes a description and example for the accession parameter. The tool description adds an example ('MGYS00005292') and reiterates the parameter's purpose, but does not provide additional semantic detail beyond what the schema already offers. With the schema covering the parameter, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's action: get a single study by MGnify accession, with an explicit example. It distinguishes from sibling list/get tools by focusing on a single study fetch.

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 does not explicitly state when to use this tool versus alternatives like mgnify_list_studies or mgnify_study_analyses. It only implies usage for a known accession, but lacks direct guidance on when not to use it or which sibling is preferable.

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

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

The description implies a read-only operation (get) but does not explicitly state that it has no side effects or permissions. It mentions the response fields, which is useful behavioral information, but without annotations, transparency about side effects is incomplete.

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

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

The description is compact, using only two sentences to convey the action, the identifier format, and the response structure. There is no redundant or extraneous 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?

The description includes the response embedded fields (flagship_studies, related_studies, genome_catalogues) and illustrates the identifier with examples, providing solid context. However, it could clarify the distinction from the list super-studies tool, but the given details are largely sufficient.

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

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

The description explains the parameter as a 'url-slug' and provides three concrete examples, clarifying the expected format and values. This adds meaningful detail beyond the schema's basic description, which is sparse.

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

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

The description clearly states the action ('Get') and the resource ('a super-study') with a specific identifier (url-slug). It also provides concrete examples, leaving no ambiguity about the tool's purpose.

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 does not provide guidance on when to use this tool versus siblings like mgnify_list_super_studies or mgnify_get_study. It lacks any contextual cues about selection criteria, making it harder for an agent to choose the right 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal the pagination-only behavior and points to alternatives, but it does not mention output shape or pagination details. This is acceptable for a simple list operation, though slightly more detail could improve transparency.

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

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

The description is two concise sentences with no redundant wording. It efficiently conveys the purpose, limitation, and relevant alternatives.

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

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

For a simple listing tool, the description is complete: it identifies the resource, states the endpoint limitation, and names the appropriate sibling tools for filtered queries. No additional context is necessary for correct invocation.

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

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

The schema already documents the pagination parameters clearly, including page, size, defaults, and bounds. The description's note that the endpoint supports only pagination aligns with the schema. However, the required 'params' wrapper object itself is not explained, which is a minor 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 uses the imperative 'List MGnify analyses' and clearly identifies the resource and endpoint. It also distinguishes this tool from filtered sibling tools by stating that the v2 /analyses/ endpoint supports only pagination.

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 explicitly states when to use this tool versus alternatives: it supports only pagination, and users are directed to mgnify_study_analyses or mgnify_run_analyses for filtered lookups. This leaves no ambiguity about the intended use case.

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?

It discloses the key behavior of biome_lineage (prefix matching with descendants) and specifies that each item includes biome_name and lineage. Pagination behavior is not mentioned, but that is standard and inferable from the schema, and no annotations exist to contradict the description.

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 concise sentences, front-loads the primary action, and uses code formatting for parameters. There is no unnecessary detail or redundancy.

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

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

The description is complete enough for a straightforward list operation, covering the core functionality, filtering options, and output structure. It omits explicit mention of pagination parameters, but these are standard and present in the schema, so the overall context is adequate.

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

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

The description adds meaningful semantics beyond the schema by explaining that biome_lineage matches prefixes and all descendants, and that max_depth caps the lineage depth. Page and size are not described, but they are standard pagination parameters with schema descriptions.

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

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

The description clearly states that the tool lists biomes and provides examples of environmental categories (soil, marine, gut). It also specifies filtering by biome_lineage and optional max_depth, making the primary purpose unambiguous.

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

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

It provides concrete examples of biome_lineage values and explains that it matches prefixes and includes descendants, which aids in deciding when to use the tool. It doesn't explicitly contrast with sibling list tools, but the name and description are sufficiently self-explanatory.

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 not disclose that results are paginated, that pagination defaults to page 1 with size 25, or that only one page is returned at a time. The input schema reveals pagination parameters, but the description itself omits this behavior, leaving the agent unaware of potential truncation.

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

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

The description is a single, focused sentence that states the action, resource, examples, and return fields. No unnecessary words or repetition. It is well-structured and easy to parse.

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

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

The description covers the core purpose and outputs, which is sufficient for a simple listing operation. However, it lacks a note about pagination (e.g., 'results are paginated, use page/size parameters to navigate') which is a common context gap for list endpoints. The schema partially compensates, but the description could be more self-contained.

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 'params' (an object with page and size) is fully described in the input schema, including defaults and constraints. The description adds no additional meaning beyond the schema, so the baseline of 3 applies due to high schema coverage of the parameters.

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

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

The description clearly states the verb 'List' and the resource 'MGnify genome catalogues', provides concrete examples (human-gut, marine, chicken-gut), and lists the returned fields. It is easily distinguished from sibling tools like mgnify_get_genome_catalogue (singular fetch) and mgnify_list_genomes (genomes within a catalogue).

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

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

The description implies usage for enumerating available catalogues but does not explicitly state when to use this tool versus alternatives (e.g., 'use this before fetching a specific catalogue') or mention pagination handling. No direct comparison to sibling tools is provided.

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

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

No annotations are provided, so the description carries the burden. It indicates a read-only listing operation, but does not disclose return format, pagination behavior, or error handling. The absence of side-effect statements is acceptable for a list operation, but details are not explicitly stated.

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

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

The description is concise—one sentence plus an example—and front-loads the primary action and required parameter. It avoids unnecessary details and is easy to parse.

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

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

For a simple list operation, the description provides sufficient context: it names the resource, the required filter, and the v2 limitation. It does not describe return structure, but the listing nature and schema-provided page/size parameters make the operation understandable. Minor gap: no mention of what data is returned per item.

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

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

The schema describes all three parameters (catalogue_id, page, size) with examples and constraints, achieving high coverage. The description adds minimal extra meaning—only reinforcing the catalogue_id example and v2 scoping, which are already present in the schema. Baseline of 3 applies due to high schema coverage.

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

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

The description states a clear action ('List genomes') and a clear resource ('inside a catalogue'). It also notes that v2 only exposes genomes scoped to a catalogue, which clarifies the tool's specific purpose and distinguishes it from sibling list tools.

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

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

The description explicitly instructs to provide catalogue_id, includes a concrete example ('human-gut-v2-0-2'), and explains the v2 scoping requirement. It does not explicitly mention when to use this vs. alternatives, but the catalogue scope is implied by the instruction and example.

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

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

No annotations are provided, so the description carries the full burden of disclosing side effects or read-only behavior. The description does not state whether this operation is read-only, modifies data, or has any side effects. Since 'search' implies no modification, but this is not explicit, transparency is lacking.

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

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

The description is extremely concise, consisting of two short sentences. It avoids any unnecessary detail or repetition, making it easy to parse quickly. This is an exemplary level of brevity.

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

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

Given that the schema provides full descriptions for all parameters, the description does not need to repeat them. It covers the core functionality (search with filters) and is sufficient for a simple list operation. Missing details like pagination hints are already in the schema, so the description is contextually complete for its purpose.

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

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

The description summarizes the filters (title substring, year bounds, order) but merely repeats information already present in the schema descriptions. It adds no new semantic details beyond what the schema provides. Since schema coverage is complete, the baseline is 3, and the description meets but does not exceed this.

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

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

The description clearly states the tool's function as 'Search publications', naming the resource and action. It is concise and unambiguous, though it could benefit from stating what kind of publications are searched (e.g., from MGnify). Overall, the purpose is evident.

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

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

The description provides no guidance on when to use this tool versus alternative tools such as mgnify_list_studies or mgnify_get_publication. There is no mention of scenarios where this filter-based search is preferable, leaving the agent to infer context. This is a significant omission.

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

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

No annotations are provided, so the description carries the burden of conveying behavior. The verb 'List' implies a read-only operation, but no explicit statement about side effects, pagination behavior, or error handling is included. This is adequate but not richly transparent.

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

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

The description is compact: two sentences, with the core action first, then filter details, then alternative routing. No redundancy or unnecessary 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?

For a simple listing tool with a rich output schema, the description is complete. It states what the tool returns, how to filter, and when to use sibling tools instead, providing sufficient context for correct selection and invocation.

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

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

The input schema already documents page, size, and has_experiment_type with descriptions and an enum. The description only restates the enum values, adding little beyond the schema, so baseline 3 is appropriate.

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

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

Description opens with 'List sequencing runs', a clear verb and resource. It also distinguishes itself from sibling tools by explicitly directing study- or sample-filtered queries to mgnify_study_analyses or mgnify_sample_runs.

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

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

Provides explicit filter guidance with the accepted has_experiment_type values. Also gives clear when-not-to-use guidance by naming the alternative tools for study/sample-scoped run listing.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose that this is a read-only operation, nor any pagination or rate-limit behavior. The term 'search' implies non-destructive intent, but this is not explicit, and response format is omitted.

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

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

Single sentence with clear purpose, filters, and next step. Efficient and front-loaded; no wasted words.

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 list/search tool, the description covers purpose, filters, and follow-up. It does not mention pagination or output shape, but these are implied by the schema and the tool's nature. Adequate for the moderate 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?

The schema already provides descriptive text for all parameters (page, size, order, search, biome_lineage). The description names only three filters, adding no new meaning beyond the schema. With high schema coverage, baseline 3 is appropriate.

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

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

Description clearly states 'Search samples' with specific filters, and differentiates from siblings by framing it as discovery ('discover biological material') with a follow-up action. This distinguishes it from get_sample, study_samples, and others.

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 context on when to use: to discover biological material, then drill into runs/analyses. It implies this is for broad sample discovery rather than specific lookups, but does not explicitly exclude alternatives or state when not to use.

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

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

The description outlines the output items ('Each item has accession, title, biome, ena_accessions') and explains the semantics of several filters (e.g., 'matches descendants' for biome_lineage, prefix '-' for order). However, it does not explicitly state that the operation is read-only, nor does it describe pagination behavior (page/size defaults) or what happens when no results match, and there are no annotations to supplement this.

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

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

The description is compact—two sentences—with no redundant fluff. Every sentence contributes meaning: the first states the action and lists filters, the second describes the output structure. It is efficiently organized for quick consumption.

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 list/search endpoint, the description covers the main use cases: search terms, biome lineage matching, pipeline filtering, and ordering. It omits pagination parameters and default ordering, but these are minor and apparent from the schema. The description is sufficient to use the tool effectively without needing the schema, though it could benefit from a note on default pagination.

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

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

The description clarifies parameter meanings beyond the schema by providing concrete examples (e.g., 'has_analyses_from_pipeline' with '5.0') and noting that order supports '-' for descending. It does not mention page and size, but those are straightforward with schema defaults, and the description adds value for the key filtering parameters.

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

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

The description clearly states the tool's purpose as 'Search MGnify studies' and enumerates the key filtering and ordering parameters, making the primary function apparent. However, 'search' is a generic verb and could be more explicit about listing vs. returning a single study, though the filter list helps clarify.

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

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

The description provides no guidance on when to use this tool relative to sibling tools such as mgnify_get_study or mgnify_list_samples. It does not mention that this is the appropriate tool for browsing/top-level study discovery or filtering by biome/pipeline, leaving the selection context implicit.

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

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

With no annotations, the description carries the full burden, but it only says 'List' without indicating side effects, permissions, or whether it is strictly read-only. It also does not mention any rate limits or data scope.

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

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

The description is a single sentence with no unnecessary words. It is well-structured, though it could benefit from a brief note on pagination params, but brevity is a strength here.

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

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

The description explains what super-studies are (umbrella collections) and gives examples, but it does not clarify how this list differs from listing regular studies or when to fetch a single super-study. Given the context of sibling tools, some guidance would help.

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

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

The schema includes a 'params' object with 'page' and 'size', but the description does not mention these parameters at all. Since schema coverage is 0%, the description adds no meaning beyond the schema.

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

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

The description clearly states the action ('List') and the resource ('super-studies'), and provides concrete examples (Tara Oceans, Earth Microbiome Project, HoloFood) that distinguish it from other list tools like mgnify_list_studies.

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 explicit guidance on when to use this tool versus siblings such as mgnify_list_studies or mgnify_get_super_study. It does not mention typical use cases, pagination behavior, or how to narrow results.

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 provided, the description carries the full burden of behavioral disclosure. It only says 'List', which implies a read-only operation, but does not explicitly state that it is non-destructive, does not mention pagination behavior (though the schema covers page and size), and does not disclose error conditions or rate limits. The description is too sparse to adequately inform an agent about behavioral traits beyond the bare operation.

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

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

The description is a single, focused sentence with no filler words. It front-loads the primary action and scope immediately. Every word contributes to the meaning, making it highly concise and well-structured for its minimal length.

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

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

While the tool is simple and has an output schema (so return format need not be explained), the description lacks essential context for an agent to reliably choose it. It does not differentiate from sibling tools like mgnify_study_analyses, and it omits any guidance on when to use it versus alternatives. The description is minimal and leaves an agent to guess usage nuances, which is insufficient for confident tool selection.

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

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

The description adds no information about the parameters beyond what the schema already provides. The schema itself includes descriptions for accession (e.g., 'ERR1234567'), page, and size, but the tool description does not elaborate on their semantics or relationships. With schema description coverage indicated as 0%, the description was expected to compensate, but it provides zero parameter-level detail, failing to add any value beyond the schema.

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

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

The description 'List analyses produced from a single run' states a specific verb (list), a clear resource (analyses), and a distinct scope (single run). It naturally differentiates from siblings like mgnify_study_analyses (which would be from a study) and mgnify_list_analyses (which lists all analyses). The purpose is unambiguous and immediately 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 implies when to use it (when you have a run accession and want its analyses), but it does not explicitly state alternatives or when not to use it. There is no mention of mgnify_study_analyses or mgnify_list_analyses as alternatives, so an agent must infer the usage context. This is implied usage, not explicit guidance.

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

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

With no annotations, the description carries full responsibility for behavioral clarity. It implies a read-only listing operation, but side effects, permissions, and pagination behavior are not described beyond the schema's parameter details.

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

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

The description is a single, focused sentence with no unnecessary words or redundancy. It is well-structured and immediately understandable.

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

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

For a simple filtered list operation, the description combined with the schema's parameter details is largely sufficient. It lacks explicit output format details, but the action is straightforward and the optional pagination parameters are well-defined in the schema.

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

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

The schema already provides detailed descriptions for accession, page, and size, including an example accession. The tool description adds little beyond clarifying that runs are tied to a sample, so it does not significantly enhance parameter understanding.

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

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

The description clearly states the action ('List') and the resource ('sequencing runs') and indicates the relationship to a sample. It is specific enough to distinguish from listing all runs, though it could be more explicit by mentioning 'for a given sample accession'.

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 annotations or guidance are provided. The description does not explain when to prefer this tool over siblings like mgnify_list_runs or how it fits into workflows, leaving usage conditions implicit.

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

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

No annotations are provided, so the description carries the full burden. It only says 'List analyses produced from a study' and discloses nothing about pagination behavior, return structure, or that it's a read-only operation. The output schema exists but the description doesn't hint at any quirks or constraints.

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 clear sentence with no filler. It's appropriately short for a simple list operation, though it could be slightly more informative without losing conciseness.

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

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

For a straightforward list tool with an output schema, this might be adequate, but given no annotations and no explicit alternative routing, an agent may not know when to choose this over similar siblings. The description doesn't explain the study-to-analyses relationship or how to obtain a valid accession beyond the schema example.

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

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

The schema itself provides detailed descriptions for all parameters (page, size, accession with example), so the description adds little. Since schema coverage of parameters is effectively high (each parameter has a description), a baseline of 3 is appropriate. The description doesn't compensate for the nested 'params' object, but that's structural and not critical.

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

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

The description clearly states it lists analyses produced from a study, using a specific verb and resource. It distinguishes from siblings like mgnify_run_analyses (analyses from a run) and mgnify_list_analyses (generic list), though it doesn't explicitly name them.

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

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

No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a study accession) or contrast with similar tools like mgnify_run_analyses or mgnify_list_analyses. An agent has to infer usage from the name and schema.

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

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

The description is transparent about the tool's read-only nature ('List' indicates no side effects). There are no annotations to contradict this, and the description matches the expected behavior of a listing operation. Minor ambiguity remains about pagination or response format, but these are not hidden side effects.

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

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

The description is a single, concise sentence with no unnecessary words. It is well-structured and immediately conveys the tool's purpose.

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

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

The description adequately communicates the core functionality for a simple listing tool. It does not mention when to prefer this over sibling tools or describe the output format, but these are implied by the tool name, parameter schema, and output schema. Given the low complexity, the description is sufficient.

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

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

The schema already provides descriptions for all parameters ('accession', 'page', 'size'), covering their meaning. The tool description adds no additional parameter-specific guidance. Since schema coverage of parameter descriptions is high, the baseline score of 3 is appropriate.

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

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

The description clearly states that the tool lists publications linked to a study, which is a specific and unambiguous action. It distinguishes from sibling tools like 'mgnify_list_publications' (which lists all publications) and 'mgnify_get_publication' (which fetches a single publication).

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 does not explicitly state when to use this tool versus alternatives. However, the tool name and required 'accession' parameter imply it is for retrieving publications for a specific study. No direct comparison or guidance is provided, so the usage context is inferred rather than stated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states a read operation, but does not mention pagination behavior (page/size), the required 'accession' parameter, or any ordering/filtering details. The schema provides parameter details, but the description adds no behavioral context beyond the basic action.

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

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

The description is a single sentence with no filler, and the core action is front-loaded. It is appropriately concise, though it omits context that could be added without bloat. Efficiency is high, but it sacrifices completeness.

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

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

The tool has a required accession and pagination parameters, and an output schema exists. The description is too terse to provide the necessary context for correct invocation, such as indicating that a study accession is required or that results are paginated. While the schema covers parameter details, the description fails to orient the agent on the tool's scope and typical usage within the larger set of MGnify 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?

The schema itself provides descriptions for all parameters (page, size, accession) with defaults and examples, so the baseline is 3. The tool description adds no parameter information, but the schema is sufficient. The description does not compensate for any gaps, but none exist in the schema.

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

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

The description states a clear verb ('List'), a specific resource ('samples'), and a scope ('that belong to a study'). It implicitly distinguishes from siblings like mgnify_list_samples (all samples) and mgnify_get_sample (single sample), though it does not name alternatives. The purpose is unambiguous.

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

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

The description provides no guidance on when to use this tool versus its siblings. It does not mention that this is the tool for scoping samples to a specific study, nor does it contrast with mgnify_list_samples or mgnify_study_analyses. An agent would have to infer usage from the name and schema.

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