Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Test Suites for Test Case

qmetry_fetch_test_suites_for_test_case
Read-onlyIdempotent

Retrieve test suites available for linking to test cases in QMetry. Browse by folder, filter by release or cycle, and paginate results with auto-resolved viewId.

Instructions

Get test suites that can be linked to test cases in QMetry with automatic viewId resolution

Toolset: Test Suites

Parameters:

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

  • tsFolderID (number): Test Suite folder ID. CRITICAL: the parameter name is 'tsFolderID' — do NOT use 'testSuiteFolderId', 'folderId', 'folderID', or other variants. Accepts a string or number. Get from project info response → rootFolders.TS.id. Use FETCH_PROJECT_INFO tool first if not provided by user.

  • viewId (number): ViewId for test suite folders - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TSFS.viewId automatically.

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

  • getColumns (boolean): Whether to get column information in response. (default: true)

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

Output Description: JSON object with test suites array and pagination metadata

Use Cases: 1. Get test suites available for linking with test cases 2. Find appropriate test suites for test case organization 3. Browse test suites in specific folders for better management 4. Filter test suites by release, cycle, or archive status 5. Organize test execution by grouping test cases into test suites 6. Plan test suite structure for comprehensive test coverage 7. Manage test case categorization for reporting purposes 8. Search for existing test suites before creating new ones 9. Get root test suite folder contents using project info

Examples:

  1. Get test suites from root folder using auto-resolved viewId

{
  "tsFolderID": 113557
}

Expected Output: List of test suites available in the root test suite folder with auto-resolved viewId

  1. Get test suites with custom pagination and auto-resolved viewId

{
  "tsFolderID": 113557,
  "page": 1,
  "limit": 25
}

Expected Output: Paginated list of test suites with 20 items per page

  1. Filter test suites by release with auto-resolved viewId

{
  "tsFolderID": 113557,
  "filter": "[{\"type\":\"list\",\"value\":[55178],\"field\":\"release\"}]"
}

Expected Output: Test suites associated with Release 8.12 (ID: 55178)

  1. Filter test suites by cycle with auto-resolved viewId

{
  "tsFolderID": 113557,
  "filter": "[{\"type\":\"list\",\"value\":[111577],\"field\":\"cycle\"}]"
}

Expected Output: Test suites associated with Cycle 8.12.1 (ID: 111577)

  1. Get only active (non-archived) test suites

{
  "tsFolderID": 113557,
  "filter": "[{\"value\":[0],\"type\":\"list\",\"field\":\"isArchived\"}]"
}

Expected Output: List of active test suites (not archived)

  1. Filter test suites by release and cycle

{
  "tsFolderID": 113557,
  "filter": "[{\"type\":\"list\",\"value\":[55178],\"field\":\"release\"},{\"type\":\"list\",\"value\":[111577],\"field\":\"cycle\"}]"
}

Expected Output: Test suites associated with both Release 8.12 (ID: 55178) and Cycle 8.12.1 (ID: 111577)

  1. Get test suites with column information

{
  "tsFolderID": 113557,
  "getColumns": true
}

Expected Output: Test suites list with detailed column metadata for better interpretation

  1. Search test suites from specific sub-folder with manual viewId

{
  "tsFolderID": 42,
  "viewId": 104316
}

Expected Output: Test suites available in specific folder ID 42 for test case linking

Hints: 1. CRITICAL: tsFolderID is REQUIRED - Test Suite folder ID will be auto-resolved if not provided 2. viewId will be AUTOMATICALLY RESOLVED from project info if not provided 3. HOW TO GET tsFolderID: 4. 1. Call FETCH_PROJECT_INFO tool first to get project configuration 5. 2. From the response, use rootFolders.TS.id for the root test suite folder 6. 3. Example: rootFolders.TS.id = 113557 (MAC project root TS folder) 7. 4. If user doesn't specify tsFolderID, automatically use rootFolders.TS.id from project info 8. VIEWID AUTO-RESOLUTION: 9. 1. System automatically fetches project info using the projectKey 10. 2. Extracts latestViews.TSFS.viewId automatically 11. 3. Example: latestViews.TSFS.viewId = 104316 (MAC project TSFS view) 12. 4. Manual viewId only needed if you want to override the automatic resolution 13. WORKFLOW: System automatically handles project info if tsFolderID or viewId is not provided 14. PROJECT INFO STRUCTURE: rootFolders.TS.id contains the root test suite folder ID 15. PROJECT INFO STRUCTURE: latestViews.TSFS.viewId contains the test suite folder view ID 16. For sub-folders: Use specific folder IDs if you know them, or call folder listing APIs 17. FILTER CAPABILITIES: Same as other QMetry list operations 18. FILTER FIELDS: release, cycle, isArchived, name, status, priority 19. RELEASE/CYCLE FILTERING: Use numeric IDs in list format (get from FETCH_RELEASES_AND_CYCLES) 20. ARCHIVE FILTERING: 0=Active, 1=Archived 21. getColumns=true provides additional metadata for result interpretation 22. Multiple filter conditions are combined with AND logic 23. Pagination supported for large result sets (start, page, limit parameters) 24. This tool helps organize test cases into logical test suites 25. Essential for test execution planning and test case management 26. Use this before creating new test suites to check existing ones

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
viewIdNoViewId for test suite folders - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TSFS.viewId automatically.
getColumnsNoWhether to get column information in response.
projectKeyNoProject key - unique identifier for the projectdefault
tsFolderIDNoTest Suite folder ID. CRITICAL: the parameter name is 'tsFolderID' — do NOT use 'testSuiteFolderId', 'folderId', 'folderID', or other variants. Accepts a string or number. Get from project info response → rootFolders.TS.id. Use FETCH_PROJECT_INFO tool first if not provided by user.
Install Server

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral context: automatic viewId resolution, auto-fetching project info, filter capabilities, AND logic for multiple filters, archive encoding, and pagination behavior. The only slight blemish is the internally confusing statement that tsFolderID is 'REQUIRED' while also being auto-resolved if not provided, which could muddy an agent's understanding of optionality.

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 description is heavily bloated: 26 numbered hints, repeated parameter explanations, and redundant example output statements. The first sentence is concise and effective, but subsequent sections repeat schema information and include overlapping instructions. While organized into sections, many sentences do not earn their 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?

Given the 8 parameters and no output schema, the description is largely complete: it provides examples for filtering, pagination, auto-resolution, and project info extraction, and describes the output as 'JSON object with test suites array and pagination metadata'. Minor gaps remain, such as the ambiguous 'REQUIRED' vs auto-resolved tsFolderID and a lack of detailed return field descriptions, but overall it equips an agent to call the tool correctly.

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 far exceeds the schema by explaining the tsFolderID naming trap, how to derive folder IDs from project info, viewId auto-resolution, filter JSON syntax with concrete examples, archive encoding, and pagination semantics. This adds substantial meaning that the schema alone does not convey.

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 opens with a specific verb and resource: 'Get test suites that can be linked to test cases in QMetry', which clearly identifies the operation. It also includes a Toolset label and use cases. However, it does not explicitly name or differentiate from the sibling qmetry_fetch_test_suites, relying on the 'for test case' phrasing to imply distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description provides contextual guidance such as 'Use this before creating new test suites to check existing ones' and explains the workflow for auto-resolving tsFolderID and viewId. It also lists use cases, but it does not explicitly state when to prefer this tool over qmetry_fetch_test_suites or other alternatives, nor does it specify exclusions. Guidance is present but not decisive.

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