Server Quality Checklist

Tool Scores

• post_delete_merge_requestB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior. It only states 'Delete a merge request' and 'Returns: Confirmation message', omitting critical side effects like irreversibility, permission needs, or impact on related data.

  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 extremely concise and well-structured, with clear Args/Returns sections and no unnecessary words. Every sentence adds value.

  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 an output schema existing, the description lacks important context for a destructive operation. It does not differentiate delete from close/reopen, nor does it mention whether the action is reversible or requires special permissions.

  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 description compensates for 0% schema coverage by explaining both parameters with concrete examples: project key (e.g., 'ij') and review_id (e.g., '194108' or internal ID). This adds 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 states 'Delete a merge request.' with a specific verb and resource, clearly distinguishing it from sibling tools like get_merge_request, put_merge_request, and post_close_merge_request.

  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 such as post_close_merge_request. The description gives no context, prerequisites, or exclusions.

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

• post_cancel_patronus_runA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden. It does not disclose side effects (e.g., whether the run is irrevocably terminated), auth requirements, or what happens to run data. It only states the action and that a confirmation message is returned.

  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 very concise and well-structured, with a one-sentence summary followed by Args and Returns sections. There is no redundant or unnecessary content.

  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 description covers the basic purpose, parameter, and return value, and an output schema exists. However, it lacks behavioral depth such as side effects and required run state, making it minimally sufficient but with clear gaps.

  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 schema provides no description for run_id (0% coverage), but the description adds 'Patronus run UUID', clarifying the format and purpose. This compensates for the schema's lack of detail.

  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 action ('Cancel') and the resource ('Patronus run'), with a specific scope ('dry run or safe merge'). It is distinguishable from sibling tools like get_patronus_run and put_patronus_dry_run.

  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 phrase 'running Patronus run' implies the tool is for active runs, but there is no explicit guidance on when to use it vs. alternatives, nor any exclusions or prerequisites. The usage is largely implied rather than stated.

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

• get_merge_request_timelineA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the return format (chronological markdown timeline, day sections, threaded replies) but does not explicitly state that it is read-only or mention any side effects. The 'get' name implies non-mutating behavior, but the description itself does not confirm safety characteristics.

  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 and appropriately sized, with a clear header, a brief return description, and an organized Args/Returns breakdown. Each section provides necessary information without unnecessary verbosity.

  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, the description is fairly complete: it covers the purpose, parameters, and return value. However, it omits any mention of authentication requirements, rate limits, or possible errors, which would be helpful in the absence of annotations.

  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 input schema has no parameter descriptions (0% coverage), but the description adds examples for project ('ij') and repository ('ultimate') and clarifies that review_id is a 'Review/MR identifier'. This provides meaningful context beyond the bare schema, though it could be more explicit about review_id format.

  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's purpose with a specific verb ('Get') and resource ('the full timeline of a merge request'), and enumerates the contents (comments, dry runs, commits, reviews). This distinguishes it from sibling tools like get_merge_request (presumably just MR details) and get_merge_requests (list).

  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?

  The description does not provide guidance on when to use this tool versus alternatives. It only describes what it does with no exclusions or references to sibling tools, leaving the agent to infer usage from the name.

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

• post_close_merge_requestA
  3.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Returns: Confirmation message' and does not mention side effects, permissions, or whether the close is reversible. Context suggests closing is a mutation, but specifics are lacking.

  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 with a clear Args/Returns structure. It includes examples inline and stays focused, though slightly more formatting (e.g., bullet lists) could improve readability.

  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?

  For a simple close operation with two required parameters and an output schema, the description covers parameters, return type, and basic behavior. It does not specify prerequisites like permissions or idempotency, but overall it is adequate given the tool's simplicity and sibling context.

  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?

  The schema has 0% coverage with no property descriptions. The description compensates by explaining both parameters: project with an example 'ij' and review_id as 'MR number (e.g., "194108") or internal ID'. This provides clear meaning 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 the action 'Close a merge request' with a specific verb and resource. It distinguishes from siblings like post_reopen_merge_request and post_delete_merge_request by focusing on the close operation.

  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 usage: use when you want to close a merge request. It does not explicitly provide when-not-to-use guidance or mention alternatives among siblings, but the intent is clear from the title and description.

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

