Server Quality Checklist

Tool Scores

• search_unirefA
  3.9/5.0
  Behavior4/5

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

  The description discloses return fields (cluster id, name, counts, representative) and the effect of the identity parameter, providing sufficient transparency for a read-only search tool without annotations.

  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 description is concise with three sentences, front-loaded with key information, and free of fluff, though it could be slightly more streamlined.

  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?

  Given the output schema exists, the description adequately covers what the tool does and what it returns, making it complete for a search tool.

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

  Parameters3/5

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

  Schema coverage is 100% and descriptions are clear; the overall description adds background context but does not significantly enhance parameter understanding beyond the schema.

  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?

  The description clearly states it searches UniRef clusters, distinguishes it from sibling tools like search_uniprotkb and get_entry by specifying the database and the nature of clusters.

  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?

  The description gives query examples and mentions the identity parameter, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria.

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

• search_proteomesA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description must stand alone. Mentions it is a search (safe read operation) but does not explicitly state read-only nature or any limitations. Adequate but not thorough.

  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?

  Two sentences with no wasted words. First sentence defines purpose, second sentence lists key parameters and output. Front-loaded and efficient.

  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?

  Given output schema exists, return values need not be explained. Covers purpose, key parameters, and output fields. Brief but complete for a search tool with good schema documentation.

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

  Parameters3/5

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

  Schema coverage is 100%, so parameters are documented. Description restates filtering options already covered in schema, adding little extra meaning beyond the schema.

  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?

  Clearly states it searches UniProt proteomes, returns specific fields (UPID, organism, type, counts), and distinguishes from sibling tools like search_uniprotkb and search_uniref.

  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?

  Provides guidance on filtering by organism_id and reference_only=True. Implicitly distinguishes from siblings, but lacks explicit when-not-to-use or alternative tool references.

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

• get_taxonomyA
  4.1/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden. It discloses the return fields (taxon ID, names, rank, lineage) and the dual input behavior. However, it doesn't mention read-only nature, rate limits, authentication, or any potential side effects. For a simple lookup, this is adequate but not exhaustive.

  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?

  The description is three sentences, front-loaded with the main purpose, and contains no fluff. Every sentence adds value: purpose, input behavior, output/use case. It is highly efficient.

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

  Completeness5/5

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

  Given the simplicity of the tool (one parameter, no nested objects), the description fully covers what the tool does, how to use it, and what it returns. The presence of an output schema further reduces the need to describe return values. The description is complete for agent decision-making.

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

  Parameters3/5

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

  The single parameter 'query_or_id' is fully described in the input schema (100% coverage). The description adds the concept of 'fetch' vs 'search' but does not significantly expand beyond the schema's own description. Thus it meets the baseline of adding some context but not much extra value.

  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?

  Clearly states the tool resolves a taxonomy name or ID, and explains it can accept either a numeric taxon ID or a name. It specifies what is returned (taxon ID, names, rank, lineage) and differentiates from sibling tools like search_uniprotkb by noting that it provides the organism_id needed for that search.

  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?

  Provides an explicit use case: converting an organism name into an organism_id for search_uniprotkb. While it doesn't explicitly state when not to use it, the description effectively implies the tool is for taxonomy resolution before other searches. Sibling tools are listed but not directly compared, so some guidance is implicit.

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

