Server Quality Checklist

Tool Scores

• publish_merge_requestB
  3.4/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 the full burden. It discloses that the platform is auto-detected from the git remote and that auth tokens come from specific env vars, which is useful behavioral context. However, it doesn't disclose side effects (opening a PR is externally visible/mutating), error behavior when tokens are missing, or what happens when base differs from current branch.

  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 three sentences, each earning its place: what it does, how platform detection works, and auth requirements. It's front-loaded with the primary purpose. No redundant text.

  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 tool with 5 parameters, full schema coverage, and no output schema, the description covers the essentials reasonably well. However, it lacks guidance on behavior when auth fails, what the function returns (PR/MR URL?), and how the base default is determined, which could trip up an agent. The prepare_merge_request sibling suggests a pairing workflow that isn't explicitly connected.

  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 structured schema already documents all 5 parameters (cwd, base, body, draft, title). The description adds the context that title and body are the content being published, but doesn't add format/content guidance beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.

  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 action (publish a PR/MR), the resource (title and body), and distinguishes between GitHub and GitLab terminology. It doesn't explicitly contrast with sibling tools like prepare_merge_request, but the verb 'publish' versus 'prepare' offers implicit differentiation. The platform auto-detection detail adds useful specificity.

  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 notes that platform is auto-detected and auth tokens come from env vars, which conveys prerequisites but not explicit when-to-use or when-not-to-use guidance. It doesn't explain when to prefer this over prepare_merge_request, though 'publish' vs 'prepare' implies a workflow ordering. No explicit alternatives are named.

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

• get_repo_infoA
  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 the burden. It states the tool is read-only in nature (getting info) and enumerates return fields, which is helpful. However, it doesn't disclose what happens if the directory is not inside a git repo (error behavior), or whether it requires network access to determine the platform.

  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, zero waste. It front-loads the purpose and enumerates the specific information returned. Nothing extraneous.

  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 read-only info tool with one parameter, no annotations, and no output schema, the description is largely adequate. It lists the returned data points. However, without an output schema or error-behavior notes, the agent gets no return-format details — a minor gap for an otherwise low-complexity 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% for the single cwd parameter, which is well-described in the schema ('must be inside a git repository'). The description doesn't add semantic meaning beyond the schema, but with only one parameter and full coverage, the baseline of 3 is appropriate.

  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?

  Clear verb+resource ('Get information about the current git repository') with explicit enumerated attributes (current branch, default branch, remote URL, detected platform). Distinguishes from siblings reasonably — list_templates, prepare/publish_merge_request are clearly different operations, though it doesn't explicitly contrast with them.

  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 context (must be inside a git repository, working directory) is implied through the cwd parameter description. There's no explicit when-to-use vs alternatives, but the sibling tools are different enough (templates, merge requests) that the usage is reasonably clear from purpose alone.

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

• list_templatesA
  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 the full burden. It states it's a listing operation (implies non-destructive read) but doesn't disclose whether templates are recursive or just at root level, what happens if no templates exist, or path conventions used. With no annotations, a read operation is reasonably implied by 'List', which carries moderate weight, but richer behavioral detail would strengthen it.

  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?

  A single sentence that is efficient and front-loads the core purpose ('List all available PR/MR templates'). The only minor gap is that it doesn't add behavioral notes within the same concise structure, but for the size, it's appropriately lean with zero wasted 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?

  This is a simple read/list tool with a single parameter and no output schema. The description adequately covers the core purpose. Without an output schema, it could usefully hint at the return shape (e.g., template names/file paths), but for a list tool the purpose and scope are reasonably communicated. Does not describe edge cases (no templates found) or template discovery nuances.

  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 the single cwd parameter already documented as 'Working directory — must be inside a git repository'. The description adds nothing about the parameter, but since coverage is complete and the schema description is adequate, the baseline of 3 applies. I rate slightly higher (4) because the schema's own parameter description is notably self-sufficient and precise, covering the git-repo prerequisite that would otherwise belong in the tool description.

  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 a specific verb+resource ('List all available Pull Request / Merge Request templates') and clearly states the scope is limited to what's 'found in the repository'. It distinguishes from siblings like prepare_merge_request and publish_merge_request, which are action verbs on the same domain; listing is clearly separate. A slight deduction because it doesn't explicitly contrast with get_repo_info, though the resource type is different enough.

  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 a read-only overview use case (before preparing or publishing an MR/PR). However, it doesn't explicitly state when to use this vs alternatives, nor does it provide exclusions like 'use this before prepare_merge_request' or mention a preferred alternative for other listing needs. Context is inferred from 'found in the repository' but not made explicit.

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

• prepare_merge_requestA
  4/5.0
  Behavior3/5

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

  Annotations are absent, so the description carries the full burden. It discloses that returned data is intended for LLM use in composing PR/MR content, which is helpful context about the tool's role. However, it doesn't disclose whether the tool performs any side effects (like creating local state, modifying files, or network calls), the format of the returned data, or whether it can fail on certain repo states (e.g., dirty working tree, no commits).

  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 well-structured with a bulleted list followed by concise context about intended use. Every sentence earns its place — the purpose list is complete, and the two follow-up sentences clarify the LLM's expected downstream behavior. No fluff or 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?

  The tool is moderately complex (gathers multiple data types) and has no output schema and no annotations, yet the description clearly explains what data is collected and how the LLM should use it. It could add detail about return format or potential failure modes, but the described purpose is sufficiently complete for an agent to select and invoke it 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 description coverage is 100%, with both cwd and base well-described in the schema ('must be inside a git repository', 'defaults to the repository's default branch'). The description itself adds limited parameter-level detail beyond this, but the high schema coverage means the baseline 3 applies. The description doesn't add behavioral context about parameter usage 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 clear verb ('Gather') with a specific resource (data for PR/MR creation) and enumerates exactly what's collected (diff, commit log, changed files, template, repo metadata). It clearly distinguishes itself from siblings like publish_merge_request (creation vs gathering) and list_templates (broader template listing vs repo-specific template retrieval).

  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 states it's used before composing a PR/MR title and body, and explains the downstream behavior (fill template vs generate content). It clearly positions itself as a preparatory step for the LLM. However, it doesn't explicitly name alternatives or say when NOT to use it, though sibling differentiation is implicit.

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