Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Test Cases Linked to Test Suite

qmetry_fetch_test_cases_linked_to_test_suite
Read-onlyIdempotent

Retrieve test cases linked to a specific QMetry test suite by suite ID, or list unlinked cases to identify coverage gaps for test planning and analysis.

Instructions

Get test cases that are linked (or not linked) to a specific test suite in QMetry

Toolset: Test Suites

Parameters:

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

  • tsID (number) required: Test Suite numeric ID. CRITICAL: the parameter name is 'tsID' — do NOT use 'testSuiteId', 'testSuiteID', 'suiteId', or other variants. Accepts a string or number. NOTE: To get the tsID - Call API 'Testsuite/Fetch Testsuite' From the response, get value of following attribute -> data[].id

  • getLinked (boolean): True to get only those issues that are linked with this Test case Run, False to get those issues which are not linked with this Test case Run. Default value true (get linked issues). (default: true)

  • start (number): Start index for pagination - defaults to 0 (default: 0)

  • page (number): Page number to return (starts from 1) (default: 1)

  • limit (number): Number of records (default 10). (default: 10)

  • filter (string): Filter criteria as JSON string (default '[]') (default: "[]")

Output Description: JSON object with test cases array containing test case details, properties, and suite linkage information

Use Cases: 1. Get all test cases linked to a specific test suite for execution planning 2. Find test cases that are NOT linked to a test suite (gap analysis) 3. Analyze test suite composition and coverage 4. Filter linked test cases by various criteria 5. Plan test execution based on test suite structure 6. Generate test suite reports and documentation 7. Validate test suite contents before execution 8. Manage test case organization within test suites 9. Export test suite details for external reporting 10. Verify test case assignments in test suites

Examples:

  1. Get all test cases linked to test suite ID 1497291 (default behavior)

{
  "tsID": 1497291
}

Expected Output: List of test cases linked to the test suite with test case details and metadata

  1. Get all test cases linked to test suite ID 1497291 (explicit)

{
  "tsID": 1497291,
  "getLinked": true
}

Expected Output: List of test cases linked to the test suite with test case details and metadata

  1. Get test cases NOT linked to test suite (gap analysis)

{
  "tsID": 1497291,
  "getLinked": false
}

Expected Output: List of test cases that are NOT linked to the test suite

  1. Get linked test cases with custom pagination

{
  "tsID": 1497291,
  "getLinked": true,
  "page": 1,
  "limit": 25
}

Expected Output: Paginated list of linked test cases with 50 items per page

  1. Filter linked test cases by priority (using default getLinked=true)

{
  "tsID": 1497291,
  "filter": "[{\"value\":[1,2],\"type\":\"list\",\"field\":\"priorityAlias\"}]"
}

Expected Output: High and medium priority test cases linked to the suite

  1. Filter linked test cases by status

{
  "tsID": 1497291,
  "getLinked": true,
  "filter": "[{\"value\":[1],\"type\":\"list\",\"field\":\"testCaseStateAlias\"}]"
}

Expected Output: Active test cases linked to the test suite

Hints: 1. CRITICAL: tsID parameter is REQUIRED - this is the Test Suite numeric ID 2. getLinked parameter is OPTIONAL - defaults to true if not provided 3. HOW TO GET tsID: 4. 1. Call API 'Testsuite/Fetch Testsuite' to get available test suites 5. 2. From the response, get value of following attribute -> data[].id 6. 3. Example: Test Suite 'Regression Suite' might have ID 1497291 7. tsID is NOT the same as tsFolderID - tsID refers to a specific test suite, not a folder 8. getLinked=true (default): Returns test cases that ARE linked to the test suite 9. getLinked=false: Returns test cases that are NOT linked to the test suite (useful for gap analysis) 10. If getLinked is not specified, it defaults to true (linked test cases) 11. FILTER CAPABILITIES: Support filtering by test case properties 12. FILTER FIELDS: priorityAlias (list), testCaseStateAlias (list), testingTypeAlias (list), testCaseTypeAlias (list), componentAlias (list), owner (list) 13. PRIORITY IDs: Typically 1=High, 2=Medium, 3=Low (verify with your QMetry instance) 14. STATUS IDs: Typically 1=Active, 2=Review, 3=Deprecated (verify with your QMetry instance) 15. TESTING TYPE IDs: Typically 1=Manual, 2=Automated (verify with your QMetry instance) 16. TYPE IDs: Typically 1=Functional, 2=Integration, 3=System (verify with your QMetry instance) 17. Multiple filter conditions are combined with AND logic 18. Use pagination for large result sets (start, page, limit parameters) 19. This tool is essential for test suite management and execution planning 20. Helps verify test suite composition before test runs 21. Critical for understanding test coverage within specific suites 22. Use for test suite analysis and optimization

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
tsIDYesTest Suite numeric ID. CRITICAL: the parameter name is 'tsID' — do NOT use 'testSuiteId', 'testSuiteID', 'suiteId', or other variants. Accepts a string or number. NOTE: To get the tsID - Call API 'Testsuite/Fetch Testsuite' From the response, get value of following attribute -> data[<index>].id
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
getLinkedNoTrue to get only those issues that are linked with this Test case Run, False to get those issues which are not linked with this Test case Run. Default value true (get linked issues).
projectKeyNoProject key - unique identifier for the projectdefault
Install Server

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already mark this as read-only, idempotent, and non-destructive; the description adds context about defaults, tsID acquisition, tsID vs tsFolderID, filter-field names, AND logic, and ID mappings. This is strong, but the description reuses 'Test case Run' wording for getLinked and example 4 claims 50 items per page with limit=25, introducing avoidable ambiguity.

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

Conciseness2/5

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

The definition is organized but severely overlong: 10 use cases and 22 hints largely repeat the parameter descriptions and each other, adding generic filler like 'essential for test suite management.' The first sentence is front-loaded, but most of the later content does not earn 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?

With no output schema, the description supplies an output description and many examples covering linked/unlinked behavior, filtering, and pagination. It addresses all seven parameters and common usage scenarios, though the output format remains high-level and the internal errors slightly compromise 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%, giving a baseline of 3; the description goes well beyond it by documenting filter fields, ID conventions, default values, and worked JSON examples. The inaccurate pagination expectation in example 4 and the 'Test case Run' wording for getLinked prevent a perfect score.

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 a specific verb and object: 'Get test cases that are linked (or not linked) to a specific test suite in QMetry.' The linked/not-linked scope makes it distinct from sibling fetch tools such as qmetry_fetch_test_cases and qmetry_fetch_test_cases_linked_to_requirement. Title and toolset reinforce the same resource.

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 an explicit Toolset, 10 use cases, and detailed hints about getLinked semantics, tsID lookup, and filtering. It clearly establishes when to use it for execution planning, gap analysis, and coverage, but it does not name alternatives or say when not to use it, so it stops short of full routing guidance.

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

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