Low Risk

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://testma...

High parameter count (12 properties); Admin/system-level operation

Part of the SmartBear MCP MCP server. Enforce policies on this tool with Intercept, the open-source MCP proxy.

@smartbear/mcp Read Risk 2/5

AI agents call qmetry_fetch_test_suites to retrieve information from SmartBear MCP without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.

Even though qmetry_fetch_test_suites only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.

Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.

smartbear-mcp.yaml
tools:
  qmetry_fetch_test_suites:
    rules:
      - action: allow

See the full SmartBear MCP policy for all 147 tools.

Tool Name qmetry_fetch_test_suites
Category Read
Risk Level Low

View all 147 tools →

What does the qmetry_fetch_test_suites tool do? +

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.

How do I enforce a policy on qmetry_fetch_test_suites? +

Add a rule in your Intercept YAML policy under the tools section for qmetry_fetch_test_suites. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the SmartBear MCP MCP server.

What risk level is qmetry_fetch_test_suites? +

qmetry_fetch_test_suites is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Can I rate-limit qmetry_fetch_test_suites? +

Yes. Add a rate_limit block to the qmetry_fetch_test_suites rule in your Intercept 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.

How do I block qmetry_fetch_test_suites completely? +

Set action: deny in the Intercept 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.

What MCP server provides qmetry_fetch_test_suites? +

qmetry_fetch_test_suites is provided by the SmartBear MCP MCP server (@smartbear/mcp). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.

Enforce policies on SmartBear MCP

Open source. One binary. Zero dependencies.

npx -y @policylayer/intercept
github.com/policylayer/intercept →
// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.