Server Quality Checklist

Tool Scores

• count_recordsB
  3.4/5.0
  Behavior3/5

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

  No annotations are supplied, so the description carries the full behavioral burden. It clarifies the meaning of include_subspecies and the record_type categories, and 'count' implies a read-only, non-mutating query, but it says nothing about permissions, rate limits, or whether counts are approximate — lean coverage on a read-only tool with an output schema.

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

  Conciseness4/5

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

  The purpose sentence is front-loaded and the Args block is compact, with each parameter getting exactly one explanatory line. No template boilerplate or restated field names beyond what is needed.

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

  Completeness4/5

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

  For a low-complexity, single-taxon counting tool with a declared output schema, the definition gives enough to call it correctly: every parameter is explained and the domain is named. The remaining gap is the absence of routing guidance against the sibling tools.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must supply all parameter meaning, and it largely does: species accepts scientific or common names with worked examples ('Bos taurus' or 'cattle'), record_type enumerates the three values with 'read_run' glossed as sequencing runs, and include_subspecies is defined as counting subspecies and breeds. Only a fuller gloss on 'sample' and 'assembly' is missing.

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

  Purpose4/5

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

  The description states a specific verb and resource ('Count records') scoped to a species within a named repository (ENA, EMBL-EBI), which is clear enough to distinguish it from retrieval-oriented siblings like search_samples and get_biosample. It stops short of explicitly contrasting itself with those siblings, so it lands just below top marks.

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

  Usage Guidelines2/5

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

  There is no statement of when to reach for count_records instead of search_samples, get_biosample, or check_sample_metadata, and no mention of prerequisites or cost tradeoffs of a counting query. The agent must infer the use case purely from the verb.

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

• search_samplesA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It does disclose the return shape (total count plus up to `limit` records with named fields) and the bounded limit range, which is useful. However, it says nothing about authentication, rate limits, error behavior, or how pagination beyond `limit` works.

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

  Conciseness5/5

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

  Front-loads the purpose, then the return summary, then the argument list in a clean labeled block. No sentence is redundant and the optional-filter caveat is placed where it matters.

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

  Completeness4/5

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

  With an output schema present and all parameters fully documented, the description is nearly self-sufficient for correct invocation. The remaining gap is the absence of any sibling-routing or access/permission context, which matters given three adjacent tools.

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

  Parameters5/5

  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: every one of the four params is explained with meaning and examples (species as scientific or common name, country name with omit-for-all semantics, limit range 1-100 with default 20, include_subspecies covering subspecies and breeds).

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

  Purpose4/5

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

  States a concrete verb and resource ('Find samples in the European Nucleotide Archive for a species') and names the data source, which is more than a generic search label. It does not explicitly distinguish itself from siblings like get_biosample or count_records, 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.

  Usage Guidelines3/5

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

  Usage is implied by the purpose and by the per-argument hints ('Omit for all countries', optional country filter). There is no explicit when-to-use/when-not guidance or mention of the alternatives (get_biosample, count_records), so the agent gets context but not routing rules.

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

• get_biosampleA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the disclosure burden. It usefully signals that the full record's attributes are returned and that some fields exist only 'where submitted' (i.e. may be absent), which sets expectations. However, it says nothing about permissions, rate limits, or failure behavior when an accession is invalid.

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

  Conciseness4/5

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

  Front-loaded with the core action, and the attribute list is a single efficient clause. The 'Args:' block is slightly formal/verbose for a one-parameter tool but still earns its place by clarifying the accession format.

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

  Completeness4/5

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

  An output schema exists, so return-value documentation is not required, and the single parameter is fully explained. What remains thin is operational context (auth, error handling), but for a simple one-param read tool the description is largely sufficient.

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

  Parameters4/5

  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 defines 'accession' as a BioSamples accession, gives a concrete example format ('SAMEA7658521'), and specifies the authoritative source (the output of search_samples). Only minor detail like locale/validation rules is missing.

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

  Purpose5/5

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

  States a specific verb and resource ('Get an EMBL-EBI BioSamples record') and enumerates the content it returns (organism, geographic location, tissue, breed, sex). It also routes the agent away from the sibling search_samples by tying the accession to that tool's output, so it is distinguishable 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.

  Usage Guidelines4/5

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

  'Use the accession returned by search_samples' gives a clear usage path and identifies the correct upstream tool. It stops short of stating when NOT to use this tool or what to do if no accession is known, so it is strong but not exhaustive.

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

• check_sample_metadataA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and does so partly: it discloses that the check always evaluates ENA's mandatory fields, defines what counts as a failure (absent, INSDC missing-value term, bad formatting), and implies this is a read-only validator by nature. It stops short of explicitly stating permissions, that the sample need not exist/be reachable, or that validation is non-mutating.

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

  Conciseness4/5

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

  The narrative is front-loaded and the Args block is compact and skimmable. Slight redundancy between the prose summary and the Args section, but every sentence adds information and no padding is present.

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

  Completeness4/5

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

  For a two-parameter read-only validator with an output schema, the description covers purpose, semantics, and the validation criteria an agent needs to interpret results. The output schema handles return format, so the only missing element is explicit guidance on sibling selection and any preconditions on sample accessibility.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description must compensate, and it does: 'accession' is grounded with a concrete example ('SAMEA7658521'), and 'extra_fields' is explained as additional required attributes with a domain-specific example. Both parameters' intent is fully recoverable from the description alone.

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

  Purpose5/5

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

  States a specific verb and resource ('Check whether an ENA/BioSamples sample's metadata is complete and well-formed') and immediately enumerates what the check covers (required fields, missing-value terms, ISO 8601 date format). This distinguishes it cleanly from siblings like get_biosample (retrieval) and count_records (aggregation), none of which validate metadata.

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

  Usage Guidelines4/5

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

  The description gives clear positive context (validate a BioSamples sample's metadata, with an explicit livestock/FAANG example motivating extra_fields), so an agent knows when this tool applies. However it never states when NOT to use it or names an alternative among the siblings, so it falls short of a 5.

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