Server Quality Checklist

Tool Scores

• add_suites_to_executionB
  3.4/5.0
  Behavior1/5

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

  The description gives valuable behavioral details: snapshotting, project filtering, duplicate avoidance, and return shape {added, skipped}. However, it directly contradicts the annotations: the description calls the operation 'Idempotent' while the annotations set idempotentHint=false. This is an annotation 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?

  Three focused sentences, front-loaded with the core action, and each additional detail adds value: snapshotting, project scoping, idempotency, and the return shape. No wasted words.

  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?

  Without an output schema it states the return value {added, skipped}, and it explains snapshot behavior, project restrictions, and duplicate handling. The schema covers parameters fully. Only minor failure-mode or error details are absent, but the description is sufficiently complete for invocation.

  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 both parameters are already documented with clear UUID descriptions. The description adds execution-level semantics such as snapshotting, project filtering, and duplicate skipping, but does not need to explain the parameters further. Baseline 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?

  States a specific verb ('Add') and resource ('Suites ... to an execution'), clarifies that Suites are folders of type suite, and distinguishes the operation from sibling tools like add_cases_to_execution and add_collections_to_execution. The snapshot behavior further makes 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 Guidelines3/5

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

  Provides useful constraints: suites must belong to the execution's project or they are skipped, and duplicates are skipped. However, it does not explicitly state when to choose this tool over the sibling alternatives, so the usage guidance is more contextual than explicit.

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

• get_test_collectionB
  3.4/5.0
  Behavior3/5

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

  The annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds a worthwhile high-level statement about returns, but it does not cover details like the effect of includeTestDetails=false or potential payload size. There is no contradiction with the 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 short sentences communicate the core purpose and the return shape with no site waste. The most important information is front-loaded, and every sentence adds value.

  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 read-only getter with simple parameters and full schema coverage, the definition is mostly complete. It states what the tool returns and covers the main optional input, but without an output schema or more detail on the 'test execution overview', an agent has to interpret the exact response shape.

  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 input schema already documents collectionId and includeTestDetails including default behavior. The description does not provide significant semantic value beyond what the schema provides, so the score is a baseline 3.

  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 verb-resource pair ('get a test collection') and specifies the payload beyond the schema by mentioning all test cases and their execution status. It is clear enough to distinguish from list_test_collections at a high level, though it does not name an alternative explicitly.

  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 gives no direct guidance about when to use this tool versus alternatives such as list_test_collections, get_test_case, or get_execution_cases. The intended context is implied, but no exclusions or preferential scenarios are provided.

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

• get_folderA
  3.5/5.0
  Behavior4/5

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

  Annotations already convey readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context by indicating that statistics and recent cases can be optionally included, and the tool returns a single folder's details. This goes beyond what the annotations alone state and does not contradict them.

  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?

  One sentence with a clear subject: 'Get a single folder'. It is concise, front-loaded, and contains useful detail while avoiding fluff. The phrasing 'optionally statistics and recent cases' is slightly awkward, but still clear.

  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 read-only single-resource getter, the description plus schema supply enough for an agent to invoke the tool correctly. With no output schema, the description gives key return structures like path, case count, optional statistics, and recent cases. Some details such as exact errors or response format after end are not described, but missing those is a minor gap for a simple get 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?

  Parameter descriptions cover 100% of the schema properties and already explain every parameter, including defaults and maximum cases. The tool description adds only a general, optional mention of statistics and recent cases, which does not meaningfully exceed what the schema already provides.

  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?

  States a specific verb ('Get') and resource ('single folder'), and says the response includes path, case count, and optionally statistics and recent cases. This distinguishes it from list_folders, but it does not explicitly distinguish it from get_folder_statistics, which also deals with folder statistics.

  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 gives no guidance on when to use this tool versus list_folders, get_folder_statistics, or any sibling tool. An agent must infer from the word 'single' that this is for one folder, but there is no explicit direction or exclusions.

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

• get_launches_statisticsA
  3.5/5.0
  Behavior3/5

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

  The description matches the annotations: 'get' is consistent with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. It adds some context by clarifying launches are test runs and that results contain aggregated statistics, but it does not disclose what those statistics are, pagination behavior, or how the aggregation is computed. Still, the annotation safety profile lowers the bar, so a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single clear sentence with no filler, caveats, or redundancy. The core verb, resource, clause, and qualifier 'aggregated statistics' are front-loaded and readable at a glance.

  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?

  Given there is no output schema, the description is somewhat vague about what 'aggregated statistics' means and what the response contain. It is sufficient to call the tool because the schema covers all inputs, but an agent would still need to guess the exact return shape and whether statistics include counts, rates, durations, or something else.

  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 input schema already explains all seven parameters including lookback period, tags, limit, offset, search, statuses, and projectId. The description only adds the high-level 'aggregated statistics' intent and does not need to repeat parameter details; this matches the baseline for fully documented schemas.

  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 states a clear action ('Get a list') on a specific resource ('launches (test runs)') and adds the scope 'for a project' plus 'aggregated statistics'. This is enough to separate the tool from execution/case/folder management tools, though it does not explicitly distinguish it from the sibling 'get_launches_trends'.

  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 'for a project' phrase implies the tool needs a projectId and is appropriate when launch-level aggregate stats are requested. However, it gives no explicit when-to-use versus siblings like 'get_launches_trends' or 'get_launch_tests', leaving the alternative-selection decision mostly to the agent.

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

• get_launches_trendsA
  3.5/5.0
  Behavior3/5

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

  The description adds no behavioral context beyond the annotations; it simply states what data is returned. Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, providing the safety profile. No contradictions or extra risks are mentioned, but no additional useful behavior details (e.g., performance, date limits) are disclosed beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

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

  The description is a single, front-loaded sentence that names the operation and key outputs without excessive length. The phrase 'and more' is mildly vague but does not bloat the sentence, and every other part conveys useful 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?

  For a read-only analytics tool with well-documented parameters and clear annotations, the description covers the essential purpose and the kinds of data returned. It does not explain the dynamic behavior of the 'include' parameter or the meaning of 'topN' but those are adequately described in the schema, so the description is sufficient for typical usage.

  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?

  With 100% schema description coverage, the schema already explains every parameter. The description's list of trend categories ('pass rates, failing tests, flaky tests, duration trends') loosely reinforces the enum values of the 'include' parameter but does not provide new semantic meaning about any specific parameter.

  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 clear verb and resource: 'Get comprehensive trend data for a project' and lists concrete outputs (pass rates, failing tests, flaky tests, duration trends). It distinguishes from siblings like get_launch_tests and get_launches_statistics by focusing on trend data, though it does not explicitly name or compare alternatives.

  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 for when trend data is needed but never explicitly states when to choose this tool over get_launches_statistics or get_launch_tests. There are no when-not statements or references to alternatives, leaving the agent to infer context from the word 'trends'.

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

• get_case_execution_historyA
  3.6/5.0
  Behavior3/5

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

  Annotations already flag readOnly, idempotent, and non-destructive, so the description doesn't need to repeat safety. It adds useful context about the 'manual' scope and return contents ('pass rate and execution timeline'), but doesn't disclose additional behavior such as how far back it looks or how results are paginated. 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?

  The description is a single, front-loaded sentence with no filler. It efficiently communicates what the tool returns, the scope, and the type of executions included.

  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?

  There is no output schema, but the description tells the agent at a high level what comes back (pass rate and execution timeline) and covers the full scope of what is retrieved. The parameter schema covers the other details. It could be slightly more explicit about the response shape, but for a simple read tool it is adequate.

  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% and the parameter descriptions are already rich, including the important caseId vs TC-N distinction. The description does not add parameter-level value beyond what the schema provides, so the baseline 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?

  The description uses a specific verb ('Get') and resource ('manual execution history for a test case') and clearly scopes it 'across all test runs' and 'both standalone executions and release test runs'. It does not explicitly distinguish itself from siblings such as get_test_history, so it is clear but not a full 5.

  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 'manual' qualifier and the mention of both standalone and release test runs imply when this tool is relevant, but there is no explicit guidance about alternatives or when this tool should not be used. It gives context without stated exclusions.

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

• create_releaseA
  3.8/5.0
  Behavior3/5

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

  The description adds the useful behavioral note that omitting status defaults to 'planned', and it explains what releases aggregate. However, aside from the all-false annotations, it does not disclose idempotency, duplicate-creation behavior, permission requirements, or what the tool returns after creation.

  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 compact and front-loaded: the first sentence states the core action, the second adds domain context, and the third conveys the most important invocation nuance. No filler or redundant phrasing.

  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?

  Combined with a fully documented schema and the explicit default-status behavior, this description provides enough context for an agent to call the tool correctly. The main gap is the absence of any information about the expected response shape, since no output schema exists.

  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?

  With 100% schema description coverage, the schema already fully documents all 7 parameters, including status default, formats, and examples. The description notes the status default again but does not add meaningful parameter-level information 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 action and resource: 'Create a new release in a project.' It also explains what releases are for ('track versions and aggregate manual and automated test results'), which distinguishes this from create_execution, create_suite, and other create tools.

  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 intended use is implied through the description of what a release is, but there is no explicit guidance on when to choose create_release over update_release, link_launches_to_release, or list_releases. No exclusions or alternative selection criteria are stated.

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

