# 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 Agent View of the PolicyLayer registry record for `qmetry_fetch_requirements`. HTML page: https://policylayer.com/tools/smartbear-mcp/qmetry-fetch-requirements ## Facts - Tool: `qmetry_fetch_requirements` - Server: SmartBear MCP (`SmartBear/smartbear-mcp`) — https://policylayer.com/tools/smartbear-mcp.md - Homepage: https://github.com/SmartBear/smartbear-mcp - Risk category: Read (Low risk) - Registry record: grade F, identity unverified - Server rate-limited: no - Parameters: 12 (1 required) - Recommended policy verdict: Allowed ## Parameters | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `page` | number | no | Page number to return (starts from 1) | | `sort` | string | no | Sort Records - refer json schema, Possible property - name, entityKey, associatedVersion, priorityAlias, createdDate, createdByAlias, updatedDate, updatedByAlia | | `limit` | number | no | Number of records (default 10). | | `scope` | string | no | 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 | no | Start index for pagination - defaults to 0 | | `filter` | string | no | Filter criteria as JSON string (default '[]') | | `viewId` | number | yes | ViewId for requirements - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey | | `baseUrl` | string | no | The base URL for the QMetry instance (must be a valid URL) | | `udfFilter` | string | no | User-defined field filter as JSON string (default '[]') | | `filterType` | string | no | Pass 'QMETRY' or 'JIRA' | | `folderPath` | string | no | Folder path for requirements - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (ro | | `projectKey` | string | no | Project key - unique identifier for the project | Parameters from the server's own tool schema. ## Example call (MCP tools/call, JSON-RPC 2.0) ```json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "qmetry_fetch_requirements", "arguments": { "viewId": 0 } } } ``` ## Why qmetry_fetch_requirements is rated Low This tool retrieves/queries requirements data from a QMetry test management system without modifying, deleting, or executing any operations. It has minimal blast radius—worst case, an AI agent might fetch irrelevant requirements data, causing inconvenience but no damage or side effects. From the tool's own definition: "Tool name includes 'fetch' and description states 'Fetch QMetry requirements'; parameters are read-only (projectKey, baseUrl, viewId); no modification, deletion, or execution capability mentioned." Risk signals: High parameter count (17 properties) · Admin/system-level operation ## Use case AI agents call qmetry_fetch_requirements 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. ## Recommended policy (PolicyLayer) Verdict: **Allowed**. Enforced by the PolicyLayer MCP gateway (https://policylayer.com/mcp-gateway) before a call reaches SmartBear MCP: ```json { "version": "1", "default": "deny", "tools": { "qmetry_fetch_requirements": {} } } ``` ## Other tools on SmartBear MCP (239) - `collaborator_delete_collaborator_remote_system_configuration` — Destructive — https://policylayer.com/tools/smartbear-mcp/collaborator-delete-collaborator-remote-system-configuration.md - `contract-testing_admin_delete_role` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-admin-delete-role.md - `contract-testing_admin_delete_team` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-admin-delete-team.md - `contract-testing_admin_delete_user` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-admin-delete-user.md - `contract-testing_admin_remove_role_from_user` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-admin-remove-role-from-user.md - `contract-testing_admin_remove_user_from_team` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-admin-remove-user-from-team.md - `contract-testing_admin_reset_roles` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-admin-reset-roles.md - `contract-testing_delete_all_integrations` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-delete-all-integrations.md - `contract-testing_delete_branch` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-delete-branch.md - `contract-testing_delete_environment` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-delete-environment.md - `contract-testing_delete_integration` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-delete-integration.md - `contract-testing_delete_pacticipant` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-delete-pacticipant.md - `contract-testing_delete_secret` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-delete-secret.md - `contract-testing_delete_webhook` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-delete-webhook.md - `contract-testing_regenerate_api_token` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-regenerate-api-token.md - `contract-testing_remove_label_from_pacticipant` — Destructive — https://policylayer.com/tools/smartbear-mcp/contract-testing-remove-label-from-pacticipant.md - `reflect_cancel_suite_execution` — Destructive — https://policylayer.com/tools/smartbear-mcp/reflect-cancel-suite-execution.md - `reflect_delete_previous_step` — Destructive — https://policylayer.com/tools/smartbear-mcp/reflect-delete-previous-step.md - `swagger_delete_portal_product` — Destructive — https://policylayer.com/tools/smartbear-mcp/swagger-delete-portal-product.md - `swagger_delete_table_of_contents` — Destructive — https://policylayer.com/tools/smartbear-mcp/swagger-delete-table-of-contents.md - `collaborator_reviewservice_action` — Execute — https://policylayer.com/tools/smartbear-mcp/collaborator-reviewservice-action.md - `collaborator_test_collaborator_remote_system_configuration_connection` — Execute — https://policylayer.com/tools/smartbear-mcp/collaborator-test-collaborator-remote-system-configuration-connection.md - `contract-testing_execute_webhook` — Execute — https://policylayer.com/tools/smartbear-mcp/contract-testing-execute-webhook.md - `contract-testing_generate_pact_tests` — Execute — https://policylayer.com/tools/smartbear-mcp/contract-testing-generate-pact-tests.md - `contract-testing_review_pact_tests` — Execute — https://policylayer.com/tools/smartbear-mcp/contract-testing-review-pact-tests.md - `contract-testing_test_execute_webhooks` — Execute — https://policylayer.com/tools/smartbear-mcp/contract-testing-test-execute-webhooks.md - `reflect_add_prompt_step` — Execute — https://policylayer.com/tools/smartbear-mcp/reflect-add-prompt-step.md - `reflect_connect_to_session` — Execute — https://policylayer.com/tools/smartbear-mcp/reflect-connect-to-session.md - `reflect_execute_suite` — Execute — https://policylayer.com/tools/smartbear-mcp/reflect-execute-suite.md - `reflect_run_test` — Execute — https://policylayer.com/tools/smartbear-mcp/reflect-run-test.md - …and 209 more: https://policylayer.com/tools/smartbear-mcp.md ## For agents This record is a snapshot. Live verdicts and the full registry: - Check every server in your MCP config at once: `npx -y policylayer stack` - Vet a server before you add it: install the mcp-precheck skill — `npx skills add https://policylayer.com` (skill text: https://policylayer.com/skill.md) - Query the registry over MCP: endpoint `https://api.policylayer.com/mcp` — tools `check_mcp_server`, `check_mcp_stack`, `check_tool`, `search_registry`, `get_change_events` --- Source: the PolicyLayer MCP registry — one continuously verified record per MCP server. Full record: https://policylayer.com/registry?q=smartbear-mcp · API: https://policylayer.com/registry/api · Policy library: https://policylayer.com/policies/smartbear-mcp