qa-touch-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target a distinct resource and action, but the five test-result tools (update_test_result, update_test_result_steps, update_test_results_multi, bulk_update_test_results, add_test_result) have closely related purposes and rely on dense descriptions to differentiate them. A few pairs like get_test_case/get_test_case_steps also overlap slightly, though the descriptions clarify their intent.
Naming Consistency4/5
Names follow a consistent verb_noun pattern in snake_case (list_, get_, create_, update_, clone_), which is predictable and readable. Minor inconsistencies exist: bulk_update_test_results vs update_test_results_multi encode the same bulk concept in different positions, and add_test_result vs update_test_result could be more clearly distinguished.
Tool Count2/5
At 32 tools, the server exceeds the 25+ threshold and feels heavy for an agent to navigate. Many tools are narrowly scoped, such as the five result-update variations, and some read-only conveniences like list_test_plans and list_workspaces could potentially be merged or trimmed.
Completeness3/5
The server covers core QA workflows well: projects, releases, test runs, test cases, modules, requirements, and defects all have create/list/get capabilities. However, there are notable gaps: no update/delete for projects, releases, test runs, modules, or defects, and test plans only support listing, so lifecycle workflows can dead-end.
Average 3.8/5 across 32 of 32 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the creation action and does not mention side effects, required parent existence, idempotency, permissions, or what the response contains. 'Create' implies mutation, but little else is revealed.
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 concise sentence with no filler, and the core action is front-loaded. It is efficient, though it omits useful context that could have been included without much extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter create tool, the schema and description together provide enough information to invoke it with the required fields. However, with no annotations and no output schema, the description leaves return behavior, prerequisites, and sibling-tool relationships unspecified, making it only minimally 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 each parameter is already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, so it meets the baseline but does not exceed it.
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 specific verb ('Create') and resource ('new requirement document') plus the scoping context ('in a project under a release'), so the primary purpose is clear. It does not explicitly differentiate from the sibling create_requirement, but the word 'document' provides some distinction.
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?
There is no guidance on when to use this tool versus alternatives like create_requirement or create_release. The intended context is implied by the description, but no explicit when-to-use, exclusions, or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'List the defects of a project' without disclosing pagination behavior, response format, or whether all defects are returned. The 'page' parameter implies pagination, but the description does not explain it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the verb and object. It is efficient, though it sacrifices potentially useful detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is minimal but arguably sufficient to indicate it returns defects for a project. However, no output schema and no mention of default page behavior leave gaps for an agent deciding how to 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?
The schema covers both parameters with descriptions (projectKey and page), so the description adds no additional parameter semantics. With 100% schema coverage, the description does not need to compensate, but it also provides no extra value.
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 the specific verb 'list' and resource 'defects', scoped to 'a project'. This clearly states what the tool does, though it does not explicitly differentiate it from siblings like get_defect_metadata or list_requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention exclusions or conditions for choosing list_defects over list_requirements or get_defect_metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It only states that releases are listed, but does not disclose pagination behavior, ordering, returned fields, or read-only guarantees. The page parameter exists in the schema but is not described in the tool description.
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 sentence with no filler or redundant phrases. It is appropriately short for a simple list tool, though it closely mirrors the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter list tool, the description plus schema covers the essential call information. However, with no output schema and no behavioral notes, an agent does not know what the response will contain or how pagination behaves beyond the schema's minimal page description.
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 both projectKey and page already described. The description adds only the project scoping phrase, which maps to projectKey. It does not provide additional meaning beyond the schema.
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 specific operation (List) and resource (releases/milestones) scoped to a project. This distinguishes it from sibling tools like create_release and list_projects, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool versus alternatives such as create_release or other list tools, nor does it mention exclusions or preconditions. The only implicit signal is the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. The word 'Get' implies a read operation, but the description does not state that it is non-mutating, what fields 'detail' includes, or how missing or invalid keys are handled.
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. Every word contributes to identifying the operation and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter retrieval tool, the description plus schema is nearly adequate, but the lack of an output schema and the existence of similar sibling tools like get_test_run_metadata leave some ambiguity about what 'detail' actually contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both projectKey and testRunKey described in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 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 states a specific verb ('Get'), a specific resource ('a single test run'), and the nature of the result ('detail'). It clearly distinguishes from list-style siblings like list_test_runs, though it does not explicitly differentiate from get_test_run_metadata.
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?
There is no guidance about when to use this tool versus the closely related get_test_run_metadata or list_test_runs. The description implies a lookup by key, but provides no context about intended use cases, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It only states listing and optional name filtering; it does not mention pagination behavior, ordering, result scope, or response characteristics. There is 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 concise sentence with no filler. It front-loads the action and resource, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all parameters, so invocation is workable, but with no annotations and no output schema, the description omits useful context such as pagination semantics and how this tool relates to sibling list/get tools. It is minimally viable but not rich.
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 describes all three parameters with 100% coverage. The description's 'optionally filtered by name' restates the name parameter but adds no meaningful detail beyond the schema.
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 'List' and the resource 'test runs of a project', with an optional name filter. It is specific enough to understand the tool's purpose, though it does not explicitly distinguish it from siblings like list_test_run_results or get_test_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus get_test_run, list_test_run_results, or other sibling tools. The description implies collection-level listing but offers no exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries full behavioral burden. It discloses only that a project is created, but does not mention side effects, persistence, permission requirements, or response behavior. There is no contradiction, but little behavioral context.
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 short, front-loaded sentence with no filler or redundancy. Every word contributes to identifying the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no nested objects, and the schema covers the parameter. However, with no annotations or output schema, the description leaves gaps around preconditions, uniqueness, and response format, though the core operation is clear.
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 'name' is already described in the schema as 'Name of the project to create'. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
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 ('Create'), a specific resource ('a new project'), and the domain ('QA Touch domain'). It is clearly distinguishable from sibling create_* tools because the resource is explicitly 'project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_projects or create_release. There is no mention of checking for existing projects, required permissions, or appropriate contexts; usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the behavioral burden, but it only restates the basic create action. It does not mention duplicate-name handling, permissions needed, whether the operation is idempotent, or what side effects occur. This is a minimal description with no additional behavioral disclosure.
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 includes the core action plus a clarifying parenthetical and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two fully documented parameters, so the schema covers invocation basics. However, with no output schema and no annotations, the description omits expectations about return values and edge cases such as duplicate releases. For a mutation tool, a bit more context would be needed for a higher score.
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 both projectKey and milestone. The description adds no parameter-specific details beyond naming the resource. 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 states the specific action ('Create') and target resource ('release (milestone)') and scopes it to a project. This makes it clearly distinct from sibling create tools aimed at projects, tests, modules, defects, etc. It does not confuse it with list_releases because the verb differs.
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?
There is no guidance on when to choose this tool over alternatives such as list_releases, or on any prerequisites like requiring an existing project. The only signal is the generic action in the description, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that status is updated and a comment is optional, but it doesn't say whether an existing comment is replaced or appended, whether status transitions are validated, or what side effects or response occur after the update.
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. Every word contributes to identifying the operation, the scope, and the optional comment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with fully documented parameters, the description is minimally adequate, but it doesn't mention return behavior, permissions, or how this tool relates to the update_test_result_steps and bulk_update_test_results siblings. Some of that burden falls on context, but additional description would make selection safer.
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 five parameters, including that resultKey comes from list_test_run_results. The description adds no parameter meaning beyond 'status' and 'optional comment,' so the baseline of 3 applies.
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 the status') and resource ('a single test run result'), and the 'single' qualifier distinguishes it from bulk_update_test_results and update_test_results_multi. It also implies the scope is status, not steps, helping separate it from update_test_result_steps.
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 word 'single' implies this tool is for one result rather than bulk operations, but there is no explicit when-to-use guidance or reference to sibling alternatives such as bulk_update_test_results or update_test_result_steps. An agent must infer the boundary from the schema and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It reveals multi-result targeting, accepted attachment formats, the 2 MB size limit, and the CASE key alias. It does not disclose whether existing results are overwritten, what effects occur on partial failures, or any permission/authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core action appears first, followed by a single dense sentence of key constraints. Every element earns its place, including the file-format list, which directly affects call success.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema already covers parameter names and the status enum, and the description adds key-sourcing and file constraints. But with no annotations and no output schema, the description should do more to explain when to use this tool versus the nearby update/bulk tools and what happens to pre-existing results.
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, but the description adds meaningful detail: result keys originate from list_test_run_results, CASE-prefixed case keys are accepted, and file types plus the 2 MB per-file cap go beyond the schema's generic 'local file paths' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Add a result to one or more test run results') and the payload contents (status, comment, time spent, attachments). It is clear and self-contained, though it does not explicitly differentiate itself from sibling tools like update_test_result or bulk_update_test_results.
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 useful invocation guidance by pointing to list_test_run_results as the source of result keys and noting that CASE-prefixed case keys are accepted. However, it does not explicitly say when to prefer this tool over update_test_result, bulk_update_test_results, or update_test_result_steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses exactly what the response contains (mapped test runs with status, custom field values, step descriptions with expected results), and the 'get' verb makes the read-only nature clear. It does not discuss edge cases like not-found or permissions, but those are minor for a simple getter.
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?
A single efficient sentence that front-loads the action and resource, then lists the returned components in a colon-delimited list. There is no redundant 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?
For a simple getter with two required keys, no output schema, and no annotations, the description gives enough context about the returned detail to make a call. It could be slightly more complete by pointing to get_test_case_steps for step-only needs, but for its primary purpose it is sufficient.
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 caseKey and projectKey are already documented in the schema. The description adds no additional semantic meaning for the parameters, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Get'), the resource ('a single test case'), and the returned content (mapped test runs with status, custom field values, step descriptions with expected results). It is specific enough to distinguish from list-style siblings, though it does not explicitly differentiate from get_test_case_steps.
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 about when to choose this tool over alternatives. It implies usage for a full test-case detail but does not mention when list_test_cases or get_test_case_steps would be more appropriate, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It indicates a mutation operation but does not explain effects such as whether existing step statuses are overwritten, whether permissions are required, what happens on partial failure, or what the response contains.
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 purposeful. The action is front-loaded, and the second sentence provides a valuable pointer to the source of the step result keys without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all parameters, and the description provides the essential prerequisite for stepResultKeys. However, with no annotations and no output schema, the description could do more to explain the operation's effects, limits, or expected response, especially given the number of sibling update tools.
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 describes all parameters with 100% coverage, so the baseline is 3. The description adds meaningful context by explaining that stepResultKeys come from get_test_case_steps, which clarifies how to obtain the array values and ties the tool to its prerequisite.
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: updating the status of one or more steps in a test run case. It is specific about the resource, though it does not explicitly differentiate from sibling tools like update_test_result or bulk_update_test_results beyond the word 'steps'.
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 useful guidance by noting that step result keys come from get_test_case_steps, which tells the agent where to obtain required inputs. It does not explicitly state when to prefer this tool over alternatives such as update_test_result, but the step-focused scope is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It transparently conveys the creating behavior and the parent-child nesting relationship, but it omits consequences such as validation of projectKey/parentKey, duplicate-name behavior, or the shape of the created module response.
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 with the core action front-loaded and the optional nesting behavior placed second. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with fully documented parameters, the description covers the essential inputs and the one optional behavior. It lacks an output schema and does not describe return values or failure modes, so an agent cannot fully predict the result or error expectations.
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 three parameters are already self-documenting. The description reinforces the parentKey nesting semantics but adds no substantial meaning beyond the schema's 'Existing module key to nest under.'
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 ('create') and resource ('module (section)') and clarifies scope ('for test cases in a project'). The optional parentKey detail distinguishes it from sibling creation tools like create_release or create_project.
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 an explicit conditional for nesting ('Pass parentKey to create it as a child of an existing module'), which tells when the third parameter is relevant. It does not state when create_module should be preferred over sibling tools or provide any when-not/exclusion guidance; usage context is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure burden. 'Get' clearly indicates a read operation, and the description lists what data is returned. However, it does not disclose response shape, error behavior, permissions, or whether any non-obvious side effects exist, leaving some ambiguity for an agent.
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?
A single, front-loaded sentence that states the action, scope, and key output contents with no wasted words. Every element 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?
This is a simple one-parameter read operation, and the description adequately conveys the purpose and included counts. The lack of an output schema or explicit usage guidance is a minor gap, but the schema note 'from list_projects' helps the agent know how to obtain the key.
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%: projectKey is documented as 'Project key (from list_projects)', which is sufficient guidance. The tool description adds no extra parameter-level meaning beyond that, so the high schema coverage sets the baseline at 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 specifies a clear verb and resource: 'Get a single project's detail' and enumerates the included counts (test case, test run, defect, milestone release counts). This distinguishes it from list_projects (multiple projects) and create_project (mutation) 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'single' implies this is for fetching one project rather than listing all, and the parameter description references list_projects as the source of the key. However, the description itself does not explicitly state when to use this tool versus list_projects, nor does it mention any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly communicates the core side effect: a new requirement is created under a document. However, it does not mention prerequisites, error behavior, permissions, or the response shape.
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 redundant filler. It states the action and the parent context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward create tool, the description is minimally adequate, but with no output schema or annotations it leaves open questions about what the tool returns and what happens if the referenced document does not exist. It provides enough to attempt a call but not full guidance.
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 parameters. The description adds no parameter-level details beyond the schema, matching 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 states a specific action ('Create a new requirement'), a resource ('requirement'), and a parent context ('under a requirement document'). This clearly differentiates it from siblings like create_requirement_document and list_requirements.
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 phrase 'under a requirement document' gives clear context that this tool is for adding a requirement to an existing document, not for creating documents or projects. It does not explicitly name alternatives or exclusions, but the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does state the mutation effect: creating a test run and selecting test cases by scope. However, it does not disclose return behavior, output format, permissions, idempotency, or error conditions, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: one clear purpose sentence followed by a minimal checklist of scope behaviors. Every line adds meaningful value and the central scope logic is front-loaded.
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 the nine parameters and lack of annotations, the description plus schema make a basic invocation constructible. However, with no output schema and no annotations, the description omits expected return values, prerequisites, and alternative-tool routing, which are important for full completeness.
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 explicit dependency mapping beyond the schema by clarifying that caseIds are required for scope=cases and moduleKeys plus an optional mode are required for scope=modules, which helps construct valid requests.
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 'Create a test run in a project', naming a specific action and resource, then clarifies the three scope modes. This clearly distinguishes it from siblings like create_test_case and clone_test_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope bullet list gives useful guidance on when to use each scope option, such as caseIds for scope=cases and moduleKeys for scope=modules. However, it never names alternatives or exclusion conditions, so an agent must infer how this tool relates to clone_test_run or create_test_case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It correctly communicates a read-only listing operation and an optional name filter, but it does not disclose details such as pagination, result ordering, whether the filter is exact or substring, or what fields each test plan includes.
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?
A single sentence that is front-loaded with the core action and scope, then adds the optional filter. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, simple list operation the description is minimally viable. However, since there is no output schema and no annotations, missing details like return shape, pagination behavior, and filter semantics leave gaps for an agent that needs to consume the results.
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 parameters are already documented. The description only restates the project scope and optional name filter without adding new semantic detail beyond what the schema 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 verb ('List') and resource ('test plans') with a clear scope ('of a project') and an optional filter. This distinguishes it from sibling list tools like list_test_runs or list_projects without needing to open 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?
It provides clear context: use this tool when you need test plans belonging to a project, optionally narrowed by name. It does not explicitly mention alternatives or exclusions, but the resource-based naming makes the intended use unambiguous among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: 'All cases in the new run start as Untested.' However, there are no annotations, so the description carries the full burden. It does not mention whether the original run is modified, what permissions are needed, or what the response contains, leaving some behavioral uncertainty.
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 action and purpose are front-loaded, and the additional behavioral detail 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 relatively simple tool with three fully described required parameters, the description covers the essential purpose and a critical post-condition. It is complete enough for an agent to select and invoke the tool, though a note about the response payload would make it stronger.
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 all three parameters. The description adds no extra parameter-level meaning, which is acceptable 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 and resource: 'Clone an existing test run.' It clearly distinguishes itself from create_test_run by emphasizing that it clones an existing run rather than creating from scratch, and 'for re-testing' adds a concrete use 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 phrase 'for re-testing' provides clear context on when this tool should be used. It does not explicitly name alternatives or exclusions, but the intended usage is evident from the first sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It usefully reveals request limits and file size constraints, but does not state what happens on invalid CSV format, whether a partially valid batch is imported, or whether existing test cases are affected. This is acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, the required format, and the two main constraints with no filler. The most important operational limits are front-loaded, making the definition easy to scan.
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 tool with a fully documented schema and no output schema, the description is largely complete. It could add expected result behavior or error handling, but an agent can reasonably invoke this tool based on the provided 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?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that filePath is a local CSV and that projectKey identifies the target project, but adds no parameter-level detail beyond the schema. It does not exceed 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 specifies a clear verb ('import'), a resource ('test cases'), a destination ('into a project'), and a source format ('local CSV file'). It also names the specific QA Touch sample format, which distinguishes this from generic import tools and from sibling create_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 clearly frames this as a bulk import tool and provides concrete usage constraints (max 100 test cases, max 2 MB). It does not explicitly name alternatives like create_test_case for single inserts, but the bulk-vs-single distinction is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It conveys a read-only listing and the effect of includeCounts (hierarchical module/submodule test case counts), but does not mention pagination, ordering, error behavior, or the potential cost of count fetching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose is front-loaded, and the optional-count behavior is explained in the second sentence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool without an output schema, the description gives enough to select and call it correctly: resource scope, required project context, and the optional flag. It does not document output fields or error cases, but the complexity is low and the schema covers parameters fully.
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 both parameters. The description adds 'hierarchical' to the includeCounts behavior and clarifies modules as 'sections,' but it mostly restates the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'List the modules (sections) of a project.' This clearly distinguishes list_modules from sibling tools like list_projects or list_test_cases, and the optional includeCounts behavior is identified.
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 context is clear: use this tool to retrieve a project's modules, optionally with hierarchical submodule test case counts. It does not explicitly name alternatives or exclusion conditions, but the scope ('of a project') makes the use case apparent against the sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one behavioral nuance—that includeDocuments also returns the requirement documents—and the verb 'List' implies a read-only operation. It does not mention pagination behavior, ordering, response format, or potential side effects, but for a simple listing tool this is moderately 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?
Two short sentences with no filler. The core action is front-loaded, and the optional flag behavior is stated in a second clause. 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 3-parameter list tool, the description plus fully documented schema covers the necessary calling information: required projectKey, optional includeDocuments, and optional pagination. It does not detail output structure, but the description at least indicates what is returned (requirements and optionally documents). Without annotations or an output schema, a bit more detail on response shape or defaults could help, but it is not critically 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 adds value for includeDocuments by explaining that it 'also return[s] the requirement documents they are organized under,' clarifying the relationship between requirements and documents beyond the schema's simple boolean description. No additional insight is given for page or projectKey, but the schema already describes them adequately.
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: 'List the requirements of a project.' This clearly identifies the tool's function and distinguishes it from siblings like list_projects or create_requirement. The optional includeDocuments clause adds relevant scope without confusion.
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 tool is for retrieving a project's requirements and optionally its documents, so basic usage is clear. However, it does not explicitly discuss when to choose this tool over alternatives or mention any exclusions or prerequisites beyond the implicit need for a project key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It usefully discloses optional file attachment behavior, allowed file extensions, and the 2 MB per-file limit, and it exposes the dependency on defect metadata. However, it does not mention authentication or write-permission requirements, whether the operation is reversible or idempotent, or what type of response the caller should expect 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 three sentences with no redundancy: action, prerequisite lookup, and optional attachment constraints. The most important selection information is front-loaded in the first sentence, and every sentence contributes information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient to select the tool and understand the main input constraints, but with no output schema and no annotations it should state what a successful creation returns, such as a defect key or ID. It also leaves the required issueSummary parameter undescribed in the text, relying on the schema and the agent's inference from the word 'defect.'
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?
Even with high schema coverage, the description adds real value beyond the input schema by constraining filePaths to a concrete allowed-format list and a 2 MB per-file size cap that the schema does not specify. It also confirms priority values should come from get_defect_metadata. It does not elaborate on issueSummary, but the schema lists it as required.
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 action verb and resource: 'Create a new defect in a project.' This clearly distinguishes it from sibling creation tools like create_test_case, create_requirement, or create_module, while adding the project scoping that the bare title lacks.
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 context for when to use the tool is clear from 'Create a new defect in a project,' and the description explicitly directs the agent to consult get_defect_metadata for valid priority values before invoking. It does not enumerate exclusions such as 'do not use for requirements,' but the resource-focused wording gives sufficient routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does add valuable behavior about template-dependent requirements (featureScript required for bdd, stepsTemplate required for steps), but it does not mention permissions, side effects, return values, or behavior on missing/existing keys. The core behavior 'create a test case' is implied by the name and description, but operational expectations are incomplete.
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, opening with the primary action and then using a bulleted list for template variants. Every sentence adds information, and the conditional requirements are front-loaded rather than buried in prose.
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 12 parameters and no output schema or annotations, the description covers the most critical selection logic (template styles and their required fields) but leaves some operational context implicit, such as where projectKey/sectionKey come from and what the tool returns. The parameter schema covers individual field meanings, so the missing context is moderate rather than severe.
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 earns an extra point by explaining how the `template` enum maps to specific parameters and conditional requirements, which the schema alone does not fully convey. The minor use of snake_case `expected_result` versus the schema's `expectedResult` introduces slight ambiguity but does not seriously undermine the added 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 clearly states a specific verb and resource: "Create a test case in a module (section)." It enumerates the four template styles, which gives immediate, concrete meaning to the tool's purpose and distinguishes it from update/read/module tools. The creation scope and template variants are 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 establishes clear context: use this tool to create a test case in a module, and select a template style. It does not explicitly name alternatives such as update_test_case or create_requirement, nor does it provide when-not-to-use guidance. However, the creation semantics and template routing make the appropriate use fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. The verb 'List' clearly signals a non-mutating read operation, and the parenthetical defines the scope. No hidden side effects are present for a parameterless listing tool, though output shape and pagination are not described.
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. The action is stated first, and the clarifying phrase '(groups/teams)' adds useful disambiguation without bloating the 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?
For a parameterless list operation without an output schema, the description is largely sufficient: it names the resource, defines what workspaces are, and implies a list return. It could be more complete by noting how workspace listing relates to project listing, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there is no parameter detail for the description to add. Per the rubric, zero-parameter tools receive a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' plus the resource 'workspaces' and immediately clarifies the domain meaning as 'groups/teams'. This makes it clearly distinct from sibling list_* tools such as list_projects, list_releases, and list_test_runs, which target different resources.
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?
There is no explicit guidance about when to use this tool versus alternatives. The description implies it should be used whenever a list of workspaces is needed, but it does not state exclusions or compare it with sibling list tools such as list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does add meaningful detail: 'Only provided fields are sent' reveals partial-update behavior, and the template-requirement note clarifies valid input combinations. It does not discuss permissions, reversibility, or response shape, but the core mutation 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 sentences with no wasted words. The action is front-loaded, and the critical conditional requirements are stated directly after the main purpose.
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 14-parameter mutation tool with no annotations or output schema, the description covers the most important behavioral logic: partial updates and template-specific mandatory fields. The required identifiers are documented in the schema, and the description is sufficient for an agent 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.
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 adds value by explaining cross-parameter constraints (template must match featureScript/stepsTemplate) and partial-update semantics, which individual property descriptions do not fully convey.
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 ('Update') and resource ('an existing test case'), which clearly distinguishes it from create_test_case and other sibling tools. The 'existing' qualifier makes the target 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?
Implies use when a test case already exists and needs modification, but does not explicitly say when to prefer this over create_test_case or get_test_case. The description provides conditional template guidance but no direct alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the tool works across two case types and that returned step result keys are meaningful for subsequent status updates. It doesn't describe pagination or error behavior, but for a simple read operation the key behavioral traits 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?
Two compact sentences deliver all essential information with no filler. The primary purpose is front-loaded, and the secondary behavioral detail about step result keys is placed usefully in the second sentence.
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 getter with no output schema, the description adequately explains what the tool does, what it returns (steps with description and expected result), and why the result is useful (step result keys). Nothing required to invoke the tool correctly 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 input schema already documents the single parameter (caseID) as 'Test case ID / key' with 100% coverage. The description adds a slight nuance by implying caseID can refer to either a test case or a test run case, but this is not expressed explicitly, so the description adds only marginal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('the steps of a test case'), and it clarifies what each step contains ('description + expected result'). It also distinguishes its scope by noting it works for both test cases and test run cases, which sets it apart from related getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: it applies to both test cases and test run cases. It also hints at the follow-up workflow by stating that step result keys are used for step-level status updates, implicitly routing the agent toward update_test_result_steps afterward, though it doesn't explicitly mention that sibling or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a read-only metadata retrieval operation and explains the conditional behavior based on `kind`. It does not discuss authentication or output shape, but those are not critical for a simple metadata fetcher.
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, no filler, with the main purpose front-loaded and the parameter behavior following immediately. Every sentence 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?
The tool is simple: one optional parameter, no output schema, no nested objects. The description covers the invocation variants and enumerates what will be returned, which is sufficient for a correct call. A more explicit return format would be nice, but 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% and the schema already documents `kind` with an enum and a default of all. The description adds value by explicitly explaining the behavioral difference between passing a kind and omitting it, reinforcing and slightly extending 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 opens with a specific verb and resource, 'Get the available defect statuses, severities, priorities, issue types and environments,' and enumerates exactly what the tool returns. This clearly distinguishes it from sibling tools like list_defects or get_test_run_metadata.
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 instructions: pass `kind` for a single list or omit it for all five. It does not name alternatives, but no alternative sibling provides the same metadata, so the guidance is clear enough for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral transparency. It discloses the pagination behavior (50 per page), the pagination metadata returned (current_page, last_page, total), and how to navigate pages. It does not explicitly state side effects, but 'List' clearly indicates a read-only 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?
The description is compact and front-loaded with the core purpose ('List projects'), followed by concise pagination details. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter list tool, the description covers the domain, pagination behavior, page parameter usage, and response metadata. The main gap is that it does not describe the shape of the project records themselves, and there is no output schema to compensate; however, the core invocation details are sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents `page` with a default and minimum, so schema coverage is 100%. The description adds value by explaining that `page` is used to fetch subsequent pages and that pagination is 50 per page, going beyond the bare schema definition.
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 ('List projects'), scopes it to the QA Touch domain, and is clearly distinct from the sibling tools create_project and get_project. An agent can immediately understand what action this tool performs.
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 the tool: to list projects with pagination, and to pass the `page` parameter to fetch subsequent pages. It does not explicitly mention alternatives or exclusions, but the usage context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses API-enforced filter exclusivity, pagination size, and the view/mode coupling, which are non-obvious behaviors an agent needs before calling. It stops short of describing response shape or ordering, but covers the important constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each carrying distinct value: purpose, pagination, filter constraint, and the special view behavior. No filler and the key limitations are front-loaded right after the one-line purpose.
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 7-parameter list operation with no annotations or output schema, the description covers the main call-shaping behaviors and pagination. It doesn't describe the fields returned in the list payload, but that is a minor omission for a list tool whose name already signals the result type.
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 adds relational semantics beyond the schema by warning that multiple filters are rejected and that view only works with mode. This helps an agent construct a valid request.
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?
Opens with 'List test cases for a project,' identifying a specific verb, resource, and scope. This clearly distinguishes it from sibling tools like list_projects, list_test_runs, and list_defects, and the title isn't merely restating the name.
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?
Gives concrete usage constraints: pagination at 50 per page, at most one of four filters because the API rejects multiples, and view: "count" being valid only with mode. It does not explicitly name an alternative tool for single test case retrieval, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It explains the caseFormat behavior with concrete examples, documents format-dependent support for comments/timeSpent, and discloses the reason behind the batch-size recommendation. It does not describe return values or failure behavior, but the core constraints are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose, and uses a clear bulleted list for caseFormat variants. Each sentence contributes useful information: the multi-result behavior, status mapping, format semantics, and batch-size guidance. There is no filler or redundant prose.
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 6-parameter mutation tool with no annotations and no output schema, the description covers the essential invocation requirements: required fields, status semantics, case identifier formats, and batch-size constraints. It could be more complete by explicitly disambiguating from bulk_update_test_results, but nothing critical is missing for constructing a valid request.
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 adds meaningful value beyond the schema by giving concrete caseFormat examples ('MNe7x', TR0029 → '29', TR0028) and clarifying which parameters apply only under the 'code' format. This helps an agent construct valid inputs more confidently.
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: update several test run results in one call, each with its own status. The phrase 'each with its own status' distinguishes it from single-result updates and from bulk updates that might imply a single shared status, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when updating multiple test run results with individual statuses. It also gives practical batching guidance ('~20') due to URL length limits. It does not explicitly name sibling tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral constraints: run mode is 'status only', moduleKeys and caseCodes are conditionally required, and assignee is only for modules/cases. It does not disclose failure semantics, return format, or irreversibility, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. The core action is front-loaded, the three modes are presented as scannable bullets, and the alternative tool is mentioned in a single closing line. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Required parameters are in the schema, and the description adds conditional requirements, mode restrictions, and an example case code (TR001). The only notable gaps are the lack of return-value information and potential partial-failure behavior, which would be helpful for a bulk operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, but the description adds significant meaning beyond it. It explains the `by` enum through concrete modes, states conditional requirements (moduleKeys required for modules, caseCodes for cases), and clarifies that assignee applies only to modules/cases. This is crucial information not obvious from 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 clearly states the action: 'Set one status (and optionally assignee/comment) across many results of a test run.' It further clarifies scope with three well-defined modes (run, modules, cases). It explicitly distinguishes itself from the sibling update_test_results_multi, so an agent can easily tell them apart.
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 routing guidance: 'For per-case different statuses use update_test_results_multi instead.' It also explains when each `by` mode applies and which parameters are required for modules and cases. It does not mention the single-result alternative update_test_result, but the bulk nature is evident from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' and the enumerated outputs make clear this is a read-only metadata retrieval, and it adds useful context about the numeric status IDs being used by bulk update endpoints. It does not discuss auth, response shape, or error conditions, but for a simple read operation the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the primary purpose and then explains the optional extension. Every sentence earns its place.
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 has low complexity: one optional parameter, no nested objects, and no output schema. The description covers what is returned, the relevant use case, and the parameter's effect, which is sufficient for an agent 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single optional parameter already has a clear description in the schema. The tool description reinforces the conditional behavior: passing projectKey also fetches assignable users. This adds meaning beyond the raw schema by explaining the effect of including the 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 states a specific verb and resource: it retrieves available test run statuses, including names and numeric IDs used by bulk update endpoints. This clearly distinguishes it from get_test_run (which returns run details) and list_test_runs (which lists runs). It also reveals the optional assignable-users behavior tied to projectKey.
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 it to obtain test run statuses, especially the numeric IDs needed for bulk update endpoints. It also explains the conditional use of projectKey to fetch assignable users. It does not explicitly name alternative tools or state when not to use it, but the purpose is specific enough that an agent can decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It discloses that `run` mode is paginated at 100 per page, that `release` supports an optional status filter, and which parameters are required for each source. It does not mention return shape or authentication, but no destructive or surprising behavior is suggested.
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-organized. The opening sentence states the core action, then a tight bullet list explains each mode without repetition or fluff. Every sentence 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?
Given the four modes and eight parameters, the description covers all required parameter combinations, optional filters, pagination, and source selection semantics. The main gaps are the absence of return-value shape details and an explicit read-only statement, but these are secondary for a listing operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds substantial meaning: it specifies which parameters must be combined for each `source`, which fields are optional, and that `run` paginates at 100 per page. This turns a flat parameter list into a usable mode-based decision matrix.
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 ('List test run results') and then disambiguates the four lookup modes via `source`. It clearly differentiates itself from sibling tools like list_test_runs by describing result-level lookups and required key combinations.
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 maps each `source` value to its required and optional parameters, making it clear which mode to use and what to pass. It does not explicitly name sibling alternatives like list_test_runs, but the mode breakdown provides sufficient context for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![qa-touch-mcp MCP server](https://glama.ai/mcp/servers/Darshitpipariya/qa-touch-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Darshitpipariya/qa-touch-mcp)

Score Badge

Copy to your README.md:

[![qa-touch-mcp MCP server](https://glama.ai/mcp/servers/Darshitpipariya/qa-touch-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Darshitpipariya/qa-touch-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Darshitpipariya/qa-touch-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server