• patch_merge_requestA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and discloses key behaviors: omit-to-leave-unchanged, empty-string-to-clear, at least one field required, and returns YAML. This goes beyond the schema, though it does not cover permissions or 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.

  Conciseness5/5

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

  The description is well-structured and front-loaded: a one-sentence purpose, then concise semantic rules, Args, and Returns. Every sentence earns its place with no redundancy.

  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 description adequately covers update behavior and return format, but omits explanations for the required identifier parameters and does not clarify how to obtain them. Given the presence of an output schema and sibling lookup tools, this is a moderate gap.

  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?

  The description explains title and description semantics clearly, but schema coverage is 0% and the required parameters `project` and `review_id` are not described at all. This leaves a gap for agents trying to identify these parameters.

  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 states 'Edit an existing merge request's title and/or description,' which is a specific verb+resource+fields. It clearly distinguishes from siblings like put_merge_request (full update) and get_merge_request (read) by emphasizing partial update semantics.

  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 clear usage context: use when updating title/description, with explicit instructions on omitting fields and clearing the description. It does not name alternatives or exclusions, but the context is sufficient to guide selection among siblings.

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

• put_merge_requestA
  4.1/5.0
  Behavior3/5

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

  The description discloses the core behavior (create) and the return format (YAML with MR number, title, branches). However, with no annotations, it fails to mention important behavioral aspects like required permissions, side effects, idempotency, or error conditions. It provides minimal behavioral transparency beyond the action itself.

  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 concise and well-structured: a one-line purpose statement, a clean list of args, and a return note. Every line adds value, avoiding irrelevant details or redundancy. The format is easy to parse and front-loaded with the primary action.

  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 description covers the essential aspects: what the tool does, all parameters, and the return format. Given the output schema exists, return details are not elaborated, but the description is largely complete for a straightforward create tool. However, it lacks explicit usage guidance and preconditions, which might be needed in more complex scenarios.

  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?

  The description offers a detailed explanation for every parameter, including a label and an example (e.g., project: 'ij', repository: 'ultimate'). This fully compensates for the schema's lack of descriptions (0% coverage), giving the agent clear guidance on what each argument means and how to format them.

  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's function: 'Create a new merge request.' It lists all relevant arguments and the return type, making it easy to distinguish from siblings like patch_merge_request (update) or get_merge_request (read). The purpose is specific and unambiguous.

  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 this tool is for creating new merge requests, but it does not explicitly contrast with alternatives such as patch_merge_request or post_close_merge_request. No 'when to use' or 'when not to use' guidance is provided, leaving the agent to infer from the verb 'create' and sibling names.

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

• post_reply_to_code_discussionA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the action, notes that Markdown is supported, and explains where to find the channel ID. However, it does not mention side effects (e.g., who gets notified, whether replies can be edited/deleted) or any permission requirements. This is acceptable for a straightforward mutation tool but not deeply transparent.

  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 concise and well-structured: a single sentence stating the core action, a helpful note about finding the channel ID, then an Args list and Returns line. Every sentence provides value, with no redundant or vague language.

  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?

  For a simple reply tool, the description covers the essential elements: purpose, parameter semantics, how to obtain a key identifier, and the return type (confirmation message, with an output schema available). Missing items like error scenarios and explicit alternatives to sibling tools are minor gaps, so this is close to complete but not fully so.

  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 schema provides only names and string types (0% coverage), but the description adds crucial meanings: project is 'Project key', review_id is 'MR number', discussion_channel_id is the 'Channel ID of the code discussion', and text is 'Reply text'. It also clarifies that project/review_id are 'for context only' and that Markdown is supported. This meaningfully compensates for the bare schema, though the phrase 'for context only' could be clearer.

  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 action with a specific verb and resource: 'Reply to an existing code discussion on a merge request.' It uses 'existing' to distinguish from creating a discussion, and the sibling tools (post_code_discussion) reinforce this distinction, making the purpose unambiguous.

  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 clear context on when to use the tool (to reply to an existing discussion) and gives a specific source for the discussion_channel_id (timeline output). However, it does not explicitly mention alternatives or exclusions (e.g., use post_code_discussion to start a new discussion), so it falls just short of full guidance.

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

