Server Quality Checklist

Tool Scores

• validate_trackC
  2.2/5.0
  Behavior2/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 lists validation items but does not state if the tool is read-only, has side effects, requires specific permissions, or what the output contains. The behavior is implied as validation but 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.

  Conciseness3/5

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

  The description is very short and uses a comma-separated list. While concise, it is cryptic and lacks sentence structure. It could be more efficient by explaining the tool's purpose in a phrase rather than a list.

  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 the tool has 4 parameters with 0% schema coverage, an output schema exists but is not described. The description does not cover the return value or behavior. It is incomplete for effective tool selection and invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any parameters. It does not mention track_path, production, report_path, or trajectory_path. The agent receives no help understanding parameter meaning beyond the schema names.

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

  Purpose3/5

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

  The description lists multiple validation aspects (schema, chronology, joints, review state, event lock) but does not clearly state the tool's primary function or scope. The verb 'validate' is present but the resource 'track' is implicit. It lacks distinction from sibling tools like inspect_track, which may also validate.

  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. There are no exclusions, prerequisites, or context indicating appropriate scenarios. The description does not help an agent decide between validate_track and sibling tools.

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

• compare_motionC
  2.4/5.0
  Behavior2/5

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

  No annotations provided, so the description must fully disclose behavior. It only states a compare operation without mentioning whether it is read-only, destructive, permissions required, or any 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.

  Conciseness3/5

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

  The description is a single sentence, which is concise, but it under-specifies the tool's behavior and parameters, making it less useful.

  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?

  With 4 parameters, 0% schema coverage, and no output schema details, the description is incomplete. It does not explain the return format or how results are presented.

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

  Parameters1/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 explain parameters. It does not mention source_track_path, candidate_track_path, or optional parameters. No parameter semantics are conveyed.

  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 'compare' and specifies the resources (hips, feet, wrists, hands) from candidate and source motion. It distinguishes from siblings like export_artifacts or track_motion, though it could be more specific about the nature of the comparison.

  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. Context signals show sibling tools are related but distinct, but the description offers no selection criteria.

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

• export_artifactsC
  2.4/5.0
  Behavior2/5

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

  Without annotations, the description must disclose behavioral traits. It hints at 'verify' (read-only check) and 'export' (write action), but does not clarify side effects, required permissions, or whether the manifest is modified. The description is insufficient for safe invocation.

  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 with no fluff, making it concise. However, it could be slightly more structured or informative without losing brevity.

  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?

  The description is too brief given the tool's complexity (2 parameters, output schema present). It omits context like what kind of artifacts, how verification works, and what the bundle contains. The presence of an output schema reduces the need to explain returns, but other gaps remain.

  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 description mentions neither job_path nor destination_path. With 0% schema description coverage, it fails to explain the parameters' roles or provide constraints beyond their names.

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

  Purpose3/5

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

  The description says 'verify the immutable manifest and export a deterministic review bundle,' which indicates a verification and export action, but the exact nature of the manifest and bundle is vague. It does not distinguish the tool from sibling tools like track_motion or validate_track.

  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 is provided on when to use this tool versus alternatives. There are no prerequisites, exclusions, or usage context mentioned.

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

• inspect_trackC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description should disclose behavioral traits like read-only nature or side effects, but it only states the output type (summary). It fails to mention whether the tool modifies data or requires special permissions.

  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 focused sentence that front-loads the action and lists key outputs. No extraneous words.

  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?

  Despite having an output schema, the description omits the parameter role and behavioral context. It lists summary topics but doesn't anchor them to the parameter's source (track). Adequate but not fully informative.

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

  Parameters1/5

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

  The single parameter (track_path) has no description in the schema (0% coverage) and the tool description does not explain its meaning or format. The agent cannot determine what constitutes a valid track_path.

  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 clearly states the tool summarizes specific aspects (coverage gaps, uncertainty, events, review state, gate results), distinguishing it from sibling tools like track_motion and validate_track which have different purposes.

  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 is provided on when to use this tool versus alternatives. It does not mention prerequisites or context, leaving the agent to infer usage from the name alone.

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

• track_motionA
  3.6/5.0
  Behavior3/5

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

  The description discloses that inference ends in tracked/unreviewed and never implies motion acceptance, adding behavioral context. However, it lacks details on side effects (e.g., artifact emission specifics) and error handling, which would be needed 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, using three short sentences to convey key points. It is front-loaded with the main action and constraints, but could be slightly more structured.

  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?

  Despite having an output schema, the description does not explain what the emitted review artifacts are or how to interpret results. It also omits prerequisites like workspace access and fallback behaviors, leaving significant gaps for an 8-parameter tool.

  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?

  With 0% schema description coverage, the description must compensate but only explains the crop fields grouping. It does not clarify the meaning of model_preset, minimum_score, device, or source_path beyond the required status.

  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 tracks every source frame with RTMW whole-body landmarks and emits review artifacts. It distinguishes itself from siblings like export_artifacts and validate_track by focusing on the tracking process.

  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 provides explicit constraints: source must be in GROUNDED_MOTION_WORKSPACE, crop fields must be all-or-none, and inference ends in tracked/unreviewed without implying acceptance. It offers clear context but does not compare with sibling tools.

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