Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Test Suites

qmetry_fetch_test_suites
Read-onlyIdempotent

Retrieve QMetry test suites for any project, using filters like release, cycle, or test suite keys. Supports folder browsing and pagination, with automatic viewId resolution.

Instructions

Fetch QMetry test suites - automatically handles viewId resolution based on project

Toolset: Test Suites

Parameters:

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

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

  • folderPath (string): Folder path for test suites - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (root directory). Only specify if user wants specific folder like "Automation/Regression". (default: "")

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

  • scope (string): Scope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon. (default: "project")

  • getSubEntities (boolean): Whether to include sub-entities.

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

  • udfFilter (string): User-defined field filter as JSON string (default '[]') (default: "[]")

  • sort (string): Sort Records - refer json schema, Possible property - entityKey, name, testsuiteStatus, linkedPlatformCount, linkedTcCount, createdDate, createdByAlias, updatedDate, updatedByAlias, attachmentCount, owner, remExecutionTime, totalExecutionTime (default: "[{"property":"name","direction":"ASC"}]")

Output Description: JSON object with 'data' array containing test suites and pagination info

Use Cases: 1. List all test suites in a project 2. Search for specific test suites using filters 3. Browse test suites in specific folders 4. Get paginated test suite results

Examples:

  1. Get all test suites from default project - system will auto-fetch viewId

{}

Expected Output: List of test suites from default project with auto-resolved viewId

  1. Get all test suites from UT project - system will auto-fetch UT project's viewId

{
  "projectKey": "UT"
}

Expected Output: List of test suites from UT project using UT's specific TS viewId

  1. Get test suites by release/cycle filter

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

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

  1. Get test suites by release only

{
  "projectKey": "MAC",
  "filter": "[{\"value\":[55178],\"type\":\"list\",\"field\":\"release\"}]"
}

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

  1. Get test suites by cycle only

{
  "projectKey": "MAC",
  "filter": "[{\"value\":[111577],\"type\":\"list\",\"field\":\"cycle\"}]"
}

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

  1. Search for specific test suite by entity key

{
  "projectKey": "MAC",
  "filter": "[{\"type\":\"string\",\"value\":\"MAC-TS-1684\",\"field\":\"entityKeyId\"}]"
}

Expected Output: Test suites matching the entity key criteria

  1. Search for multiple test suites by comma-separated entity keys

{
  "projectKey": "MAC",
  "filter": "[{\"type\":\"string\",\"value\":\"MAC-TS-1684,MAC-TS-1685,MAC-TS-1686\",\"field\":\"entityKeyId\"}]"
}

Expected Output: Test suites matching any of the specified entity keys

Hints: 1. CRITICAL WORKFLOW: Always use the SAME projectKey for both project info and test suite fetching 2. Step 1: If user specifies projectKey (like 'UT', 'MAC'), use that EXACT projectKey for project info 3. Step 2: Get project info using that projectKey, extract latestViews.TS.viewId 4. Step 3: Use the SAME projectKey and the extracted TS viewId for fetching test suites 5. Step 4: If user doesn't specify projectKey, use 'default' for both project info and test suite fetching 6. NEVER mix project keys - if user says 'MAC project', use projectKey='MAC' for everything 7. For search by test suite key (like MAC-TS-1684), use filter: '[{"type":"string","value":"MAC-TS-1684","field":"entityKeyId"}]' 8. RELEASE/CYCLE FILTERING: Use release and cycle IDs, not names, for filtering 9. For release filter: '[{"value":[releaseId],"type":"list","field":"release"}]' 10. For cycle filter: '[{"value":[cycleId],"type":"list","field":"cycle"}]' 11. For combined release+cycle: '[{"value":[releaseId],"type":"list","field":"release"},{"value":[cycleId],"type":"list","field":"cycle"}]' 12. Get release/cycle IDs from FETCH_RELEASES_AND_CYCLES tool before filtering 13. FILTER FIELDS: name, release, cycle, platform, isArchived, testsuiteStatus, createdByAlias, createdDate, entityKeyId, attachmentCount, linkedPlatformCount, linkedTcCount, updatedByAlias, updatedDate, owner, remExecutionTime, and totalExecutionTime 14. SORT FIELDS: entityKey, name, testsuiteStatus, linkedPlatformCount, linkedTcCount, createdDate, createdByAlias, updatedDate, updatedByAlias, attachmentCount, remExecutionTime, and totalExecutionTime 15. For multiple entity keys, use comma-separated values in filter 16. Use empty string '' as folderPath for root directory

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
sortNoSort Records - refer json schema, Possible property - entityKey, name, testsuiteStatus, linkedPlatformCount, linkedTcCount, createdDate, createdByAlias, updatedDate, updatedByAlias, attachmentCount, owner, remExecutionTime, totalExecutionTime[{"property":"name","direction":"ASC"}]
limitNoNumber of records (default 10).
scopeNoScope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon.project
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
viewIdNoViewId for test suites - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TS.viewId automatically.
udfFilterNoUser-defined field filter as JSON string (default '[]')[]
folderPathNoFolder path for test suites - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (root directory). Only specify if user wants specific folder like "Automation/Regression".
projectKeyNoProject key - unique identifier for the projectdefault
getSubEntitiesNoWhether to include sub-entities.
Install Server

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds substantial beyond-annotation context: automatic viewId resolution, root folder defaulting, release/cycle ID semantics, and output shape with a data array and pagination info. This gives the agent a clear behavioral model without contradicting the annotations.

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

Conciseness3/5

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

The description is well-structured and front-loads the critical auto-viewId behavior, but it is very long and repetitive. Parameter defaults and descriptions are duplicated from the schema, and the 16 numbered hints contain overlapping information, making it less concise than it could be.

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?

For a complex tool with 11 optional parameters and no output schema, the description is remarkably complete. It covers automatic viewId resolution, folder behavior, filtering by release/cycle, pagination, sort fields, filter fields, and multiple worked examples with expected outputs.

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?

Although schema coverage is 100%, the description greatly enriches parameter understanding: it explains exactly how viewId and folderPath are auto-resolved, provides concrete filter JSON patterns, enumerates sort and filter fields, and shows comma-separated entity key examples. This goes far beyond the baseline for schema-covered parameters.

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 the tool fetches QMetry test suites and emphasizes automatic viewId resolution, which is a specific, actionable behavior. However, it does not explicitly distinguish itself from closely related sibling tools like qmetry_fetch_test_suite_details or qmetry_fetch_test_suites_for_test_case.

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 a clear 'Use Cases' list and strong contextual hints, such as fetching release/cycle IDs from FETCH_RELEASES_AND_CYCLES before filtering and using the same projectKey across calls. It lacks explicit exclusions or direct comparisons to sibling tools, so the agent has to infer when other QMetry fetch tools would be more appropriate.

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