• get_test_historyA
  3.8/5.0
  Behavior4/5

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

  Annotations already establish readOnlyHint, idempotentHint, and destructiveHint as safe, so the description does not need to cover safety. The description adds useful behavioral context by stating the output covers pass/fail timeline, duration changes, and retry patterns. This goes slightly beyond the annotations and clarifies what kind of history 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?

  Three focused sentences: the first states what the tool does, the second explains what it returns, and the third gives a use case. No filler or duplication, and the core purpose 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?

  For a relatively simple read-only tool with full schema coverage, the description is nearly sufficient. It explains the result's contents and intended purpose, but it omits the important behavioral caveat about titlePath matching empty history on invalid paths and does not reference a sibling alternative. The schema compensates for the path caveat, so the overall package is adequate but not fully 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 description coverage is 100%, so the schema carries the parameter documentation burden. The description only mentions the title path concept and does not add further explanation of days, limit, projectId, or titlePath format beyond what the schema already gives.

  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 identifies the action (Get) and the resource (execution history for a specific test), and it names the locator used (title path). It does not, however, explicitly differentiate this tool from the sibling get_case_execution_history, leaving some differentiation to inference.

  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 provides a concrete use case: understanding when a test started failing or became flaky. It does not mention when not to use this tool or how it compares to nearby alternatives like get_case_execution_history or get_launch_tests, so the usage guidance is implied rather than explicit.

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

• remove_cases_from_collectionA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true, so the baseline burden is lower. The description adds a meaningful behavioral detail not present in annotations: it also deletes step results for those executions. This gives the agent a clearer picture of the destructive 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 two short sentences with no redundant filler. The primary action is front-loaded, and the extra destructive detail is isolated in the second sentence. Every word earns its place.

  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 two-parameter mutation tool with strong schema coverage and annotations, the description covers the main action and an important side effect. It does not explicitly clarify that the test cases themselves are not deleted from the project, only removed from the collection, but the phrase 'from a test collection' strongly implies this.

  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 both collectionId and caseIds are already documented with types and examples. The description adds no parameter-specific semantics beyond their role in the removal operation. This is adequate because the schema carries the parameter 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 uses a specific verb and resource: 'remove test cases from a test collection.' This clearly differentiates it from siblings like add_cases_to_collection, and the phrase 'from a test collection' distinguishes it from delete_test_case. The additional side-effect sentence reinforces the exact scope.

  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 gives no guidance on when to use this tool versus alternatives. It does not mention that add_cases_to_collection is the inverse or that delete_test_case has a different meaning. The usage context is implied by the name and description but never explicitly stated.

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

• run_health_checkA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds real complementary context: the composite score's weighting ('blending automation, coverage, and manual execution'), and the subtle rule that the score only considers sections that 'are present and have data.' 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.

  Conciseness4/5

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

  Front-loaded with the purpose, then a dense but purposeful enumeration of the output sections and the include parameter. A single compact paragraph is slightly heavy, but every sentence carries meaning; nothing redundant or off-topic.

  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 no output schema, the description shoulders the burden of character return shape, and it does so thoroughly: composite score, sub-scores, sections, and weighting behavior. Minor gaps like undefined behavior when a project has no data are acceptable for a read-only analysis tool. The three params are fully covered between schema and description.

  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 the baseline is 3; the description earns a 4 by adding meaning beyond the include parameter's enum declarations — detailing what each section computes (pass rate, flakes, status/priority breakdown, pass-rate trend) and how section selection affects the composite score.

  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?

  States a specific verb and resource ('Get a holistic health assessment for a project') and defines the output precisely (composite score 0-100 plus per-dimension sections). It is clear and distinctive against the CRUD-heavy siblings, though it does not explicitly contrast itself with the analytics siblings (get_coverage_gaps, get_launches_statistics, get_launches_trends).

  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 the use case from 'holistic health assessment' and gives operational guidance ('Use include to limit which sections are computed'), but it never states when to prefer this tool over more targeted alternatives or when not to use it. The context is clear but the routing to/from siblings is left to inference.

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

• update_folderA
  3.8/5.0
  Behavior3/5

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

  Annotations already cover idempotence (idempotentHint=true), non-read-only behavior, and non-destructiveness (destructiveHint=false). The description adds one useful behavior: 'Set parentId to null to move to root level.' It does not enrich that this is an update operation that may overwrite existing values or discuss permissions/rate limits, but given the annotations the disclosure is adequate.

  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 compact and front-loaded: it opens with the verb and resource ('Update a folder name and/or move it to a different parent'), then clarifies the special root-level case. Both sentences earn their place, with no filler 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 simple mutation operation, high schema coverage, and complete annotations, the information needed to call the tool correctly is largely present. The description covers the non-trivial parentId=null case. It omits a return value or result description, but no output schema exists, and an update tool does not inherently need one for a call to succeed.

  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 input schema provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds one operational nuance for parentId (set to null to move to root), but this is already present in the schema's parameter description. No extra meaning is added beyond what structured field already provides.

  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 a specific action: 'Update a folder name and/or move it to a different parent.' This distinguishes it clearly from sibling tools like create_folder, get_folder, and delete_folder. The inclusion of the 'move to root' detail makes the resource and scope unmistakable.

  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 communicates the primary use cases (renaming and moving a folder) and adds a specific behavioral note about parentId null. However, it does not explicitly mention when not to use this tool, nor does it name alternatives like creating or deleting a folder. The reader must infer the social context from sibling names alone.

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

• add_collections_to_executionA
  3.9/5.0
  Behavior1/5

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

  The description explicitly says the operation is idempotent, while the annotations declare idempotentHint: false. This is a direct contradiction. Although the description otherwise adds useful behavioral detail about snapshotting, project-scoped skipping, and the return value, the annotation conflict requires a score of 1 per the rubric.

  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 focused sentences convey the purpose, constraints, idempotency, and return shape with no filler. The description is front-loaded with the primary action and resources, making it highly scannable.

  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 mutation tool with no output schema, the description is complete: it specifies what is added, how collections are treated, project eligibility rules, idempotency behavior, and the return object. An agent has enough information to invoke this correctly without needing additional explanation.

  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 already fully documents both parameters, so the baseline is 3. The description adds value by clarifying that collectionIds are snapshotted as test runs, that collections outside the project are silently skipped, and that already-present collections cause no duplication.

  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 opens with a specific verb and resource: adding Test Collections to an execution. It also clarifies what 'Test Collections' means as 'manual runs' and clearly distinguishes this from siblings like add_cases_to_execution and add_suites_to_execution.

  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 this tool applies: adding one or more collections to an execution, with clear behavior for invalid and duplicate collections. It does not explicitly name alternatives or state 'when not to use this tool', but the semantics are clear enough from the description and sibling names.

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

• add_external_linkA
  4/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the annotations: repeated calls with the same external_id return the existing link instead of creating a duplicate. This clarifies the idempotency behavior that idempotentHint only hints at. No contradiction with annotations exists.

  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 and both are purposeful: the first states exactly what the tool does and to which systems, and the second covers an important behavioral caveat. No filler 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 description, combined with the rich schema and annotations, is largely complete: scope, idempotency, and entity/provider flexibility are all covered. The only notable gap is that the happy-path return value is not described, and there is no output schema to compensate.

  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 86%, so the schema already carries most parameter semantics, setting the baseline at 3. The description does not meaningfully add to individual field meanings, although the idempotency note does clarify the function-level semantics of externalId.

  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 uses a specific verb and resource: 'Link any test entity... to an external ticket...'. It explicitly enumerates entity types and target systems, which clearly distinguishes it from sibling tools like link_launches_to_release or link_autotest_to_case.

  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 is clear: use this tool when adding an external link to an entity. However, it does not explicitly differentiate when to use this tool versus alternatives such as list_external_links or remove_external_link, nor does it provide any exclusions or when-not-to-use guidance.

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

• bulk_update_casesA
  4/5.0
  Behavior3/5

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

  Annotations already indicate the operation is mutable, destructive, and idempotent, so the description has limited burden. It adds the same-project constraint, but does not disclose partial-failure behavior, response shape, or whether tag operations merge or replace existing tags. That leaves some behavioral ambiguity for a bulk mutation operation.

  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 short sentences, each carrying meaningful information: the action, the supported fields, and the project constraint. The description is front-loaded and contains no filler.

  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 purpose, supported fields, batch scope, and the key constraint that all caseIds must belong to the same project. Since there is no output schema, it could ideally mention the response or partial failure semantics, but the current description is complete enough for a caller to select and invoke the tool 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?

  The schema covers 100% of parameter descriptions, including caseIds constraints and the updates sub-fields. The description adds only the same-project constraint beyond what the schema says, so the baseline score 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?

  The description states a specific action and resource: 'Update multiple test cases at once' and enumerates exactly which fields can be changed (status, priority, tags). The 'at once' plus 'batch' framing also gives agents a clear signal how to distinguish this from the single-case sibling update_test_case.

  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 gives clear context: this is for bulk updates and requires all cases in the same project. It doesn't explicitly state 'use update_test_case for a single case' or 'don't use for cross-project cases', but the same-project constraint and batch framing make the primary usage reasonably explicit.

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

