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

Retrieves test suites available for linking to test cases in QMetry, supporting folder filtering and pagination.

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

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

  • 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. Manual viewId only needed if you want to override the automatic resolution.

  • 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: clientData.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. Manual viewId only needed if you want to override the automatic resolution.
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
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.
Behavior4/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing automatic resolution of viewId, the need for projectKey, pagination behavior, filtering capabilities, and output format. No contradictions.

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 very lengthy with many bullet points, hints, and 8 examples. While informative, it lacks conciseness and could be better structured. The front-loaded purpose is clear, but the volume of text may overwhelm the agent.

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?

Given the complexity (9 parameters, no output schema, many siblings), the description is highly complete: it covers prerequisites, parameter details, workflows, examples, hints, and filter capabilities. All needed information is present.

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 baseline is 3. The description adds significant meaning with critical notes on tsFolderID (parameter name, sourcing from FETCH_PROJECT_INFO), viewId (automatic resolution), and filter (fields and examples). Examples demonstrate parameter combinations.

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 'Get test suites that can be linked to test cases in QMetry with automatic viewId resolution', which is specific about the resource and purpose. It distinguishes from the sibling tool 'qmetry_fetch_test_suites' by adding the 'for test case' context, though not explicitly naming the difference.

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 extensive usage context: prerequisites (FETCH_PROJECT_INFO for tsFolderID), automatic viewId resolution, pagination, filtering, and use cases. It advises 'Use this before creating new test suites to check existing ones' but does not explicitly state when not to use this tool or list alternatives.

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