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

Get test cases linked or not linked to a test suite in QMetry. Supports filtering and pagination for execution planning, gap analysis, and coverage verification.

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")

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

  • 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 '[]')[]
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
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
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by explaining pagination behavior, filter capabilities, and output format, without contradicting annotations. No side effects mentioned, which is appropriate.

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

Conciseness2/5

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

Description is excessively long and redundant. Information in 'Parameters', 'Hints', and 'Examples' overlaps significantly. Could be streamlined to half the length without losing clarity.

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?

No output schema exists, so description partially compensates with an output description and examples. However, the output format is vaguely described ('JSON object with test cases array containing test case details') and lacks exact field names or pagination metadata. For a tool with 8 parameters and no output schema, it's adequate but not thorough.

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?

Input schema covers 100% of parameters with descriptions. Description adds extra context with 'CRITICAL' notes, hints for getting tsID, and filter field mappings (e.g., priorityAlias, status IDs), which go 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?

Description clearly states 'Get test cases that are linked (or not linked) to a specific test suite in QMetry', which is a specific verb+resource. It distinguishes from sibling tools like qmetry_fetch_test_cases (which doesn't filter by suite) and qmetry_link_test_cases_to_test_suite (which links rather than fetches).

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?

Provides explicit guidance on when to use getLinked=true vs false, how to obtain tsID, and many use cases. However, it lacks explicit exclusions or comparisons to alternative tools (e.g., vs qmetry_fetch_test_cases_linked_to_requirement), so not a full 5.

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