• get_merge_requestA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. The verb 'Get' implies a read-only operation, and the returns section discloses the output format (YAML containing title, state, author, branches, reviewers). However, it does not mention error handling, rate limits, or authorization requirements.

  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 concise and well-structured with a clear one-line purpose, an Args section, and a Returns section. Every sentence adds value without 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?

  For a simple get operation, the description covers purpose, parameters, and return format. It lacks explicit usage guidance relative to sibling tools, but the output schema exists and the description already explains the returned fields. Overall, it is sufficiently complete for its complexity.

  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?

  The input schema has no descriptions (0% coverage), but the description compensates fully by explaining every parameter with concrete examples: project key ('ij'), repository name ('ultimate'), and review_id (numeric or full review ID). This adds significant meaning beyond the bare 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?

  Clearly states 'Get details of a specific merge request.' Differentiates from siblings like get_merge_requests (list all) and get_merge_request_timeline (timeline) by focusing on a single MR's details.

  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 implicitly indicates use for retrieving a specific MR's details via the presence of review_id, but it does not explicitly discuss when to use this tool versus alternatives like get_merge_requests or get_merge_request_timeline. More explicit sibling comparison would improve clarity.

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

• get_patronus_runsA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full burden for behavioral transparency. It discloses the output format (YAML list) and that runs are dry runs/safe merges, but does not explicitly state read-only behavior, permission needs, rate limits, or any side effects. This leaves some uncertainty for an agent, but the core purpose and return type are conveyed.

  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 concise and well-structured: a brief purpose statement, usage context, follow-up note, and clearly labeled Args/Returns sections. Every sentence contributes value, and the format is easy to parse, making it efficient for an agent.

  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?

  For a simple list tool with two parameters and an output schema, the description is complete. It provides examples for both parameters, states the return type (YAML list), and explains how the results are used with get_patronus_run. No critical information appears missing, given the tool's simplicity.

  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 schema has 0% coverage, so the description compensates by explaining both parameters: project is a project key with example 'ij', and review_id is an MR number with example '194108'. These concrete examples and definitions add substantial meaning beyond the bare schema, though more nuance (e.g., where to find the project key) could improve usefulness.

  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/lists Patronus runs (dry runs / safe merges) for a merge request, using the specific verb 'Find' and identifying the resource. It differentiates from the sibling get_patronus_run by noting each run's ID can be passed to that tool for follow-up queries, establishing distinct scope.

  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 'Use this to discover CI dry runs and safe merge attempts for a merge request,' providing a clear context for usage. It implicitly distinguishes from get_patronus_run by pointing to that tool for individual run details, though it doesn't explicitly state exclusions for cases where a run ID is already known.

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

• post_code_discussionA
  4.3/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 discloses the core behavior (creating a discussion), the anchoring mechanism (revision and line), and that Markdown is supported in the text. However, it does not mention side effects, permissions, or error conditions, which would have improved transparency for a mutation tool.

  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: a one-sentence purpose, followed by a clean bullet list of parameters with examples, and a brief returns statement. Every sentence adds value, and the layout is easy to parse, making it both concise and appropriately detailed for a 7-parameter tool.

  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?

  Despite having no annotations and 7 required parameters, the description covers the tool's purpose, all parameters with examples, and a returns statement. An output schema exists, so detailed return documentation is not required. It is sufficiently complete for an agent to invoke the tool correctly, though edge cases or error handling are not mentioned.

  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 description coverage is 0%, but the description fully compensates by listing each of the 7 parameters with a name and an example (e.g., 'project: Project key (e.g., "ij")', 'revision: Git commit SHA the comment is anchored to'). This gives agents clear semantic meaning beyond the bare schema names.

  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's function with a specific verb and resource: 'Create an inline code discussion on a specific file and line of a merge request.' This distinguishes it from siblings like post_merge_request_comment (general MR comment) and post_reply_to_code_discussion (reply to an existing discussion).

  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 clearly implies when to use the tool: when you need to create an inline comment on a specific file and line of a merge request. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it correctly among siblings.

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

