Server Quality Checklist

Tool Scores

• resolve_biotech_spatial_intentC
  2.9/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the full burden. It discloses that the output is 'immutable,' implying idempotent behavior and no side effects. It also specifies SI units (meters). However, it does not mention authorization needs, rate limits, or what happens with invalid inputs, leaving some behavioral aspects undisclosed.

  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 a single sentence that is front-loaded with the action and key details (immutable, SI units). It is concise and avoids redundancy. However, it is so brief that it sacrifices completeness, which slightly reduces conciseness effectiveness.

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

  Completeness2/5

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

  Given two parameters with no schema descriptions and a likely transformation function, the description is too minimal. It does not explain the conversion formula, value ranges, or the meaning of the output metrics (even though an output schema exists). An agent would need to guess the tool's inner logic. For a translation tool, more context is expected.

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

  Parameters2/5

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

  The schema has 0% description coverage, and the tool description adds no explanation for the parameters 'concentration_input' and 'plate_scale_mm.' Their names hint at meaning, but the description only references 'assay parameters' generically. The agent gets no additional semantic information beyond the parameter names themselves.

  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 uses the verb 'translates' and specifies the result is 'immutable spatial metrics using SI base units (meters).' This clearly indicates a transformation of inputs to outputs in defined units, distinguishing it from the sibling tool 'fetch_genomic_data' which retrieves data. However, 'assay parameters' is vague; it doesn't explicitly state that the tool computes something like spatial resolution or distance.

  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?

  No usage guidance is provided. The description does not state when to use this tool versus any alternatives, nor does it mention prerequisites, such as required experimental conditions or data formats. While the sibling tool is different, explicit context for selection is missing.

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

• calculate_dna_melting_tempB
  3.3/5.0
  Behavior2/5

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

  No annotations exist, so description carries full burden. It mentions outputs but does not disclose behavioral traits like formula assumptions, input validation, error handling, or limits on sequence length/composition.

  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?

  Single sentence efficiently communicates purpose and practical outcome. No wasted words, but could be slightly expanded for key details.

  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?

  For a simple one-parameter tool with output schema, the description is adequate but could mention typical formula used (e.g., nearest-neighbor) or salt dependency to be fully informative.

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

  Parameters2/5

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

  Only one parameter, dna_sequence, with 0% schema description coverage. The description simply says 'DNA sequence' without adding format, allowed characters, case sensitivity, or length constraints beyond the parameter name.

  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 calculates GC-content and melting temperature from a DNA sequence, and explicitly links to determining heating plate temperature. Distinguishes from sibling tools which focus on pipetting, genomic data fetching, plate coordinates, and spatial intent.

  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?

  Implies usage for DNA melting temperature calculation, but does not provide explicit guidance on when to use versus alternatives, nor any exclusions or prerequisites.

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

• translate_emg_to_actuationA
  3.5/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 full burden. It mentions 'safe, deterministic' outputs, which adds behavioral context, but lacks details on calibration, error handling, or edge cases.

  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?

  Single sentence, no redundant words, front-loaded with action and resource.

  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 tool is simple with 2 parameters and an output schema, but missing usage guidelines and full parameter semantics; adequate but not comprehensive.

  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 0%, so description adds value by explaining emg_microvolts and the output (joint angles, velocity profiles). However, joint_id parameter is not explained beyond its default.

  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 translates EMG signals into joint angles and velocity profiles for prosthetic actuation, using specific verbs and resources, and distinguishes it from unrelated sibling tools.

  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?

  No guidance on when to use this tool versus alternatives, no prerequisites or exclusions provided; the description only implies usage for prosthetic actuation.

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

• fetch_genomic_dataA
  3.6/5.0
  Behavior3/5

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

  Describes caching and API fallback behavior, which is useful. However, lacks details on side effects, error handling, or rate limits. No annotations to compensate.

  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?

  Three sentences, each adding value. The main action is front-loaded. Could be slightly more compact but no waste.

  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 output schema present and one parameter, description explains caching mechanism well. Minor gap: no mention of error responses or data format.

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

  Parameters2/5

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

  Schema has 0% description coverage for 'gene_id'. Description mentions it queries by gene_id but adds no format or validation details.

  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?

  Description clearly states verb ('queries') and resource ('sequence parameters'), with additional caching behavior. Distinguishes from siblings, which are unrelated.

  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?

  Implies use for genomic data fetching but provides no explicit when-to-use, when-not-to-use, or alternative tool guidance.

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

• map_plate_coordinateA
  3.7/5.0
  Behavior3/5

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

  No annotations exist, so the description must carry the burden. It mentions the transformation and standards but does not disclose edge cases (e.g., invalid well IDs) or side effects. For a computational mapping, this is 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?

  Single sentence with no wasted words. Every part adds value: verb, resource, examples, standards. Perfectly concise.

  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 doesn't need to detail return values. It covers the main purpose, standards, and units. However, it lacks details on supported plate formats and error behavior, which would make it more complete.

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

  Parameters2/5

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

  Schema descriptions are absent (0% coverage). The description implicitly defines 'well_id' via examples but does not explain 'plate_format' or its role. With no schema help, the description fails to fully clarify parameter meanings.

  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 verb 'translates' and the resource 'well IDs to Cartesian offsets', with specific examples ('A1' to 'H12') and standards (SLAS/SBS). It distinguishes from unrelated sibling tools.

  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?

  No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for coordinate conversion but lacks exclusions or alternatives. Siblings are unrelated, so no confusion, but still falls short of a 4.

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

• calculate_pipetting_speedA
  4.5/5.0
  Behavior4/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 discloses the tool's behavior: calculating safe settings to prevent splashing and ensure precision. As a pure computation, it is implicitly non-destructive, but this is not stated explicitly. However, the described behavior is accurate and sufficient.

  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 redundant words. Every part serves a purpose: verb, output, inputs, and goal. It is optimally concise.

  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 tool's simplicity (two numeric inputs, calculation), the description covers its purpose and key inputs. An output schema exists (not shown), so return value details are handled there. No missing context for effective use.

  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?

  With 0% schema description coverage, the description must compensate. It clarifies that 'fluid viscosity' is in cP, which is not evident from the schema alone. The other parameter's unit (uL) is implied by its name. While minimal, this addition provides meaningful context 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 uses a specific verb ('Calculates') and clearly identifies the tool's output (optimal safe feedrate and delay times) and input basis (fluid viscosity and target volume). It also states the goal (ensure precise volumes, prevent splashing). This distinguishes it from the unrelated sibling tools.

  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 implies usage when pipetting speed needs optimization for specific fluid viscosity and target volume. No explicit when-not or alternative tools are needed since siblings are unrelated, but the context of use is clear.

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