qmetry_fetch_requirements

// WHEN AI AGENTS USE THIS TOOL

AI agents call qmetry_fetch_requirements 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.

// WHY ENFORCE A POLICY ON QMETRY_FETCH_REQUIREMENTS

Even though qmetry_fetch_requirements 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.

// RECOMMENDED POLICY

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_requirements:
    rules:
      - action: allow

See the full SmartBear MCP policy for all 147 tools.

// DETAILS

Tool Name qmetry_fetch_requirements

Category Read

MCP Server SmartBear MCP MCP Server

Risk Level Low

// MORE SMARTBEAR MCP TOOLS

Destructive collaborator_delete_collaborator_remote_system_configuration Destructive reflect_cancel_suite_execution Destructive reflect_delete_previous_step Destructive swagger_delete_portal_product Destructive swagger_delete_table_of_contents Execute collaborator_reviewservice_action Execute contract-testing_can_i_deploy Execute qmetry_link_issues_to_testcase_run

View all 147 tools →

// RELATED READING

// FAQ

What does the qmetry_fetch_requirements tool do? +

Fetch QMetry requirements - 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 requirements - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.RQ.viewId automatically. Manual viewId only needed if you want to override the automatic resolution. - folderPath (string): Folder path for requirements - 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. - hideEmptyFolders (boolean): Whether to hide empty folders. - folderSortColumn (string): Folder sort column (default 'name') - folderSortOrder (string): Folder sort order (ASC or DESC) - isJiraFilter (boolean): 'false' if using qmetry filter (default: false) - filterType (enum): Pass 'QMETRY' or 'JIRA' (default: "QMETRY") - 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 - name, entityKey, associatedVersion, priorityAlias, createdDate, createdByAlias, updatedDate, updatedByAlias, requirementStateAlias, linkedTcCount, linkedDfCount, attachmentCount, createdSystem, owner (default: "[{\"property\":\"name\",\"direction\":\"ASC\"}]") **Output Description:** JSON object with 'data' array containing requirements and pagination info **Use Cases:** 1. List all requirements in a project 2. Search for specific requirements using filters 3. Browse requirements in specific folders 4. Get paginated requirement results 5. Filter requirements by name or properties 6. Get requirement metadata for test planning **Examples:** 1. Get all requirements from default project - system will auto-fetch viewId ```json {} ``` Expected Output: List of requirements from default project with auto-resolved viewId 2. Get all requirements from UT project - system will auto-fetch UT project's viewId ```json { "projectKey": "UT" } ``` Expected Output: List of requirements from UT project using UT's specific RQ viewId 3. Get requirements with manual viewId (skip auto-resolution) ```json { "projectKey": "MAC", "viewId": 7397, "folderPath": "/APIARY 88" } ``` Expected Output: Requirements using manually specified viewId 7397 4. Search for specific requirements by entity key ```json { "projectKey": "MAC", "filter": "[{\"type\":\"string\",\"value\":\"MAC-RQ-123\",\"field\":\"entityKeyId\"}]" } ``` Expected Output: Filtered requirements matching the entity key criteria 5. Search for multiple requirements by comma-separated entity keys ```json { "projectKey": "MAC", "filter": "[{\"type\":\"string\",\"value\":\"MAC-RQ-123,MAC-RQ-456,MAC-RQ-789\",\"field\":\"entityKeyId\"}]" } ``` Expected Output: Requirements matching any of the specified entity keys 6. Filter requirements by state (e.g., Open, Approved) ```json { "projectKey": "MAC", "filter": "[{\"type\":\"string\",\"value\":\"Open\",\"field\":\"requirementStateAlias\"}]" } ``` Expected Output: Requirements with 'Open' state 7. Filter requirements by priority ```json { "projectKey": "MAC", "filter": "[{\"type\":\"string\",\"value\":\"High\",\"field\":\"priorityAlias\"}]" } ``` Expected Output: Requirements with 'High' priority 8. Filter requirements by archive status ```json { "filter": "[{\"value\":[1,0],\"type\":\"list\",\"field\":\"isArchived\"}]" } ``` Expected Output: List of requirements filtered by archive status (archived and non-archived) 9. Get only archived requirements ```json { "filter": "[{\"value\":[1],\"type\":\"list\",\"field\":\"isArchived\"}]" } ``` Expected Output: List of only archived requirements 10. Sort requirements by name in ascending order ```json { "projectKey": "MAC", "sort": "[{\"property\":\"name\",\"direction\":\"ASC\"}]" } ``` Expected Output: Requirements sorted alphabetically by name 11. Sort requirements by creation date (newest first) ```json { "projectKey": "MAC", "sort": "[{\"property\":\"createdDate\",\"direction\":\"DESC\"}]" } ``` Expected Output: Requirements sorted by creation date, newest first 12. Sort requirements by entity key ```json { "projectKey": "MAC", "sort": "[{\"property\":\"entityKey\",\"direction\":\"ASC\"}]" } ``` Expected Output: Requirements sorted by entity key (MAC-RQ-1, MAC-RQ-2, etc.) 13. Sort requirements by linked test case count ```json { "projectKey": "MAC", "sort": "[{\"property\":\"linkedTcCount\",\"direction\":\"DESC\"}]" } ``` Expected Output: Requirements sorted by number of linked test cases, highest first 14. Complex filter: Requirements by owner with specific state ```json { "projectKey": "MAC", "filter": "[{\"type\":\"string\",\"value\":\"john.doe\",\"field\":\"owner\"},{\"type\":\"string\",\"value\":\"Approved\",\"field\":\"requirementStateAlias\"}]" } ``` Expected Output: Requirements owned by john.doe with 'Approved' state 15. Multi-field sort: Priority first, then creation date ```json { "projectKey": "MAC", "sort": "[{\"property\":\"priorityAlias\",\"direction\":\"DESC\"},{\"property\":\"createdDate\",\"direction\":\"ASC\"}]" } ``` Expected Output: Requirements sorted by priority (High to Low), then by creation date (oldest first) 16. Filter requirements by specific release and cycle ```json { "projectKey": "MAC", "filter": "[{\"value\":[55178],\"type\":\"list\",\"field\":\"release\"},{\"value\":[111577],\"type\":\"list\",\"field\":\"cycle\"}]" } ``` Expected Output: Requirements associated with Release 8.12 (ID: 55178) and Cycle 8.12.1 (ID: 111577) 17. Filter requirements by release only ```json { "projectKey": "MAC", "filter": "[{\"value\":[55178],\"type\":\"list\",\"field\":\"release\"}]" } ``` Expected Output: All requirements associated with Release 8.12 (ID: 55178) **Hints:** 1. CRITICAL WORKFLOW: Always use the SAME projectKey for both project info and requirement 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.RQ.viewId 4. Step 3: Use the SAME projectKey and the extracted RQ viewId for fetching requirements 5. Step 4: If user doesn't specify projectKey, use 'default' for both project info and requirement fetching 6. NEVER mix project keys - if user says 'MAC project', use projectKey='MAC' for everything 7. For search by requirement key (like MAC-RQ-123), use filter: '[{"type":"string","value":"MAC-RQ-123","field":"entityKeyId"}]' 8. For multiple entity keys, use comma-separated values: '[{"type":"string","value":"MAC-RQ-123,MAC-RQ-456","field":"entityKeyId"}]' 9. Use empty string '' as folderPath for root directory 10. Filter supports QMETRY and JIRA types - default is QMETRY 11. FILTER FIELDS: entityKeyId, name, requirementStateAlias, priorityAlias, owner, createdByAlias, updatedByAlias, createdSystem 12. SORT FIELDS: name, entityKey, associatedVersion, priorityAlias, createdDate, createdByAlias, updatedDate, updatedByAlias, requirementStateAlias, linkedTcCount, linkedDfCount, attachmentCount, createdSystem, owner 13. SORT DIRECTIONS: ASC (ascending), DESC (descending) 14. Multiple filters: Use array with multiple objects for AND conditions 15. Multiple sort criteria: Use array with multiple objects, first takes priority 16. Filter format: [{'type':'string','value':'filterValue','field':'fieldName'}] 17. Sort format: [{'property':'fieldName','direction':'ASC|DESC'}] 18. RELEASE/CYCLE FILTERING: Use release and cycle IDs from fetch_releases_and_cycles tool 19. For specific release: '[{"value":[releaseId],"type":"list","field":"release"}]' 20. For specific cycle: '[{"value":[cycleId],"type":"list","field":"cycle"}]' 21. For release AND cycle: '[{"value":[releaseId],"type":"list","field":"release"},{"value":[cycleId],"type":"list","field":"cycle"}]' 22. Example: Release 8.12 (ID: 55178) + Cycle 8.12.1 (ID: 111577) = filter with both IDs. 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_requirements? +

Add a rule in your Intercept YAML policy under the tools section for qmetry_fetch_requirements. 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_requirements? +

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

Can I rate-limit qmetry_fetch_requirements? +

Yes. Add a rate_limit block to the qmetry_fetch_requirements 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_requirements completely? +

Set action: deny in the Intercept policy for qmetry_fetch_requirements. 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_requirements? +

qmetry_fetch_requirements 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