Server Quality Checklist

Tool Scores

• computase_summarize_sequenceA
  3.6/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the output metrics (composition, GC uncertainty, GC skew) but does not describe behavior such as normalization or how input limits are handled beyond what the schema already states. No contradiction with annotations.

  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 a single, front-loaded sentence with no filler or redundant restating of the title. Every word adds value by naming the specific analysis outputs.

  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 single parameter, rich annotations, and the presence of an output schema, the description is largely complete. It names the key computed metrics, and the output schema covers return details. It falls slightly short only by not addressing usage context relative to siblings, but this is a minor gap.

  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 description coverage is 100%, and the one required parameter 'sequence' has a descriptive schema entry including accepted inputs and length limits. The tool description adds no additional meaning beyond what the schema already provides, so 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.

  Purpose5/5

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

  The description uses a specific verb ('Summarize') with a clear resource and names three concrete outputs: composition, GC uncertainty, and GC skew. This distinguishes it from siblings like reverse_complement or translate_sequence, which perform transformations rather than summary statistics.

  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 explicit guidance on when to use this tool versus the sibling tools. The purpose implies it is for sequence summary statistics rather than transformations or motif scanning, but no when-to-use or when-not-to-use conditions are stated, leaving the agent to infer selection criteria.

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

• computase_translate_sequenceA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds some behavioral context by restricting translation to complete codons and allowing a selectable genetic-code table, but it leaves undefined edge behaviors like partial trailing codons or stop-codon outcomes, which are only implied by the schema.

  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 a single concise sentence with no filler. It front-loads the action ('Translate complete codons') and includes the key qualifier ('selected NCBI genetic code'), making it appropriately sized for a straightforward operation.

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

  Completeness3/5

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

  The rich input schema, output schema, and annotations carry most of the operational details, making the description adequate for invoking the tool. However, it is slightly incomplete because it does not position the tool against the related ORF-enumeration sibling or clarify partial-codon handling.

  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 description coverage is 100%, so sequence, table_id, and stop_handling are already fully documented. The description adds little beyond restating the genetic-code selection, so the schema-based baseline of 3 is appropriate.

  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 names a specific verb ('Translate') and resource ('complete codons'), with a meaningful qualifier ('selected NCBI genetic code'). This clearly distinguishes the tool from siblings such as reverse_complement or scan_motif, and 'complete codons' helps separate it from ORF enumeration.

  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 implies the intended use—translating a nucleotide sequence with a chosen genetic code—but it does not explicitly say when to choose this tool over computase_enumerate_orfs or any other sibling. There is no when-not-to-use guidance or mention of alternatives.

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

• computase_scan_motifA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds the strand-orientation behavior but does not disclose details like match truncation, overlapping behavior, or edge cases; these are left to the schema and 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.

  Conciseness5/5

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

  A single, front-loaded sentence with no filler. Every word earns its place, and the core action and scope are presented clearly.

  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, full parameter documentation, and safety annotations, the description is mostly sufficient. The only gap is the lack of explicit guidance about when to choose this tool over siblings, which is a minor omission.

  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 description coverage is 100%, so the schema fully documents all five parameters. The description mentions motif and strands but adds no semantic value beyond what the parameter descriptions already provide.

  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 names a specific action ('Scan'), a specific input type ('IUPAC motif'), and a clear scope ('forward, reverse, or both strands'). This clearly distinguishes it from sibling tools like reverse-complementing, translating, or summarizing sequences.

  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: an agent can infer this tool is for finding motif occurrences rather than for sequence transformation or summarization. However, there is no explicit when-to-use/when-not-to-use guidance or named alternatives.

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

• computase_reverse_complementA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that IUPAC codes are handled and both DNA and RNA are supported, but it does not disclose edge-case behavior such as FASTA header handling or output formatting. No contradiction with annotations exists.

  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 a single, front-loaded sentence with no filler. Every phrase contributes meaning: 'Compute,' 'IUPAC-aware,' 'DNA or RNA,' and 'reverse complement.'

  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 single-parameter, schema-backed, annotation-covered read-only transformation with an output schema, the description is sufficient. An agent has everything needed to invoke it correctly: input type, molecule scope, alphabet handling, and safety profile are all covered.

  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 description coverage is 100%, and the schema already documents the accepted formats, IUPAC support, and the 5,000,000-nucleotide cap. The tool description adds only that the input is DNA or RNA, which is marginal beyond the schema's 'nucleotide sequence' wording.

  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 states the exact operation ('Compute'), the target resource ('reverse complement'), and the scope ('DNA or RNA', 'IUPAC-aware'). This clearly distinguishes it from the sibling tools (summarize, translate, enumerate ORFs, scan motif), so an agent can immediately identify the right tool.

  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?

  There is no explicit guidance about when to use this tool versus the sibling tools, nor any exclusions. However, the operation is so specific that the intended usage is strongly implied: use it whenever a DNA or RNA reverse complement is needed.

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

• computase_enumerate_orfsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by specifying that ORFs are 'bounded' and that enumeration covers 'all six reading frames,' going beyond what annotations alone convey.

  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 a single, efficient sentence that leads with the action and resource, then adds the critical six-frame scope. There is zero redundant wording and every word contributes to understanding the tool's purpose.

  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?

  The tool has a rich input schema with full parameter documentation and an output schema, so the one-sentence description is sufficient for selection and basic invocation. It does not explain the exact meaning of 'bounded,' but the schema's require_stop, max_results, and min_length_nt parameters clarify that concept.

  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 description coverage is 100%, so each of the 7 parameters is already well documented with types, defaults, and constraints. The description adds no parameter-specific meaning, but it does not need to because the schema carries that burden.

  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 uses a specific verb ('Enumerate') and a specific resource ('bounded candidate ORFs'), and adds the important scope detail 'across all six reading frames.' This clearly distinguishes the tool from siblings like translate_sequence or scan_motif, which perform different biological analyses.

  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 operational context: if the task is to enumerate candidate ORFs in all six reading frames, this is the tool to use. It does not explicitly list exclusions or alternatives, but the sibling names are distinct enough that an agent can infer when this tool is appropriate.

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