• get_coverage_gapsA
  4/5.0
  Behavior4/5

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

  Annotations already communicate read-only, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds meaningful behavioral detail by defining the forward coverage gap, the reverse gap involving recent launches, and what kinds of results are surfaced. This goes beyond the annotations and schema.

  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 with no padding: the first states what the tool surfaces, and the second gives a direct use case. The key output categories are front-loaded before the softer context sentence.

  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 main return categories and the purpose, while the schema thoroughly covers all five parameters. Since there is no output schema, the description carries the burden of describing the output and does so at a practical level. It would be slightly stronger with a note about how results are combined or limited, but it is otherwise 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 description coverage is 100%, and every parameter has a clear description with defaults and bounds. The description adds no additional parameter-level semantics, but it does not need to because the schema already carries that weight.

  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 specific verb ('Identify') and a specific resource ('test coverage gaps'), then enumerates exactly what counts as a gap: unlinked test cases, low-automation folders, and reverse-gap autotests. This makes the tool's purpose unmistakable and distinguishes it from siblings like search_tests or get_feature_scan.

  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 gives a general context ('Useful for test planning and coverage improvement'), which implies when the tool might be used, but it does not explicitly state when to prefer or avoid this tool over sibling alternatives nor name any exclusion conditions. This is useful but not explicit routing guidance.

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

• get_folder_statisticsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety behavior. It adds useful context by noting that statistics include nested folders and summarizing return metrics, though it does not disclose potential limitations such as data range boundaries or response size.

  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 compact and front-loaded, stating the core purpose first and following with a brief enumeration of return categories. Every sentence adds functional value, with no wasted words or redundant schema 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 a single required parameter, strong annotations, and a simple read-only purpose, the description covers the essential context. Without an output schema, the list of metric categories gives the agent a reasonable expectation of the response shape, though exact field or structure details are not fully enumerated.

  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 schema fully documents the sole parameter (folderId, UUID) and even tells the agent to obtain it from list_folders. The description contributes no additional parameter-specific guidance, so it is at the baseline for a schema with 100% 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 identifies a specific verb ('Get'), a resource ('folder statistics'), and a distinct scope ('including nested folders'). It lists concrete return categories (automation rate, status/priority breakdown, tag usage, time-based metrics), making it easy to distinguish from sibling tools like get_folder or list_folders.

  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 establishes the tool's clear domain: detailed folder-level statistics with nested scope. It does not explicitly state when to avoid it in favor of siblings like get_launches_statistics or get_folder, but the focus on folder statistics makes the intended use reasonably apparent.

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

• get_releaseA
  4/5.0
  Behavior4/5

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

  Annotations already cover read-only and idempotent behavior. The description adds useful context about the returned content, such as aggregate stats and optional linked manual executions and automated launches. This is appropriate disclosure given the safe read-only profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single efficient sentence that front-loads the primary action and resource and then adds the key optionality. No filler or repeated schema/annotation content is present.

  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 a 3-parameter schema that is fully described and safety annotations already provided, the description covers the important context: target release, full details, aggregate stats, and optional linked executions/launches. Without an output schema, a slightly more explicit list of returned fields could raise it further, but the description is still strong.

  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 parameter descriptions are complete at 100% coverage, including defaults and guidance on keeping the response small. The tool description does not add parameter-level detail, but it also does not need to because the schema already carries the full meaning.

  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 a specific verb and resource ('Get a single release'), clarifies the scope as a single item, and lists key content returned ('full details including aggregate stats' and optional linked data). This distinguishes it from sibling tools like list_releases and other getters.

  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 clearly implies the tool is for retrieving one release and it gives optionality around linked executions/launches, but it does not explicitly name alternatives such as list_releases or state when the optional includes should be omitted. Some usage direction is present, but exclusions are left to inference.

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

• get_test_caseA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered. The description adds meaningful behavioral detail about what 'full details' includes, such as steps, custom fields, dependencies, shareUrl, and optional linked autotests and edit history.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the core purpose first and then lists the distinguishing detail fields without waste. Every phrase adds useful 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?

  For a read-only single-case retrieval tool with no output schema, the description covers the main return content and optional toggles, and the schema covers all parameters. It could be slightly more explicit about error behavior, but nothing critical is missing.

  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 fully describes all four parameters. The description adds high-level context about what the response will contain, but does not itself explain individual parameters; the excellent caseId guidance lives in the schema, not the description. This matches the high-coverage baseline.

  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 a specific verb ('Get'), a specific resource ('a single test case'), and lists the key contained details. It is immediately distinguishable from sibling tools like list_test_cases, which retrieve multiple cases, and get_test_history, which retrieves execution history.

  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 is the tool to use when you need one full test case, but it does not explicitly state when to choose it over alternatives like list_test_cases or search_tests, nor does it name any exclusions. Some usage guidance appears in the parameter description for caseId, but the main description itself lacks that routing.

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

• list_external_linksA
  4/5.0
  Behavior3/5

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

  The annotations already establish that this is read-only, idempotent, and non-destructive. The description adds only 'given entity' and 'optionally filtered by provider', which are also visible in the schema. It does not mention result shape, pagination, or other runtime behavior beyond what the call itself implies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single sentence that front-loads the verb, object, scope, and optional filter. There is no filler and no repetition of obvious schema details.

  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?

  It is largely sufficient for a simple read-only listing tool, especially with strong annotations and a small well-understood parameter set. However, there is no output schema and the description doesn't describe the shape of the links returned or any pagination/filtering behavior, so it leaves a small 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?

  Schema coverage is 67%, with entityId and provider already described and entityType constrained by enum. The description loosely mirrors these with 'given entity' and 'filtered by provider', but it adds no substantive semantic detail beyond the schema's existing documentation.

  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 specific verb 'List' and names a specific resource: 'external ticket links for a given entity'. It also notes the optional provider filter, making the tool's scope immediately clear and distinguishing it from add_external_link and remove_external_link.

  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 gives clear context: to use this tool when they want to display external ticket links for an entity, optionally narrowed by provider. It doesn't explicitly name alternatives or state when this tool should be avoided, 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.

• list_foldersA
  4/5.0
  Behavior4/5

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

  Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds valuable behavioral context beyond annotations: return shape (flat list), hierarchy fields (parentId, path, depth), and the semantic model (folders can nest folders/suites; suites are leaf nodes). This meaningfully informs expected behavior without contradicting any annotation.

  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 tightly written sentences: verb/resource first, usage purpose second, return-shape and semantics third. Every sentence earns its place; there is no filler or repetition of schema content. The hierarchy detail is packed efficiently.

  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 (hierarchical data, no output schema), the description conveys the key matters: what is returned, the folder/suite nesting rule, and why an agent needs it. It doesn't explain how includeStats/indexDeleted alter results, or pagination/result limits, but the read-only/idempotent safety is covered by annotations and the primary invocation contract is clear enough.

  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% — all three parameters (projectId, includeStats, includeDeleted) already have descriptions and defaults in the schema, so the baseline of 3 applies. The description does not add parameter-level semantics beyond the schema, such as how includeStats affects output or how includeDeleted interacts with hierarchy reporting.

  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?

  Description states a specific verb (list) and resource (all folders and suites for a project), which clearly differentiates it from the singular get_folder sibling. It also clarifies the folder/suite relationship, adding precision beyond just 'list folders'. Minor gap: doesn't explicitly distinguish from list_test_cases or list_test_collections, but the 'folders and suites' scope is 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 gives an explicit usage instruction: 'Call this to get folder IDs needed for create_test_case.' This tells the agent when to invoke it. However, it does not name alternatives or state when-not-to-use (e.g., get_folder for a single folder, list_projects for project lookup), so it falls short of a full 5.

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

• list_test_collectionsA
  4/5.0
  Behavior4/5

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

  Annotations already cover read-only, idempotent, and non-destructive behavior, so the description does not need to repeat safe behaviors. It adds useful context by noting that results include execution stats, even if it does not elaborate on response shape or archived handling.

  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 with no filler. The first sentence is the actionable purpose and the second provides conceptual context for what collections are used for, which is appropriately 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?

  For a read-only list tool with well-documented filters and pagination, this description is largely complete. It lacks explicit routing guidance against other list tools, and there is no output schema describing execution stat fields, but nothing blocks correct invocation.

  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%, and every parameter already has a clear description. The tool description adds no additional parameter detail, but it does not need to; the baseline of 3 applies because the schema does the heavy lifting.

  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 explicitly states the verb 'List', the resource 'test collections', and the scope 'in a project', and adds value with 'manual runs' and 'execution stats'. This distinguishes it from other list tools enough for an agent to identify the right resource.

  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 when to use the tool by explaining collections organize manual test executions for sprints, releases, or ad-hoc testing. However, it does not explicitly name alternative tools like list_executions or list_test_cases, nor does it state when not to use them, leaving that routing to the agent's inference.

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

