Server Quality Checklist

Tool Scores

• argot.get_voice_contextA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds that it is read-only and requires a fitted repository, providing context beyond annotations without contradiction.

  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 plus a note, front-loading the main purpose and efficiently conveying critical information without extraneous content.

  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 simple parameter set (2 params, no output schema) and rich annotations, the description adequately explains the tool's behavior and return values. It could elaborate on 'active replacement guidance,' but is largely complete.

  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 both parameters have descriptions. The tool description mentions that file_path's extension selects the language, adding slight context, but overall doesn't significantly extend beyond the schema's parameter descriptions.

  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 retrieves repository vocabulary relevant to a file (typical callees, imports, replacement guidance) and distinguishes it from being a code verdict or changeset check, differentiating it from sibling tools like argot.check_changeset.

  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 indicates use 'before writing' and clarifies it is 'generation context, not a verdict about code and not a changeset check,' implying appropriate usage scenarios. It also notes it requires a fitted repository, though explicit when-not-to-use and alternatives are not provided.

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

• argot.get_fit_statusA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool only diagnoses and never fits or writes, which is consistent. It also mentions 'structured reasons and next_action' in output, but beyond that, no new behavioral traits are disclosed.

  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, front-loaded with key purpose, no fluff. Efficiently covers tool scope, output, and boundaries.

  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 0 parameters, comprehensive annotations, and no output schema, the description fully explains what the tool does and its diagnostic role. It mentions output format and exclusion of mutations, which is sufficient for this simple 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?

  The tool has 0 parameters with 100% schema coverage (empty). The description adds value by describing what the tool returns (structured reasons, next_action), which is unnecessary but helpful. Baseline for 0 params is 4.

  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 gets 'repository readiness' and lists specific aspects (fit suitability, completeness, configuration compatibility, adaptive refresh recommendation). It also explicitly says what it does not do ('diagnoses setup and maintenance only; it never fits or writes'), distinguishing it from sibling tools like check_changeset or check_hunk.

  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 says to use 'before using learned tools,' which provides clear context. It also states it 'diagnoses setup and maintenance only,' implying when not to use for fitting/writing. However, no explicit alternatives are mentioned.

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

• argot.list_conventionsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it requires a fitted repository, which is valuable behavioral context beyond 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?

  Two concise sentences with no wasted words. The key information is front-loaded.

  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 zero parameters and no output schema, the description adequately covers the tool's purpose, usage, and requirements. It could mention what the output looks like, but is complete enough.

  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?

  There are zero parameters, so the description cannot add meaning beyond the input schema. Baseline 4 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 clearly states the verb 'List' and the resource 'conventions learned from the repository', specifying the types of conventions (vocabulary, concentrations, migrations). It differentiates from siblings which focus on checking changes.

  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?

  It tells the agent when to use the tool: 'discover candidate team conventions or understand where code belongs'. It also explicitly states what it does not do: 'does not evaluate a change'. This provides clear guidance without naming alternatives, but the context is sufficient.

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

• argot.check_changesetA
  4.5/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral details: 'it does not fit, mute, edit files, or update the last-check cache; requires a fitted repository.' This goes beyond annotations and clarifies side effects and prerequisites.

  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 sentences plus a brief note, all front-loaded with the most important information. Every sentence adds value: purpose, usage context, return type, and behavioral constraints. No wasted or redundant words.

  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?

  With 5 parameters all documented in schema and no output schema, the description covers the return value ('stable check JSON, including findings, evidence, suppressions, and result counts') and a critical prerequisite ('requires a fitted repository'). This is complete for an agent to understand input/output and constraints.

  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 parameter already has a description. The tool description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema does the work.

  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 runs the complete detector pipeline over one changeset and returns check JSON. The verb 'check' is specific, and the phrase 'complete configured detector pipeline' and reference to CLI distinguish it from sibling tools like check_hunk.

  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 explicitly says 'Use this after editing when you need the same voice, semantic, architecture, integrity, and custom-rule findings as the CLI.' It also clarifies what it does not do (fit, mute, edit files, update cache), providing when-not-to-use guidance. It does not name alternatives directly but the context and tone imply it's for full pipeline checks.

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

• argot.check_hunkA
  4.6/5.0
  Behavior5/5

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

  Adds behavioral context beyond annotations: return fields, exclusions, prerequisite (fitted repository). 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?

  Three sentences: purpose, usage, output/exclusions. No wasted words, front-loaded with key information.

  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?

  Describes returns adequately given no output schema. Mentions limitations and prerequisites. Slightly lacking in return type detail, but sufficient for a simple read-only 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% with detailed descriptions. The tool description does not add new info about parameters beyond what schema provides, so baseline 3.

  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 action (score), resource (code hunk), and model (fast fitted voice). Distinguishes from sibling check_changeset by noting preference for real changes.

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

  Usage Guidelines5/5

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

  Explicitly says when to use: 'while drafting or for an isolated snippet when no Git changeset exists.' Also states exclusions (no semantic/integrity rules) and alternative (check_changeset).

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

• argot.explain_hunkA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'requires a fitted repository' and 'untruncated structured evidence', which provides useful context beyond annotations. No contradiction.

  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 main sentences plus one supplementary. Front-loaded with key purpose and usage. Every sentence is essential and informative. No redundancy.

  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?

  Covers purpose, parameters, behavior (read-only, requires fitted repo), and usage context. Lacks explicit description of return values, but the description mentions 'untruncated structured evidence, including surprising identifiers and attestation counts' which gives adequate expectation for a tool with no output schema.

  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 100%, but description adds valuable context: explains that file_path extension selects language model, file_source is optional to improve accuracy, and hunk_content should be only the changed lines. This adds meaning beyond what the schema descriptions 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?

  Description explicitly states the verb 'explain', the resource 'hunk-level voice result', and what it produces ('untruncated structured evidence, including surprising identifiers and attestation counts'). It distinguishes from siblings by specifying it's a follow-up when check_hunk flags or nearly flags a snippet, and covers the fitted voice model only.

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

  Usage Guidelines5/5

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

  Clear guidance: 'Use as a follow-up when check_hunk flags or nearly flags a snippet; do not use it as a second independent check.' Also states 'It covers the fitted voice model only' and 'Read-only; requires a fitted repository.' Provides when to use and when not to use, with prerequisite.

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