qmetry_fetch_test_suites
Fetch QMetry test suites - automatically handles viewId resolution based on project 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) (default: "https://testmanagem...
This record as markdown: /tools/smartbear-mcp/qmetry-fetch-test-suites.md
What qmetry_fetch_test_suites does on SmartBear MCP
AI agents call qmetry_fetch_test_suites to retrieve information from SmartBear MCP without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
page | number | — | Page number to return (starts from 1) |
sort | string | — | Sort Records - refer json schema, Possible property - entityKey, name, testsuiteStatus, linkedPlatformCount, linkedTcCount, createdDate, createdByAlias, updated |
limit | number | — | Number of records (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 be |
start | number | — | Start index for pagination - defaults to 0 |
filter | string | — | Filter criteria as JSON string (default '[]') |
viewId | number | Yes | ViewId for test suites - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey |
baseUrl | string | — | The base URL for the QMetry instance (must be a valid URL) |
udfFilter | string | — | User-defined field filter as JSON string (default '[]') |
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 "" (roo |
projectKey | string | — | Project key - unique identifier for the project |
getSubEntities | boolean | — | Whether to include sub-entities. |
Parameters from the server's own tool schema.
Why qmetry_fetch_test_suites is rated Low
This tool retrieves or queries test suite data from a QMetry instance without creating, modifying, deleting, or executing any operations. It is a straightforward data retrieval function with no destructive, financial, or execution capabilities. The automatic viewId resolution is a convenience feature that does not change the fundamental read-only nature of the operation.
From the tool's definition Tool name contains 'fetch' and description states 'Fetch QMetry test suites', which is a retrieval operation with no side effects.
Risk signalsHigh parameter count (12 properties) · Admin/system-level operation
Attacks that exploit this kind of access
The rule that runs qmetry_fetch_test_suites safely
PolicyLayer is an MCP gateway: it sits between your AI agents and SmartBear MCP, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For qmetry_fetch_test_suites, this is the rule to start with:
qmetry_fetch_test_suites is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect SmartBear MCP, apply this rule, and every qmetry_fetch_test_suites call is checked against it from then on.
Questions about qmetry_fetch_test_suites
Fetch QMetry test suites - automatically handles viewId resolution based on project 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) (default: "https://testmanagement.qmetry.com") - viewId (number) *required*: 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. Manual viewId only needed if you want to override the automatic resolution. - 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 json {} Expected Output: List of test suites from default project with auto-resolved viewId 2. Get all test suites from UT project - system will auto-fetch UT project's viewId json { "projectKey": "UT" } Expected Output: List of test suites from UT project using UT's specific TS viewId 3. Get test suites with manual viewId (skip auto-resolution) json { "projectKey": "MAC", "viewId": 103097, "folderPath": "" } Expected Output: Test suites using manually specified viewId 103097 4. List test suites from specific project (ex: project key can be anything (VT, UT, PROJ1, TEST9) json { "projectKey": "use specific given project key", "viewId": "fetch specific project given projectKey Test Suite ViewId", "folderPath": "" } Expected Output: Test suites using manually specified viewId 103097 or projectKey 5. Get test suites by release/cycle filter json { "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) 6. Get test suites by release only json { "projectKey": "MAC", "filter": "[{\"value\":[55178],\"type\":\"list\",\"field\":\"release\"}]" } Expected Output: All test suites associated with Release 8.12 (ID: 55178) 7. Get test suites by cycle only json { "projectKey": "MAC", "filter": "[{\"value\":[111577],\"type\":\"list\",\"field\":\"cycle\"}]" } Expected Output: All test suites associated with Cycle 8.12.1 (ID: 111577) 8. Search for specific test suite by entity key json { "projectKey": "MAC", "filter": "[{\"type\":\"string\",\"value\":\"MAC-TS-1684\",\"field\":\"entityKeyId\"}]" } Expected Output: Test suites matching the entity key criteria 9. Search for multiple test suites by comma-separated entity keys json { "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. It is categorised as a Read tool in the SmartBear MCP MCP Server, which means it retrieves data without modifying state.
qmetry_fetch_test_suites accepts 12 parameters: page, sort, limit, scope, start, filter, viewId, baseUrl, udfFilter, folderPath, projectKey, getSubEntities. Required: viewId. The full parameter table on this page comes from the server's own tool schema.
Register the SmartBear MCP server in PolicyLayer and add a rule for qmetry_fetch_test_suites: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches SmartBear MCP. Nothing to install.
qmetry_fetch_test_suites is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the qmetry_fetch_test_suites rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for qmetry_fetch_test_suites. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
qmetry_fetch_test_suites is provided by the SmartBear MCP server (SmartBear/smartbear-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on SmartBear, and thousands of servers like it.
This server
Across the catalogue