• post_merge_request_commentA
  4.3/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 adds useful details like Markdown support and the return confirmation message, and it implies a non-destructive post operation. However, it lacks explicit information about permissions, side effects (e.g., notifications), or any limitations, which would be valuable for a write operation without annotation support.

  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 concise and well-structured: a clear opening sentence, a compact Arg list with examples, and a Returns line. Every sentence earns its place with no redundancy or fluff.

  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 (3 required parameters, no nested objects, and an output schema), the description is complete. It covers all parameters, explains the return value, and the purpose is clear. The presence of sibling tools does not require additional context because the scope is well-defined.

  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 schema has 0% description coverage, and the description compensates well by adding examples (project: 'ij'), clarifying that review_id can be an MR number or internal ID, and noting Markdown support for text. This adds meaning beyond the bare schema. It does not explain optionality or validation, but all parameters are required and the descriptions are adequate.

  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 'Post a general comment on a merge request,' which is a specific verb and resource. The 'general' qualifier distinguishes it from sibling tools like post_code_discussion and post_reply_to_code_discussion, making the purpose unambiguous.

  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 clear context that this tool is for posting general comments, which implies when to use it. It does not explicitly name alternatives or exclusions, but the context is sufficient for a straightforward operation. The sibling tools further clarify the distinction, though the description itself could have been more explicit.

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

• put_patronus_dry_runA
  4.3/5.0
  Behavior4/5

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

  No annotations are present, so the description itself carries the burden. It discloses that this is a non-destructive operation ('without merging') and describes the return behavior: Markdown with run ID, URL, and status, plus failure guidance. This gives the agent reasonable expectation of side effects and output, though it does not mention async timing or requirements like accessible MR.

  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 well-structured with a summary, behavior, args, and returns sections. Every line adds value: the args examples are useful, and the return description is necessary. It's slightly longer than minimal but not bloated.

  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 only two string parameters and no annotations, the description provides enough context for invocation. It includes return value details and points to get_patronus_run for follow-up. It doesn't cover edge cases like duplicate runs or permissions, but for a simple start command it's sufficiently 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?

  The input schema provides only types and required flags, with 0% description coverage. The description's Args section supplies semantic meaning: 'project' is a project key (e.g., 'ij') and 'review_id' is an MR number (e.g., '194108'). These examples help the agent generate correct values, though it doesn't specify exact regex/format constraints.

  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 'Start' and the resource 'Patronus dry run for a merge request'. It distinguishes itself from siblings like get_patronus_run and post_cancel_patronus_run by focusing on initiation. The phrase 'Runs all configured quality checks (TeamCity builds) without merging' adds specificity.

  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 what the tool does ('Runs all configured quality checks... without merging'), which implicitly tells when to use it. It explicitly points to the sibling get_patronus_run for tracking progress, providing an alternative. It does not explicitly list when not to use, but the guidance is sufficient for selection.

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

• get_patronus_runA
  4.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It does mention the return format ('YAML with run overview, TeamCity checks, and problems'), but it omits explicit confirmation that the operation is read-only and does not describe error handling or access requirements. This could leave an agent unsure about 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.

  Conciseness5/5

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

  The description is well-organized with clear sections for usage, args, and returns. It is concise without being terse, and every sentence contributes actionable information (e.g., how to obtain the run ID, how to use the resulting build IDs).

  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?

  For a single-parameter tool with an existing output schema, the description covers all necessary invocation context: input source, return contents, and follow-up steps. It is complete enough for an agent to confidently select and call this tool without additional information.

  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?

  The schema only defines run_id as a string, but the description adds essential meaning: it is a 'Patronus run UUID', and it gives specific methods for sourcing it (from get_patronus_runs or a URL with an example). This fully compensates for the 0% schema coverage.

  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 'Get details of a specific Patronus run' and enumerates what will be included (TeamCity build checks and problems). This distinguishes it from the plural sibling get_patronus_runs, which lists runs rather than fetching a single run's details.

  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 explicitly instructs to use the run ID from get_patronus_runs or a Patronus URL, and suggests following up with the teamcity CLI to inspect build IDs. This provides contextual workflow guidance, though it doesn't explicitly list when not to use the tool or alternative tools for different scenarios.

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

