Server Quality Checklist

Tool Scores

• branch_hygieneA
  4.3/5.0
  Behavior4/5

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

  Annotations already set readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it's 'Pure local git; no network' and that 'The default branch itself is excluded from the list.' It also outlines the return structure. 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?

  Four sentences with no wasted words. The first sentence immediately conveys read-only nature and the key fields. Return format is given. Every sentence serves a purpose.

  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?

  Despite having 3 optional params and an output schema (implied by the return structure described), the description covers the key behavioral aspects: what it returns, default branch exclusion, network independence, and the stale flag logic. No gaps for an agent to invoke correctly.

  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 the schema already documents all three parameters. The description does not add significant extra meaning beyond what is in the schema descriptions (e.g., default for stale_days). 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?

  Description clearly states the tool provides an inventory of branches with ahead/behind counts, last commit date, author, merged status, and stale flag. It explicitly says 'Use it to find unmerged, abandoned branches,' which is a specific use case. The name 'branch_hygiene' is metaphorical but the description makes it concrete. Sibling tools like co_change or commit_context focus on different aspects, so this tool is well-differentiated.

  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?

  Description gives explicit guidance: 'Use it to find unmerged, abandoned branches.' It also states it's read-only and pure local git with no network. It does not explicitly mention when not to use or provide alternatives, but the context is clear enough for an agent to decide.

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

• co_changeA
  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 significant behavioral context: read-only, mines commits, cost O(window × files-per-commit), and parameter effects. 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.

  Conciseness4/5

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

  The description is concise given the complexity, with a front-loaded summary of purpose. Every sentence adds value, but it could be slightly tighter.

  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?

  The description fully covers what the tool does, how it works, algorithm details, return values (co-occurrence count and ratio), performance cost, and parameter constraints. With an output schema present, it is 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 coverage is 100% with descriptions. The description adds meaning by explaining how parameters (window, threshold, limit) affect the algorithm and providing default values contextually.

  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 finds files that historically change together with the input file, using commits and co-occurrence. It explicitly distinguishes from sibling tools by focusing on co-change analysis.

  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 a use case ('if I edit X, what else should I check?') and notes it's local log mining with no network. It could explicitly mention when not to use, but the context is clear.

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

• recent_workA
  4.4/5.0
  Behavior4/5

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

  The description reinforces annotations with 'Read-only' and adds behavioral context like 'Pure local git; no network', which goes beyond the annotations. It also describes the output structure. No contradictions 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 two sentences: the first succinctly defines purpose and scope, the second details the return format. Every word contributes meaningful information, no fluff or repetition.

  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's moderate complexity and the presence of an output schema in the description, the description covers defaults, return type, and key constraints. Minor omissions like the exact git command used are not critical for an AI agent.

  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%, but the description adds valuable default behavior information (e.g., author defaults to repo's user.name, since defaults to 7 days ago). This enriches the agent's understanding beyond the raw 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's a read-only standup/changelog helper that shows one author's commits in a time window with file changes and insertion/deletion totals. This distinctively sets it apart from sibling tools like 'branch_hygiene' or 'co_change' by focusing on individual author activity.

  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 scenarios (standup, changelog) and mentions defaults, but does not explicitly state when to avoid using it or compare it to sibling tools like 'who_touched' or 'commit_context'. However, the context is clear enough for an AI agent to infer appropriate use.

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

• commit_contextA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate read-only and idempotent. The description adds crucial context: it may make an outbound GitHub API call for PR enrichment and errors if SHA doesn't resolve. This goes beyond the annotations, though it doesn't detail the response format or all 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?

  Three sentences, front-loaded with the read-only nature, and efficiently enumerates returned data and special behaviors. Every sentence provides necessary information without redundancy.

  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 presence of an output schema (unseen but flagged), the description covers everything needed: what the tool returns, when it errors, and potential external call. It is fully adequate for an agent to invoke the tool correctly.

  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%, so baseline is 3. The description adds value by explaining error behavior for the SHA parameter and implying the cwd default. It doesn't repeat schema but provides behavioral context that aids parameter 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 it retrieves detailed information about a single commit (subject, body, changed files, PR, issues). This verb+resource approach is specific and distinct from sibling tools like 'branch_hygiene' or 'recent_work', which focus on different aspects.

  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 for getting a comprehensive commit summary but does not explicitly differentiate from siblings or state when not to use. It does mention an important behavioral constraint (external GitHub call) and error condition, providing some guidance.

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

• introducing_prA
  4.6/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description details the internal process: git blame, reading merge-commit messages, fallback to GitHub REST API, rate limits, and null result scenarios. This fully discloses behavioral traits.

  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 comprehensive but somewhat lengthy. It is well-structured with the key point 'Read-only' up front, and each sentence adds value. Could be slightly more concise but still effective.

  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 complexity (two-step process with fallback) and that an output schema exists, the description covers all necessary behavioral and usage aspects without missing critical details.

  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 100% schema coverage, baseline is 3. The description adds meaning: explains that `file` and `line` are used together, `commit` is an alternative, and `cwd` defaults. It provides context beyond the schema definitions.

  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 finds the PR that introduced a line or commit. It specifies exact inputs (line/commit) and distinguishes from sibling tools like 'co_change' or 'branch_hygiene' by focusing on PR introduction.

  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 (when you need the introducing PR for a line or commit) and mentions token-dependent fallback behavior. However, it does not explicitly state when not to use or compare to siblings.

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

• who_touchedA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint and idempotentHint. Description adds cost scaling and error conditions (non-git repo, untracked file), going 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?

  Concise and well-structured: front-loaded with purpose and output, then usage details. Every sentence adds information with no redundancy.

  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?

  Covers purpose, output, parameter usage, error conditions, and performance. Output schema exists so return values are documented separately. Complete for the tool's complexity.

  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. Description adds meaning: scoping with line_start/line_end, and clarifies that 'function' is cosmetic. This adds value beyond 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 the tool reads code ownership via git blame, aggregated by author, and lists specific outputs (line count, commit count, primary owner). This distinguishes it from siblings like 'commit_context' or 'co_change'.

  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 clear guidance on when to use line_start/line_end for scoping, error conditions, and performance characteristics. Does not explicitly mention alternatives but context is strong.

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