qmetry_fetch_requirements

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.

qmetry_fetch_requirements accepts 12 parameters: page, sort, limit, scope, start, filter, viewId, baseUrl, udfFilter, filterType, folderPath, projectKey. 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_requirements: 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_requirements 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_requirements 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_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.

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