Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Link Issues to Testcase Run

qmetry_link_issues_to_testcase_run

Link issues to a QMetry testcase run to associate defects with test executions and maintain traceability.

Instructions

Link one or more issues to a QMetry Testcase Run (execution).

Toolset: Issues

Parameters:

  • projectKey (string): Project key - unique identifier for the project (default: "default")

  • baseUrl (string): The base URL for the QMetry instance (must be a valid URL)

  • issueIds (array) required: ID of issues to be linked to Testcase Run

  • tcrId (number) required: ID of Testcase Run to link issues with. CRITICAL: parameter name is 'tcrId' — do NOT use 'tcRunId', 'testCaseRunId', or other variants. Accepts a string or number.

Output Description: JSON object with linkage status and details.

Use Cases: 1. Link a single issue to a testcase run 2. Link multiple issues to a testcase run 3. Automate defect association during test execution 4. Maintain traceability between defects and test runs

Examples:

  1. Link one issue to a testcase run

{
  "issueIds": [
    "5054834"
  ],
  "tcrId": 567890
}

Expected Output: Issue 5054834 linked to testcase run 567890 successfully.

  1. Link multiple issues to a testcase run

{
  "issueIds": [
    "5054834",
    "5054835"
  ],
  "tcrId": 567890
}

Expected Output: Issues 5054834, 5054835 linked to testcase run 567890 successfully.

Hints: 1. if you have pass issue key (VT-IS-5, MAC-IS-10 etc.) then first fetch issue by issue key to get issue id. 2. To get the issueIds, call the Fetch issues linked with testcases tool and use data[].defectID from the response. 3. To get the tcrId, call the Execution/Fetch Testcase Run ID tool and use data[].tcRunID from the response. 4. Both issueIds and tcrId are required. 5. You can link multiple issues at once by providing an array of IDs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tcrIdYesID of Testcase Run to link issues with. CRITICAL: parameter name is 'tcrId' — do NOT use 'tcRunId', 'testCaseRunId', or other variants. Accepts a string or number.
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
issueIdsYesID of issues to be linked to Testcase Run
projectKeyNoProject key - unique identifier for the projectdefault
Behavior4/5

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

Annotations already indicate readOnlyHint=false (write operation). The description adds that the output is a JSON object with linkage status and details, and includes critical warnings about parameter naming ('tcrId'). It does not contradict annotations and provides useful behavioral context beyond the schema.

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

Conciseness4/5

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

The description is well-organized with clear sections: purpose, parameters, output, use cases, examples, and hints. However, it is somewhat verbose (e.g., parameter descriptions repeat schema text, use cases are extensive). Still, critical information is front-loaded, and the structure aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description provides output description and example responses. It covers prerequisites (how to obtain issue IDs and tcrId) and includes use cases. It lacks explicit error handling but overall sufficiently guides the agent for typical linking scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing a baseline of 3. The description adds value by clarifying the parameter naming pitfall for tcrId, and hints on how to obtain valid values (e.g., using Fetch issues linked with testcases tool). Examples further illustrate correct usage.

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 'Link one or more issues to a QMetry Testcase Run (execution)', specifying the verb 'Link' and the resources 'issues' and 'Testcase Run'. It further clarifies the scope with 'one or more', and the toolset section helps distinguish from other QMetry tools that fetch or update different entities.

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 does not explicitly state when to use this tool versus alternatives, but it provides hints on prerequisites (e.g., fetching issue IDs and tcrId from other tools). It lacks comparative guidance against siblings like qmetry_link_requirements_to_testcase, so the agent must infer usage from context.

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

Install Server

Other Tools

Latest Blog Posts

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/SmartBear/smartbear-mcp'

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