• search_testsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context that results include most recent execution status and reliability metrics, but it does not disclose pagination, default limits, or any query semantics beyond what the schema already provides.

  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 compact and focused: two sentences, the first stating the core action and the second giving practical guidance. There is no filler or redundant restating of schema-property details.

  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 search tool with a well-documented schema and strong annotations, the description is largely complete. It names the search criteria, result content, and a use case. The main gap is that it does not explicitly discuss output format or suggest any sibling alternative for non-searching workflows, which would slightly strengthen completeness.

  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 all parameters are already well-documented. The description adds general vocabulary like 'title, file path, or tags' that maps to the query parameter, but it does not add substantive meaning beyond the input schema, so the baseline score 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?

  The description states a specific verb ('search'), a resource ('tests'), the supported search dimensions ('title, file path, or tags'), and what is returned (execution status and reliability metrics). This allows an agent to distinguish it from sibling tools like list_test_cases or get_case_execution_history.

  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 gives clear usage context ('Use this to find tests related to a specific feature or area'). However, it does not explicitly state when NOT to use it, such as when listing all tests without a search query or when retrieving full detail for a single test.

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

• delete_releaseA
  4.1/5.0
  Behavior5/5

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

  The annotations already indicate destructive and idempotent behavior, but the description adds valuable context: the delete is actually a non-destructive archive, the release can be restored via the UI, and linked test runs/launches are preserved. This meaningfully clarifies the impact beyond the structured hints.

  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 compact sentences carry exactly the necessary information. The first sentence front-loads the core action, and the second adds important behavioral detail with no wasted 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?

  For a single-parameter soft-delete operation with full schema coverage and relevant annotations, the description is complete. It explains what occurs, what is preserved, and how the action is reversible, which is enough for an agent to invoke the tool safely.

  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 input schema already documents the single releaseId parameter as 'Release UUID to archive' with 100% coverage. The description does not add new parameter-level meaning beyond reaffirming that the operation is an archive, so the baseline score applies.

  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 ('Soft delete (archive) a release') and identifies the specific resource. It does not explicitly call out sibling distinctions, but 'soft delete' versus a permanent delete and the resource name make the purpose clear.

  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 the intended use: archive a release while preserving linked test runs and launches. However, it gives no explicit guidance on when not to use this tool or which alternative to choose if a hard delete, update, or restore is needed.

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

• export_reportA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add contextual behavior. It states that the report content is returned as a string and that release reports depend on releaseId, which is useful and goes beyond the schema. It does not explain edge-case behavior like empty report results, but this is not critical given the 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 compact and well-structured: it front-loads the main purpose, lists supported types and formats, states the return type, and ends with the most important conditional note. No sentence is wasted.

  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 has five parameters, schema annotations, and no output schema, the description provides enough information for an agent to call the tool correctly and understand the result. It could further position this tool against sibling read/report tools, but that gap is minor.

  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 description coverage is 100%, so the baseline is 3. The description adds value by explicitly connecting reportType 'release' to the releaseId argument and directing the agent to fetch it from list_releases. This cross-parameter relationship is helpful beyond the schema's individual field descriptions.

  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 states a clear action (generate a formatted report), a clear resource (project), and explicitly lists report types and formats. It does not explicitly distinguish itself from similar sibling tools like get_launches_trends or get_execution, but its purpose is 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 explains that it covers summary, failures, trends, and release reports and adds a concrete conditional note: release reports require releaseId, which can be obtained from list_releases. It does not explicitly say when not to use this tool or when a simpler sibling is preferable, but the included guidance is actionable and clear.

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

• add_cases_to_collectionA
  4.2/5.0
  Behavior4/5

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

  The description discloses behavioral traits beyond the annotations: duplicate cases are skipped, and the cases must exist and belong to the same project. These are valuable operational details that align with, and enrich, the idempotentHint=true annotation. It does not specify failure behavior for invalid cases or collection, but the core behavior is clear.

  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 short sentences with no filler. The core operation is front-loaded, and the caveats are stated briefly and precisely. Every sentence provides useful action-oriented 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?

  For a two-parameter mutating operation, the description is largely sufficient: it gives the target, the precondition, and the duplicate-skipping behavior. With idempotentHint=true and destructiveHint=false already supplied, the description covers most operational concerns. It does not describe what happens if a case belongs to another project or if the collection is missing, but that is a minor 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?

  Input schema coverage is 100%, so the schema already explains parameter formats and meanings. The description adds operational meaning such as duplicate handling and project membership, but it does not need to restate parameter semantics. Baseline 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?

  The description clearly specifies the action (add), the object (test cases), and the target (an existing test collection). This differentiates it from related tools like add_cases_to_execution and remove_cases_from_collection without ambiguity.

  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 when to use this tool: when adding test cases to an existing collection. The preconditions that cases must exist in the same project help clarify correct use. It does not explicitly exclude alternatives or name sibling tools, but the target resource is unambiguous.

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

• get_launch_testsA
  4.2/5.0
  Behavior5/5

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

  Annotations cover the safety profile (readOnlyHint, idempotentHint, destructiveHint). The description adds high-value behavioral context beyond those annotations: response contents (error messages, stack traces), the attachments array shape, and a crucial non-obvious behavior — the X-MCP-Key header requirement for API URLs vs. presigned storage URLs. This is exactly the kind of runtime nuance an agent needs to fetch artifacts correctly.

  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 front-loaded with the primary purpose and scoping, then layers in return details, and reserves density for the attachments/URL auth nuance at the end. Every sentence earns its place; nothing is wasted or promotional.

  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 no output schema, the description compensates well by documenting what failed tests return (errors, stack traces, attachments, URL handling). It is a bit thin on describing the overall result list shape beyond the attachment nuance, but for a launch-scoped read operation the prerequisites, filtering capabilities, and artifact-fetching behavior are well covered.

  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 schema already documents limit, offset, search, launchId, statuses, and includeErrors with ranges, defaults, formats, and enum values. The description does not add parameter-level meaning beyond the schema, so the baseline 3 applies. The launchId description even provides its own cross-tool sourcing guidance.

  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 opening sentence states a specific verb, resource, and scope: 'Get all tests from a specific launch/run with detailed results.' The term 'specific launch/run' distinguishes it from broad search/list siblings, and the schema's launchId description reinforces the workflow sourcing it from get_launches_statistics/get_launches_trends.

  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?

  Usage context is implied through the mention of detailed results, error messages, stack traces, and failure investigation attachments, but there are no explicit 'when to use vs. alternatives' statements, such as directing the agent to search_tests when no launchId is known. The schema's launchId hint (obtain from siblings) supplies workflow context, but the description itself doesn't state exclusions.

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