• post_reopen_merge_requestA
  4.4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full behavioral burden. It discloses the important prerequisite that the source branch must exist and provides actionable advice if it was deleted. It also mentions the return type. However, it does not disclose potential side effects, permission requirements, or behavior when the MR is already open, leaving some gaps.

  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 and concise. The summary line is front-loaded, followed by a useful note about the source branch, then clearly formatted Args and Returns sections. Every sentence is purposeful, 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?

  For a simple tool with only two parameters, the description covers the purpose, an important prerequisite, parameter semantics, and the return type. The input schema and this description together provide enough information for correct use. It also aligns well with sibling tools in the same domain.

  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?

  The schema only lists parameter types (strings), giving no semantic meaning. The description compensates fully by explaining 'project' with an example ('ij') and clarifying that 'review_id' can be an MR number ('194108') or internal ID. This adds significant value 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 clearly states the tool's function: 'Reopen a closed merge request.' This is specific, uses a strong verb, and names the resource. It distinguishes itself from siblings like post_close_merge_request and put_merge_request.

  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 clear context: it is for reopening a closed MR. It also gives practical guidance about the source branch needing to exist. However, it does not explicitly mention alternatives or when not to use the tool, falling short of a 5.

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

• get_attachmentA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description takes on the full burden of behavioral disclosure. It clearly explains the conditional behavior: text files return content directly, while binary files return a download URL. This is valuable transparency, though it does not mention potential error conditions or authentication requirements.

  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 clear purpose, a helpful usage hint, and organized Args/Returns sections. Every sentence adds value, and there is no wasted text.

  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?

  For a simple one-parameter download tool, the description is complete. It covers how to obtain the ID, what the return value will be for different file types, and clearly states the output format. No additional information seems necessary.

  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 input schema only defines attachment_id as a string with no description (0% coverage). The description compensates by explaining it is an Attachment UUID and instructing the user to obtain it from get_merge_request_timeline output, adding 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 clearly states 'Download a file attachment from a Space MR discussion' with a specific verb and resource. It also distinguishes itself from sibling tools like get_merge_request_timeline by focusing on attachment retrieval, and it explicitly references how to obtain the attachment ID from that sibling tool.

  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 clear context by instructing to use the attachment ID from get_merge_request_timeline output, which tells the agent when and how to invoke this tool. However, it does not explicitly mention alternative tools or when not to use it, so it stops short of a 5.

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

• get_merge_requestsA
  4.5/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It discloses the return format (YAML list), default limit, valid state values, case-insensitive author matching, and the error behavior for unknown authors. This is substantial transparency, though it does not mention ordering or pagination, which prevents a perfect score.

  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 well-structured docstring with an Args list and Returns note. The first line immediately states the purpose, and every sentence provides useful information without redundancy. It is concise yet comprehensive.

  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 complexity (6 parameters) and the presence of an output schema, the description covers most aspects needed to use it correctly. It explains default behavior, filter options, and return type. Minor gaps like lack of ordering/pagination details prevent a perfect score, but overall it is quite complete.

  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?

  The input schema has no descriptions (0% coverage), so the description is essential. It adds rich meaning to every parameter: examples for project/repository, allowed values for state, default and semantics for limit, and case-sensitivity/error behavior for author. This fully compensates for the schema's lack of detail.

  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 lists merge requests for a repository, using the specific verb 'List' and specifying the resource ('merge requests') and scope ('repository'). The plural 'requests' and mention of filters distinguish it from siblings like 'get_merge_request' (singular) and 'get_merge_request_timeline'.

  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 clear context for when to use the tool, including optional filters (branch, state, author, limit) and a default behavior. It does not explicitly name alternative tools for single merge requests or timelines, but the plural 'requests' and parameter list imply when this tool is appropriate, so it is a clear context without exclusions.

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