• search_uniprotkbA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavioral traits. It notes that default output is a 'compact summary' and that 'total match count is always reported' for paging. It also states that reviewed and organism_id are 'appended to the query for you.' However, it does not mention response format details (beyond summary/fasta/tsv), pagination mechanism, rate limits, or error handling, leaving some gaps.

  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?

  The description is two concise sentences followed by brief parameter-specific notes. The first sentence clearly states the tool's purpose, and the second provides usage context. No redundant information; every sentence earns its place.

  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?

  Given the tool has 6 parameters and an output schema, the description covers key aspects: purpose, default return format, filtering options, paging hint. It is missing explicit mention of how to use format='fasta' or 'tsv' and pagination details, but the output schema covers return structure. Overall, it is adequate for a search tool.

  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 coverage is 100%, and the description adds valuable context beyond the schema: for 'query', it gives examples of UniProt syntax; for 'reviewed' and 'organism_id', it explains they are appended automatically; for 'fields', it clarifies applicability; for 'format', it describes the three values. This enriches the agent's understanding.

  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?

  The description clearly states 'Search UniProtKB and return matching protein entries.' It uses a specific verb ('Search') and resource ('UniProtKB'), and the examples of search criteria (gene, name, organism, etc.) distinguish it from sibling tools like get_entry (single entry) and get_fasta (sequence retrieval).

  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 explains when to use the tool ('find proteins by gene, name, organism, keyword, length, etc.') and hints at alternatives (e.g., for specific entries, use get_entry). It provides guidance on filtering with reviewed and organism_id, and mentions paging based on total match count. However, it does not explicitly list when not to use it or contrast with all siblings.

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

• get_entryA
  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 full burden. It details what each format returns, but does not explicitly state that the operation is read-only or mention error handling.

  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?

  The description is concise with two sentences. The first sentence states the purpose, the second explains formats. No unnecessary words.

  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?

  Given output schema exists and schema coverage is full, the description adequately covers functionality. It could better differentiate from siblings, but is complete for a fetch tool.

  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 coverage is 100%, baseline 3. The description adds value by elaborating on the 'format' parameter options, especially the content of 'summary', going beyond the enum names.

  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?

  The description clearly states 'Fetch one UniProtKB entry,' specifying the resource and action. It distinguishes itself from siblings by detailing available output formats.

  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 explains when to use each format (summary for digest, json for full record, etc.), but does not contrast with sibling tools like 'get_fasta'.

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

• map_idsA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description bears full burden. It discloses async behavior, enrichment condition for certain to_db values, and validation feedback (returns allowed databases on invalid value). It doesn't mention rate limits or auth, but the context is adequate for a data mapping tool.

  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?

  The description is three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, workflow details, and validation behavior. No wasted words.

  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?

  Given the presence of an output schema, the description sufficiently covers what the tool does and returns. It explains the async polling and enrichment for certain target databases. Could be slightly more detailed about the response format, but overall complete.

  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 100%, so baseline is 3. The description adds operational context (async nature, enrichment, validation) beyond the schema's parameter descriptions, enhancing understanding of how the tool uses the parameters.

  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?

  The description clearly states the tool maps identifiers between databases using UniProt's async ID-mapping service. It specifies the verb 'map' and the resource 'identifiers between databases', distinguishing it from sibling tools like get_entry or search_uniprotkb.

  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 explains the async workflow (submits job, polls, returns results) and gives a specific usage hint ('Use 'UniProtKB_AC-ID' as from_db when starting from UniProt accessions'). It also describes validation behavior. However, it does not explicitly state when not to use this tool or point to alternatives.

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

• get_fastaA
  4.8/5.0
  Behavior5/5

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

  Discloses important behaviors: endpoint selection (single vs batch), silent dropping of unknown/obsolete accessions with a note, and rejection of malformed accessions. No annotations exist, so description carries full transparency burden and does so thoroughly.

  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?

  Three sentences efficiently cover purpose, endpoint behavior, and critical warnings. No fluff, well-structured.

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

  Completeness5/5

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

  For a simple one-parameter tool, the description covers all essential aspects: what it returns, how it handles different inputs, and error cases. Output schema exists and need not be explained.

  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?

  The schema covers the parameter fully, but the description adds significant meaning: the endpoint logic conditional on input size and the consequences of different accession types. This goes beyond the schema description.

  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?

  The description clearly states the tool returns raw FASTA sequences for UniProtKB accessions. It distinguishes from siblings like get_entry by specifying the output format, and the verb is specific.

  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?

  Context for when to use is clear (requesting FASTA), but no explicit comparison to siblings like get_entry or map_ids. However, the description provides critical usage notes about accessions, which guide correct invocation.

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