• get_projectA
  4.2/5.0
  Behavior4/5

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

  Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: the returned vocabularies are project-customizable, the tool returns the fields the project actually uses, and it provides the expected response shape despite there being no output schema.

  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 efficient: it front-loads the purpose, explains why the agent should call it, and lists the relevant status field examples. Slightly verbose because of the enumerated return shape and status examples, but each part supports correct invocation.

  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 read-only, single-parameter tool with no output schema, the description is complete. It explains what the tool returns, why the agent would need it, and the critical domain caveat that status values are project-customizable. Nothing essential is missing.

  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 only parameter, projectId, is fully documented in the schema as a 'Project UUID (from list_projects)'. Since schema description coverage is 100%, the description does not need to add parameter-level semantics and does not.

  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?

  Uses a specific verb ('Get') with a clear resource ('a project's configuration') and enumerates exactly what is returned: meta, actual system-field vocabularies, and custom-field definitions. This clearly differentiates it from sibling tools like list_projects and other get_* tools.

  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?

  Explicitly instructs the agent when to call the tool: before setting status values, because statuses are project-customizable and must not be hardcoded. It does not explicitly discuss when not to use it or list alternative tools, but the when-to-use guidance is strong and actionable.

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

• link_launches_to_releaseA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate idempotent and non-destructive behavior, and the description adds useful behavioral context beyond annotations: it specifically clarifies that launches are linked by reference rather than copied. This helps an agent understand the semantic effect of the operation without contradicting the 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 short, purposeful sentences. The main action is stated first, and the contrast with manual runs adds crucial context without repetition or unnecessary text.

  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 small parameter set, the annotations, and the explicit schema descriptions, the description is sufficient in scope. It lacks an explicit output/return mention, but no output schema exists; behavioral and idempotency clues are already present through annotations.

  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 clear descriptions for both releaseId and launchIds, including where to obtain launch UUIDs. The description does not significantly add per-parameter detail beyond the schema, so it meets the baseline but does not push higher.

  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 specific verb and resource ('Link automated test runs (launches) to a release') and explicitly distinguishes this from manual runs, making it easy to understand what the tool does. The clarity is reinforced by the contrast 'unlike manual runs' and the 'by reference (not copied)' detail.

  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 gives clear context by explaining this is for automated test runs and that launches are linked by reference, which implies it is the correct tool when connecting launches to releases. It does not explicitly name alternatives or exclusion conditions, but the manual-run distinction provides reasonable usage guidance.

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

• list_executionsA
  4.2/5.0
  Behavior4/5

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

  Annotations already show readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds substantive behavioral detail by explaining the shape of the progress field, including all buckets and rates, which goes beyond the 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 terse sentences, each carrying distinct value: what is listed, when to use it, and what progress contains. No filler or repeated schema 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?

  With no output schema, the description usefully explains a key part of the response (progress bucket details). It also gives the intended lookup scenario. It doesn't mention pagination or the exact fields returned for each execution, but for a harmless read-only list tool this is acceptable.

  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 does not add parameter-level detail. Schema coverage is 60%: projectId, search, and status have descriptions, while limit and offset only have names and defaults. However, limit and offset are self-explanatory pagination parameters and have sensible defaults, so the gap is minor.

  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 a specific action ('List') and resource ('Manual Test Executions for a project'), and adds the distinguishing element of progress stats. It is easy for an agent to differentiate this from the singular get_execution or related add-source tools.

  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 to find an existing execution id before adding sources', which gives a concrete trigger scenario. It does not explicitly name sibling alternatives or list when not to use it, but the use case is clear enough for selection.

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

• list_releasesA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark this as read-only, idempotent, and non-destructive, so the description only needs to add contextual behavior. It does this by mentioning the inclusion of aggregated stats and support for status/search filtering, which helps set expectations beyond a plain list.

  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 short sentences with no filler. The core purpose is front-loaded and additional capabilities are stated efficiently.

  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 six-parameter listing tool with fully described schema and no output schema, the description adequately covers purpose and main filtering capabilities. It does not describe pagination semantics, but those are already present in the schema, so the agent has enough to invoke the tool 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?

  Input schema description coverage is 100%, so all six parameters are documented structurally. The description adds only high-level information about status and search filtering, which does not exceed what the schema already provides; therefore, the baseline 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 lists releases for a project and includes a specific scope: aggregated stats for manual tests and automated launches. The verb 'List' plus the resource 'releases' is specific and differentiates it from single-resource tools like get_release.

  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 conveys when to use it: to get a project's releases together with aggregated stats and filtering. It does not explicitly name alternatives, but the context is clear enough that an agent can infer list_releases is the right choice for a collection-oriented, filtered request.

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

• move_test_caseA
  4.2/5.0
  Behavior3/5

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

  The annotations already provide the safety profile (read-only false, destructive false, idempotent true), and the description mostly reinforces that moves stay within the same project. The 'different folder' and 'same project' scope adds a small amount of behavioral context, but doesn't disclose anything beyond the schema constraints or 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 one concise, front-loaded sentence that states the action, the scope, and the exception. It does not repeat the schema or add filler; every words earns its place.

  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 two-parameter move operation with no output schema, the description effectively captures what the tool does and its main boundary condition. A bit more detail about expected result or failure behavior would be nice, but the annotations already carry the idempotent and destructive-profile information.

  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 input schema already documents both parameters completely (caseId and targetFolderId, with their types and the same-project requirement). The description just restates the folder constraint and adds no extra detail about parameter values, formats, or derived behavior.

  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 specific verb ('Move'), a clear resource ('test case'), and an explicit target ('a different folder within the same project'). It also names the key limitation ('Cross-project moves are not supported'), which distinguishes this tool from any generic update or move operation.

  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?

  It states exactly when to use the tool: moving a test case to another folder within the same project. It also explicitly says when not to use it: cross-project moves are not supported. No alternative sibling exists for moving a test case, so no further routing guidance is needed.

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

• delete_test_caseA
  4.3/5.0
  Behavior5/5

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

  Beyond the annotations, the description adds valuable behavioral details: the operation is a soft delete, the case can be restored via the UI, and connected autotests are unlinked. These side effects are not visible from annotations alone and help the agent predict the full impact.

  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 tight sentences with no wasted words. The core operation is front-loaded, followed by the restore path and the important side effect of unlinking autotests.

  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 mutation with annotations, this description is sufficient. It explains what happens, how it can be undone, and what additional effects occur, so an agent can safely predict the behavior without an output schema.

  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% and the only parameter, caseId, is already documented as 'Numeric test case ID to archive'. The tool description adds no additional parameter meaning beyond what the schema provides.

  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 identifies the resource ('a test case') and the specific behavior ('Soft delete (archive)'). It also separates it from sibling deletion tools by emphasizing archiving and restoration.

  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 intended use case is implied: call this when you want to archive a test case, and the restoration note implies the operation is reversible. However, it does not explicitly mention alternatives or when not to use it, such as removing a case from a collection instead of deleting it.

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

• delete_test_collectionA
  4.3/5.0
  Behavior4/5

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

  The description adds value beyond the annotations. Although destructiveHint and idempotentHint already mark the operation as destructive and repeatable, the description clarifies the exact nature: it is an archive/soft delete, the collection is recoverable via UI, and test executions remain intact. This materially refines the meaning of the destructive hint and helps the agent avoid assuming irreversible deletion.

  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 short sentences deliver high-value information with no redundant words. The most important fact, 'soft delete', is front-loaded, and the following sentences add critical behavioral nuance about restoration and preserved executions.

  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 is complete for a simple one-parameter mutation. It explains the operation type, reversibility, and impact on test executions. There is no output schema, so the absence of return-format details is acceptable. The core behavior an agent needs to invoke this tool safely and correctly is fully covered.

  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?

  There is only one parameter and the schema description coverage is 100%. The schema already explains that collectionId is the test collection UUID to archive. The tool description does not add further parameter-specific detail, which is acceptable because the schema carries that burden.

  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 specific operation: 'Archive (soft delete) a test collection'. It identifies both the verb and the resource, and explicitly clarifies it is a soft delete. This distinguishes it from the sibling delete_* tools, especially delete_test_case and delete_execution.

  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 does not explicitly name alternative tools or state when not to use it, but it gives clear behavioral context: restoration via the UI and preservation of test executions. For an agent deciding whether to use this tool, the 'soft delete' framing and reversibility strongly imply this is the safer deletion pathway.

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

• get_executionA
  4.3/5.0
  Behavior4/5

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

  Annotations already establish safety (readOnly, idempotent, not destructive), but the description adds valuable non-obvious behavior: externalLinks are returned only when the caller holds integrations:read, and the structure of progress and sources is explicitly described. This goes beyond annotation basics and informs the agent about conditional data availability.

  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 information-dense sentences cover purpose, usage, and result structure without filler. The main purpose is front-loaded, and every clause adds meaningful detail for successful tool invocation.

  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 no output schema, the description must convey what the tool returns. It does so thoroughly: sources, links, progress, bucket categories, and rates. It also explains the permissions caveat and how IDs map to sibling tools. Nothing critical is missing for a single-parameter read operation.

  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 input schema already fully documents executionId as an execution UUID with 100% coverage. The description does not add semantic meaning to the parameter itself, but it indirectly explains how the returned sources relate to other operations. This is baseline adequate given full 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 uses a specific verb ('Get') with a clearly defined resource ('a Manual Test Execution') and enumerates its returned components: sources, linked releases, external ticket links, and overall progress. It distinguishes itself from siblings like get_execution_cases and list_executions by describing a full execution snapshot with progress and sources.

  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 states 'Use to verify what an execution contains,' giving clear situational guidance. It also connects to sibling tools by noting sources[].id is the runId for set_execution_source_status and remove_source_from_execution. It does not name alternative tools for negative guidance, but the primary use case is clear.

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

• get_execution_casesA
  4.3/5.0
  Behavior4/5

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

  Annotations already confirm read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond those annotations: it documents the returned fields, notes that externalLinks appear only with integrations:read, and guarantees that 'everything report_case_result writes reads back here.'

  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 dense but all information is relevant: purpose, return contents, dependency note, workflow ordering, and filtering. The first sentence packs in much detail while still being readable, and the later sentences sharpen the workflow context 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 read-only list tool with no output schema, the description does an excellent job explaining the response structure and filtering. Minor missing context: exactly how pagination is represented in the response and what valid values exist for status beyond the examples in the schema.

  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 high (67%), with useful descriptions already on search, status, groupId, and executionId. The description contributes only the mapping of 'filtering by ... title' to the search parameter, while limit/offset are standard unannotated 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?

  States an explicit action ('List'), a specific resource ('individual case-run rows of a Manual Test Execution'), and the intended use ('so you can report results against them'). It also clearly distinguishes itself from report_case_result by positioning itself as the read-side counterpart.

  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?

  Provides explicit workflow positioning: 'Use after add_*_to_execution and before report_case_result.' This tells the agent exactly when in a process the tool fits, and the read-back note clarifies its relationship to report_case_result.

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

• remove_external_linkA
  4.3/5.0
  Behavior3/5

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

  The description's 'Remove' matches the annotations' destructiveHint=true and readOnlyHint=false, so there is no contradiction. It adds that the link is an external ticket link and that valid identifiers are the UUIDs produced by specific companion tools. However, it does not add much behavioral detail beyond what the annotations already express, such as irreversibility or failure behavior.

  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?

  One clear, front-loaded sentence communicates the operation, the target, and the source of the required identifier. There is no filler or redundant restating of the schema.

  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 destructive tool with an informative annotation set and no output schema, this is sufficiently complete. The annotations establish that it is destructive and non-read-only, and the description supplies the remaining practical context: what kind of link and how to obtain its UUID.

  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, but the description compensates by explaining that linkId is a link UUID and, more usefully, that it comes from add_external_link or list_external_links. This gives an agent concrete guidance on where to find a valid value rather than simply naming the field.

  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 a specific verb ('Remove'), a clear resource ('external ticket link'), and the exact key needed to identify it (link UUID). It also names the source tools that produce the UUID (add_external_link or list_external_links), which disambiguates it from related link-based siblings.

  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 effectively tells the agent when this tool is appropriate: when there is an external link UUID, and it explains how to obtain that UUID. It does not explicitly state when not to use it or name alternatives for non-removal operations, but the single-job scope is clear enough.

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

• suggest_test_casesA
  4.3/5.0
  Behavior4/5

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

  The description reveals important behavioral characteristics not present in the annotations: this is pattern matching, not model output, and the results are scaffolding that require human/AI refinement before persistence. The readOnlyHint already signals safety, but the description adds the expectation that results are provisional and not final artifacts. This meaningfully helps the agent decide how to use the output.

  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 compact two-sentence definition that front-loads the tool's purpose and then adds just enough behavioral and next-step context. Every clause serves a clear function: output expectation, pattern-matching caveat, and handoff to its sibling. There is no padding or reiteration of schema fields.

  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 fully documented input schema, read-only annotation, and simple output shape stated in the description, the tool is fully scoped. The description even covers what to do with the returned scaffolding, which is essential for a suggestion-only tool. Nothing critical is missing for an agent to correctly invoke it and handle the output.

  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 input schema already documents all four parameters with 100% coverage, including defaults and constraints. The description adds minimal extra parameter semantics, mostly reinforcing that featureDescription is the source input and projectId makes suggestions project-aware. That is helpful but only tangentially, so the baseline 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?

  The description clearly identifies the tool as returning template-based test case scaffolding for a feature description, and specifies the output format (titles, steps, priorities). It explicitly contrasts itself with model output and create_test_case, which helps an agent understand its distinct role among siblings. The verb 'Return' plus the resource 'test case scaffolding' makes the core 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 gives explicit usage context: use this tool to generate project-aware starting suggestions, refine them yourself, then persist them with create_test_case. It implicitly communicates that create_test_case is the follow-on tool for actual creation, but it does not enumerate situations where this tool should be avoided or other alternatives preferred. This is strong but not fully exhaustive guidance.

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

• unlink_launch_from_releaseA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds useful behavioral transparency by stating that only the link is removed and the launch itself remains unaffected, which prevents an agent from assuming the launch is deleted.

  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 short sentences with no filler or redundant phrasing. The core action is front-loaded and the clarifying caveat about the launch being unaffected is valuable and concise.

  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, two-parameter unlink operation, the description covers the action, the object being modified, and the critical non-effect on the launch itself. The annotations and schema carry the remaining safety and input details, so nothing essential appears to be missing.

  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 input schema already fully documents both releaseId and launchId with clear descriptions, so the description does not need to add parameter-level meaning. The description adds nothing beyond what the schema provides, so the baseline score 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?

  The description clearly states the specific action: removing an automated launch from a release. It also clarifies a key distinction by noting that the launch itself is not affected, which helps separate this from destructive launch deletion or removal tools.

  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 about the operation's effect, removing the association while preserving the launch. It does not explicitly name alternatives such as link_launches_to_release, but the inverse relationship is strongly implied by the phrasing and sibling tool list.

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

• update_test_caseA
  4.3/5.0
  Behavior4/5

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

  It discloses the partial-update behavior and states that the full updated case object including shareUrl is returned, which is useful beyond the annotations. The annotations already mark it as non-read-only, idempotent, and potentially destructive, and the description does not contradict those hints. It adds context without requiring the agent to infer behavior.

  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 short sentences convey purpose, behavioral nuance, return value, and a useful practical tip. There is no filler or repetition. The format is efficiently front-loaded with the essential action and semantics.

  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 tool with 9 parameters and no output schema, the description includes the key guidance: partial update behavior, current value retrieval, and return shape. Since all parameters are fully documented in the schema, the description does not need to restate them. Nothing critical about calling this tool is missing.

  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 input schema already documents each parameter clearly. The description adds no per-parameter details, which is acceptable since the schema is rich. The partial-update note adds some context for all optional fields but does not reduce the need to rely on the schema for param-specific semantics.

  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 identifies the operation ('Update an existing test case') with a specific verb and resource. 'Existing' distinguishes it from create_test_case and delete_test_case, and the scope is unambiguous. No ambiguity remains regarding what the tool acts on.

  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 gives practical usage context, especially the tip to call get_test_case first to see current values and the partial-update semantics ('only provided fields are updated'). It does not explicitly contrast with bulk_update_cases or say when to use create instead, but the guidance is clear enough for common use.

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

• update_test_collectionA
  4.3/5.0
  Behavior4/5

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

  The description reveals a material behavioral detail beyond annotations: only provided fields are updated, and omitted fields remain unchanged. This clarifies the patch semantics and prevents accidental overwrites. It complements the annotations (destructiveHint=false, idempotentHint=true) without contradicting them.

  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, both substantive. The first states the action and partial-update behavior; the second gives targeted procedural advice. No fluff, no repetition of schema content, and key information is front-loaded.

  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 a straightforward update operation with a fully described schema including enum values, the description covers the essential missing context: partial update semantics and the prerequisite call. No critical call-critical information is absent.

  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 every parameter with details. The description adds no parameter-level meaning beyond the schema. This is the baseline for high 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 states a specific action and target: 'Update test collection metadata'. This clearly identifies the operational scope and distinguishes it from siblings like delete_test_collection, create_test_collection, or update_test_case, without needing to inspect the schema.

  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 pre-use guidance: 'Use get_test_collection first to see current values.' This implies when to use the tool—when you know what you want to change and need current values first. It does not explicitly exclude alternatives, but the context is unambiguous.

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

• create_folderA
  4.4/5.0
  Behavior4/5

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

  With only default false annotations, the description carries the burden of exposing behavior. It does well by disclosing the smart type-defaulting, the parent-child constraints, and the suite leaf-node rule. It does not mention side effects like return behavior or permissions, but the important behavioral traps are covered.

  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 compact and front-loads the most important invocation detail with the 'IMPORTANT' note. Every sentence contributes either definition, hierarchy context, a default behavior, or the alias route, with no filler.

  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 plus rich schema covers creation intent, defaulting, and nesting rules thoroughly, making the tool safely selectable and callable. The only notable omission is the lack of any description of the response/return value, and there is no output schema to compensate.

  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?

  Because the input schema already covers 100% of parameters and even documents the auto-detection behavior for type and the 'suites cannot be parents' rule, the description adds little parameter-specific semantics beyond restating that context. The schema is doing the heavy lifting here.

  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 creates a folder or suite in a project and explains the structural difference: folders can nest, suites are leaf nodes. This active verb + resource pairing is unaffected, and the explicit mention of the create_suite alias helps differentiate it from a closely related sibling.

  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?

  It provides concrete, actionable usage rules: omit 'type' to use smart defaults (folder at root, suite when nested), and use the create_suite alias for suite-specific creation. This gives the agent a clear decision procedure for invoking the tool correctly and when to favor an alternative.

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

• get_feature_scanA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds non-obvious behavior: automatic hierarchy detection, 2-level aggregation (epic→story→subtask), returned test/autotest summaries, and the prerequisite that Jira be connected.

  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?

  Every sentence earns its place: the purpose, return payload, hierarchy behavior, and prerequisite are all stated without filler. The most important outcome is front-loaded before supporting details.

  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 one simple parameter, no enums, and no output schema, the description carries the burden of explaining outputs. It lists the returned groups (Jira context, coverage stats, test cases, autotest trends) and hierarchy behavior, which is sufficient for selecting and calling the tool. Exact response shape and error handling are not specified, but they are not needed for a straightforward read-only lookup.

  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% and the single parameter is already well documented. The description further explains how jiraKey is interpreted across issue types and adds hierarchical aggregation depth ('2 levels deep: epic→story→subtask'), which enriches the parameter's meaning beyond the schema alone.

  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 opens with a specific verb-resource pair, 'Get a comprehensive feature health scan by Jira issue key,' and enumerates concrete return categories, making the tool's purpose unambiguous. It also mentions hierarchy aggregation and Jira connectivity, which separates it from sibling listing/coverage tools.

  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 supplies clear invocation context: the key may be any Jira issue type, epics aggregate child issues, and Jira must be connected. It does not explicitly name sibling alternatives or state when-not-to-use, but the value is distinct enough that selection is straightforward.

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

• update_releaseA
  4.4/5.0
  Behavior4/5

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

  The description adds useful context beyond the annotations by stating that only supplied fields are changed while omitted ones remain unchanged. This disambiguates patch-style behavior from full replacement and complements the existing readOnlyHint/idempotentHint annotations without contradicting them.

  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 short, purposeful sentences. The first states the core capability and partial-update behavior; the second gives a practical prerequisite. There is no filler or unnecessary 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?

  The definition is strong for an update operation: it covers the action, the patch semantics, and the preliminary get_release recommended. It does not describe possible errors or return behavior, but with no output schema and a fully documented input schema, these omissions are acceptable 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?

  Schema coverage is complete for individual fields, but the description contributes an important cross-parameter behavior: omitted fields are preserved. This meaningfully informs how the agent should construct the request and is not fully explicit in the input 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 opens with a specific verb and resource: 'Update release metadata.' It clearly distinguishes this from create_release, delete_release, and get_release, and the following sentence clarifies that it is a partial update rather than a full replacement.

  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 tells the agent to fetch current values first with get_release, preventing accidental overwrites. It does not explicitly discuss conditions for creating a new release vs. updating an existing one, but the guidance provided is concrete and actionable.

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

• create_executionA
  4.5/5.0
  Behavior4/5

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

  Annotations indicate read/write, non-destructive, non-idempotent behavior. The description adds useful context: it aggregates several entity types, is a top-level container, is not a single run, and returns the new execution ID. It does not detail all side effects such as relationship behavior, but the essence is covered.

  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 just three sentences, all informative and sequential: definition, contrast with sibling, follow-up actions. It wastes no words and front-loads the most important disambiguating information.

  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 is complete for a creation tool: it defines the resource, explains its role in relation to test collections, lists the sibling tools needed to fully assemble the execution, and states the return value. An agent has enough context to call this correctly even without an example.

  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 every parameter is documented in the schema. The description adds no specific parameter semantics beyond the returned ID. According to the rubric, a high-coverage schema grants a 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?

  The description clearly states the resource ('Manual Test Execution', the top-level container on the Executions page) and what it aggregates. It explicitly differentiates this from Test Collection, making the tool's role unambiguous even among many siblings.

  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?

  It explicitly tells the agent when to use this tool vs create_test_collection, and names the follow-up add_* tools needed to populate it. This leaves no ambiguity about the workflow or alternatives.

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

• create_suiteA
  4.5/5.0
  Behavior4/5

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

  The annotations already cover mutability flags, so the description does not need to restate those. It adds useful behavioral context beyond the annotations: suites are leaf nodes, cannot be created at the root, and this tool is an alias rather than an independent operation. The requirement on parentId is disclosed clearly.

  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 compact and front-loaded: the core action and object type come first, followed by alias relationship, usage condition, and constraint. Every sentence contributes necessary guidance without filler.

  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 creation tool with three fully documented required parameters, the description is complete. It covers the target node type, its placement requirement, and the canonical when-to-use signal. Since no output schema exists, no return-value documentation is expected or required.

  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 input schema covers all three parameters with full descriptions, so the baseline applies. The description adds a little value by explaining why parentId is required, but it does not meaningfully extend param semantics 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 that create_suite creates a test suite, specifies it is a leaf node holding test cases, and frames it as a convenience alias for create_folder with type='suite'. This distinguishes it from the many folder-related siblings and makes the semantic of a 'suite' clear.

  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?

  The description explicitly says to use this tool when the user asks to 'create a suite', and it points to create_folder as the underlying mechanism. It also provides a key usage constraint: suites cannot live at root, so parentId is required. This gives the agent both selection guidance and a precondition.

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

• create_test_caseA
  4.5/5.0
  Behavior5/5

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

  With no annotations carrying behavioral hints, the description supplies needed transparency: it discloses auto-creation of folder/suite hierarchy, auto-creation of missing tags, safe defaults for status and priority, and the return value including shareUrl. This gives an agent a solid mental model of side effects without contradicting the 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 dense but not bloated; each sentence contributes a useful rule or scenario, and the 'IMPORTANT' note about omitting status and priority is front-loaded. It earns its length for a complex creation tool.

  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 tool with 13 parameters, no output schema, and no meaningful annotation signals, the description covers the key mental model: where cases must live, how folderId vs projectId resolve, auto-creation behavior, tag defaults, and return shape. Minor wrinkles like precedence when both folderId and projectId are passed are not necessary for the agent to correctly invoke the tool in common cases.

  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 schema already documents 100% of parameters with detailed descriptions, defaults, and auto-creation semantics. The description restates the A/B targeting choices and default behavior at a high level, but adds only marginal parameter insight 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 specific verb 'Create' and resource 'test case in a test suite', then firmly distinguishes the tool's scope with 'Test cases MUST live inside a suite (not a bare folder)'. This removes ambiguity against sibling tools like create_suite or create_folder.

  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 gives explicit when-to-use guidance by defining two valid targeting paths: folderId or projectId with optional folderName/suiteName, including auto-creation behavior. It does not explicitly name sibling alternatives like update_test_case, so it falls just short of full alternative routing.

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

• create_test_collectionA
  4.5/5.0
  Behavior4/5

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

  Annotations only convey that the tool is a non-read-only mutation. The description adds value by clarifying that it creates a single manual run, can optionally add test cases, returns the created collection with a count of added tests, and defaults priority to medium when omitted. This is helpful context beyond the 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 tight and front-loaded: it states what the tool does, then the distinction from the sibling, then return behavior and a default. Every sentence earns its place with no redundancy or filler.

  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 nine-parameter creation tool with no output schema, the description provides sufficient decision-making context: it distinguishes the object from the execution container, notes optional test-case addition, states the return value, and mentions the default priority. Combined with the rich schema, an agent can decide to use the tool 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%, so the schema already documents all nine parameters, including the priority default. The description adds high-level semantic context around the collection being a manual run and the optionality of adding test cases, but it does not significantly improve per-parameter understanding 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 a clear verb and resource ('Create a new test collection'), defines what the object represents ('a single manual run'), and explicitly differentiates it from the top-level Executions-page container. This clearly separates it from sibling tools like create_execution.

  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?

  Provides explicit routing guidance: use create_execution for the top-level container, and use add_collections_to_execution to attach this collection to an execution. This tells the agent exactly when to use this tool versus the closely related sibling.

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

• link_autotest_to_caseA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide idempotent, non-destructive, non-read-only metadata. The description adds valuable behavioral context beyond this: the autotest may not exist at link time, and the link is fully established later when the test runs. This is genuinely useful supplementary behavioral information.

  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 short, well-organized sentences. The first sentence states the action and resource, and the second sentence highlights the most important non-obvious constraint about pre-linking.

  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 two-parameter operation, the description covers purpose, parameter semantics, behavior, and an important edge case. The annotations carry the safety/idempotency details, so nothing necessary for correct invocation is missing.

  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 describes both parameters and has 100% coverage, so the baseline is 3. The description adds parameter-level meaning by clarifying that the autotest is matched by title, not by ID, and that pre-linking via testTitle is allowed even if the test does not yet exist.

  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 specific verb and resource pair: links an automated test by title to a manual test case for coverage tracking. This makes the tool's purpose unambiguous and distinguishes it from sibling linking tools like link_launches_to_release.

  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 use case is clear: coverage tracking between automated tests and manual cases, including pre-linking before the autotest exists. It does not explicitly name alternatives or exclusion criteria, but the target is distinct enough that an agent should know when this tool fits.

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

• set_execution_source_statusA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, and the description does not contradict them. It adds behavioral context by specifying that status is validated against project test_run_status values, listing defaults, and clarifying the write operates on the group level rather than the case level.

  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 compact and front-loaded with the core purpose, followed by lookup guidance, status validation details, and a sibling distinction. Every sentence carries useful information with little 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 three-parameter write operation with full schema coverage and helpful annotations, the description provides all needed context: what the resource is, where to get the ID, how status is validated, and the critical boundary against the sibling case-level tool. Nothing essential is missing.

  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 the baseline is 3. The description goes beyond the schema by explaining where to obtain runId (from get_execution sources[].id or get_execution_cases groupId) and what the status values typically are, including project-custom possibilities.

  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 a specific verb and resource: 'Set the status of one source group' inside an execution. It clarifies what a source group is and explicitly distinguishes this from setting an individual case's status by naming report_case_result. The agent can tell this apart from the broad sibling set.

  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?

  It gives clear when-to-use guidance and deliberately differentiates from the per-case tool: 'This is the GROUP status; use report_case_result for an individual case's status.' It also tells the agent where to fetch the runId and how to confirm valid status values, making the correct use unambiguous.

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

• add_cases_to_executionA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations, the description reveals important behaviors: invalid/cross-project case ids are skipped, an empty result creates no group, and the return value contains {added, skipped, groupId}. These details materially change how an agent interprets outcomes and help it detect partial failures.

  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 compact and front-loaded: the core operation and object are stated first, followed by crucial constraints and the return shape. Every sentence earns its place, with no redundant repetition of schema fields.

  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 mutation tool with no output schema, the description provides enough behavioral context: what is being added, the validity constraints, the empty-result edge case, and the return contract. The annotations already cover safety profile, so no critical guidance is missing.

  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 already 100%, but the description adds relational meaning: caseIds must map to cases in the execution's project, the name labels a group, and invalid ids cause skips. This goes beyond the schema's basic type and format 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 operation: add individual test cases to an execution as a named group, explicitly scoped to source_type cases. This distinguishes it from sibling tools like add_cases_to_collection and add_suites_to_execution without needing to open their schemas.

  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 gives clear context: use this tool when adding case-level groups to an execution, and the source_type cases qualifier signals when it does not apply. It does not explicitly name alternatives such as add_suites_to_execution, but the intended usage is still easy to infer.

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

• delete_executionA
  4.7/5.0
  Behavior5/5

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

  The description goes beyond the annotations by revealing that the deletion is soft, that it unlinks dependent runs, that it is reversible only via support/DB, and what the return value is. It also warns to 'use with care', which contextualizes destructiveHint=true without contradicting it.

  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 three short sentences with zero wasted words. Core purpose is front-loaded, then side effects, then the alternative and return shape. Every sentence contributes meaningful information for tool selection and invocation.

  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 destructive single-parameter tool with no output schema, the description fully compensates by describing the side effects, reversibility constraints, alternative behavior, and exact response shape. The idempotency is covered by annotations, so nothing material is missing.

  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 schema already covers 100% of the parameter with a clear 'Execution UUID' description. The tool description adds contextual meaning by framing executionId as identifying 'an entire Manual Execution', but it does not add new format, lookup, or validation details. This meets the baseline expectation for high 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 states a specific verb and resource: 'Soft-delete an entire Manual Test Execution'. It also explains the collateral behavior (unlinking manual runs that pointed to it), which clearly differentiates it from sibling operations like remove_source_from_execution.

  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?

  It explicitly tells the agent when not to use this tool and which alternative to choose: 'To remove just one source group instead, use remove_source_from_execution.' This provides a clear decision boundary between the whole-execution deletion and a more targeted removal.

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

• delete_folderA
  4.7/5.0
  Behavior5/5

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

  The annotations already flag destructiveHint and idempotentHint, but the description adds essential behavior beyond these: the deletion is soft/archival, recursive across nested folders and test cases, and reversible through the UI. That is concrete, useful information that the annotations alone do not provide.

  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 short sentences front-load the essential behavior ('soft delete', 'all its contents', 'recursive', 'restorable'). Every sentence carries necessary information and there is no filler or repetition.

  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 destructive tool with one fully-documented parameter and no output schema, the description fully covers the operation's scope, side effects, and reversibility. There is nothing critical missing for an agent to safely decide whether to invoke this 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?

  Since schema description coverage is 100%, the baseline is 3. The description adds meaning to folderId by explaining that identifying that folder also archives all nested folders and test cases, not just the folder itself. This reinforces the subtree-wide implication of the single parameter.

  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 starts with a specific verb and resource ('Soft delete (archive) a folder') and immediately clarifies scope ('all its contents'). It distinguishes itself from sibling tools such as delete_test_case, delete_test_collection, and update_folder by emphasizing recursive archiving of nested folders and test cases.

  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 gives clear context for when to use this tool: when a folder and all nested content should be archived, and notes that restoration is only via the UI. It does not explicitly say 'don't use this if you want permanent deletion' or point to a non-recursive alternative, but the recursive wording implies this.

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

• list_projectsA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. The description adds meaningful context about access levels, which is behavioral information beyond what annotations provide.

  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 carry the essential purpose, the recommended call order, and role-based behavior without any filler. The critical 'START HERE' guidance is front-loaded for immediate visibility.

  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 parameterless list tool, the description is complete: it states what is listed, who can see what, and what the caller should do with the results (collect project IDs). No critical information is missing despite the lack of an output schema.

  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 zero parameters, so the schema is inherently complete. The description reinforces what the tool retrieves, but no parameter-level detail is needed. Baseline 4 applies for zero-parameter tools.

  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 a specific verb ('List') and resource ('all projects accessible to the current user'), clearly distinguishing it from the singular get_project sibling. The role-based scope (admins vs. managers/users) further clarifies exactly what the tool returns.

  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?

  The description explicitly instructs the agent to call this tool first to obtain project IDs needed by other tools. It also clarifies visibility behavior per role, giving the agent the context needed to interpret results correctly.

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

• list_test_casesA
  4.7/5.0
  Behavior5/5

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

  Annotations only declare readOnly, idempotent, and non-destructive behavior, but the description adds useful behavioral facts beyond those: the response metadata offers status/priority options, each case includes a shareUrl, and the search parameter matches case numbers including with the 'TC-' prefix. This illuminates exactly how the tool behaves when invoked, more than a generic read operation would.

  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 compact, to the point, and front-loaded with the core purpose. It includes a filter summary, mentions the result metadata, and then describes the important search workflow in an actionable way. Every sentence earned its place; there is no redundant padding or tautological phrasing.

  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 10 parameters, no output schema, and a potentially ambiguous search-by-displayId workflow, the description supplies the missing operational details: response metadata, shareUrl, and the exact TC-number search mapping. It does not list every output field, but it is provided enough context for an agent to select and call the tool correctly in the common list/filter and displayId resolution scenarios.

  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?

  Since the schema already describes all 10 parameters with 100% coverage, the baseline is 3. The description adds important semantics primarily to the search parameter by explaining prefix matching and how to extract the internal id, and it gives a canonical example with 'TC-30'. It does not add detailed semantics for every filter, but the value is above the baseline.

  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 opens with 'List test cases in a project with filtering and pagination,' which names a specific verb and resource and gives the tool an unmistakable scope. It distinguishes itself from sibling list tools (list_executions, list_folders, list_projects) by the target resource 'test cases' and from the broad search_tests sibling by framing the operation as listing with filters.

  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 goes beyond 'when to call' by providing a specific workflow: pass search: 'TC-30' to map a user-facing displayId to an internal numeric id. It does not, however, mention when NOT to use this tool or call out alternatives such as search_tests or get_test_case, so no explicit exclusion is provided.

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

• remove_source_from_executionA
  4.7/5.0
  Behavior5/5

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

  The description goes well beyond the annotations by disclosing that removal is cascading ('ALL its case-run rows and step results'), that the execution itself is preserved, and that the return value is 'removed: true'. DestructiveHint and readOnlyHint in the annotations are consistent; the added detail about cascade is not available from annotations alone.

  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?

  Every sentence earns its place: purpose, cascade behavior, how to find the ID, what is not deleted, and exact return JSON. The most critical information is front-loaded and there is no filler.

  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 tool is simple, but the description prepares the agent with everything needed to call it successfully: parameter source, destructive scope, boundary of operation, and expected response. No additional missing context is required for an agent to invoke it 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?

  The schema already covers both parameters with descriptions, providing baseline. The description adds operational meaning for runId by telling the agent where to find it (get_execution or get_execution_cases) and confirms executionId as 'Execution UUID', reinforcing schema. This goes beyond simple label repetition.

  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 starts with a specific verb ('Remove') and resource ('source group... from an execution'), and clarifies what a source group is (suite, collection, or named case-group as one execution_test_run). It also distinguishes itself from delete_execution by explicitly stating 'Does not delete the execution itself.'

  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 guidance on how to obtain the required runId via get_execution (sources[].id) or get_execution_cases (groupId). It also implies the alternative of deleting the whole execution is separate, but it doesn't name that sibling or describe when not to use this tool versus other execution-modifying tools like set_execution_source_status.

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

• report_case_resultA
  4.9/5.0
  Behavior5/5

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

  Well beyond the annotations, the description discloses the auto-derivation precedence order (failed then blocked then in_testing then passed), the group roll-up rules (all not_executed → not_started; some executed → in_progress; all executed → blocked if a blocked case exists else completed), the quirk that test_run_status has no failed state, and the override lifespan semantics. No annotation contradiction — idempotentHint=true is reinforced by the stated idempotent behavior.

  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 long (~230 words), but every sentence carries load-bearing information — targeting rules, derivation order, roll-up logic, override interaction, return payload. It is front-loaded with the primary purpose and organized topically; it would only benefit from minor separation, but no sentence is wasted.

  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 9-parameter, side-effecting tool with no output schema, the description covers every decision an agent needs: how to address the case, how to set each field, how auto-roll works for the containing group, when an override sticks, and exactly what the call returns (case status, group status, steps written, progress). Nothing required for correct invocation is missing.

  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?

  Although the schema already covers all 9 parameters (100% coverage), the description adds genuinely non-obvious meaning: the precedence ordering of executionCaseId vs executionId+caseId, the groupId disambiguation condition, the "auto" derivation algorithm, and the omit-to-leave-unchanged behavior. These cross-parameter semantics live only in the description.

  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 a specific verb and resource — "Record the result of running one case inside a Manual Test Execution: set per-step pass/fail and/or the case status" — and immediately distinguishes itself from siblings like update_execution and set_execution_source_status by scoping to a single case's results with atomic/idempotent semantics.

  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?

  It provides explicit targeting guidance: use executionCaseId (from get_execution_cases) as preferred, fall back to executionId + caseId, and pass groupId if the case is in several groups. It also tells the agent when to supply status explicitly, when to use "auto", and when to omit it, and explicitly references the set_execution_source_status sibling to explain how its override interacts with the automatic roll-up.

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

• update_executionA
  4.9/5.0
  Behavior5/5

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

  Beyond the annotations, the description adds meaningful behavioral context: status values are project-configurable, setting status follows a during/after pattern, and releaseIds is a replace-all operation. It also warns that this tool does not modify case results, which is important behavioral information not captured by 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 compact and well-structured: it opens with the tool's core purpose, immediately gives the key status workflow, and then clarifies alternative tools. Every sentence carries operational value, with no wasted 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?

  For a tool with 10 parameters, no output schema, and meaningful behavioral traps like replace-all release links and project-custom statuses, the description covers all critical operational needs. It also references the exact sibling tools an agent might confuse it with and provides a concrete fallback for discovering valid status values.

  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 already covers 70% of parameters with descriptions, and the description adds practical semantics on top: status should be in_testing while running and passed/failed/blocked when done, and releaseIds replaces the entire release-link set. It does not elaborate on every param interpretation, but the added guidance is valuable.

  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 a specific verb ('Update'), a specific resource ('a Manual Test Execution's own fields'), and distinguishes the tool from sibling operations by explicitly saying it does not change case results. It is instantly clear what this tool is for and what it is not for.

  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?

  The description provides explicit usage guidance: use this for execution-level fields and status, use report_case_result for case results, and use set_execution_source_status for source group status. It also instructs calling get_project to confirm project-specific status values rather than hardcoding.

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