Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Requirements

qmetry_fetch_requirements
Read-onlyIdempotent

Fetch QMetry requirements from a project with automatic viewId resolution. Supports filtering, sorting, and pagination to locate specific requirements.

Instructions

Fetch QMetry requirements - automatically handles viewId resolution based on project

Toolset: Requirements

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)

  • viewId (number): 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

{}

Expected Output: List of requirements from default project with auto-resolved viewId

  1. Get all requirements from UT project - system will auto-fetch UT project's viewId

{
  "projectKey": "UT"
}

Expected Output: List of requirements from UT project using UT's specific RQ viewId

  1. Get requirements with manual viewId (skip auto-resolution)

{
  "projectKey": "MAC",
  "viewId": 7397,
  "folderPath": "/APIARY 88"
}

Expected Output: Requirements using manually specified viewId 7397

  1. Search for specific requirements by entity key

{
  "projectKey": "MAC",
  "filter": "[{\"type\":\"string\",\"value\":\"MAC-RQ-123\",\"field\":\"entityKeyId\"}]"
}

Expected Output: Filtered requirements matching the entity key criteria

  1. Search for multiple requirements by comma-separated entity keys

{
  "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

  1. Filter requirements by state (e.g., Open, Approved)

{
  "projectKey": "MAC",
  "filter": "[{\"type\":\"string\",\"value\":\"Open\",\"field\":\"requirementStateAlias\"}]"
}

Expected Output: Requirements with 'Open' state

  1. Filter requirements by priority

{
  "projectKey": "MAC",
  "filter": "[{\"type\":\"string\",\"value\":\"High\",\"field\":\"priorityAlias\"}]"
}

Expected Output: Requirements with 'High' priority

  1. Filter requirements by archive status

{
  "filter": "[{\"value\":[1,0],\"type\":\"list\",\"field\":\"isArchived\"}]"
}

Expected Output: List of requirements filtered by archive status (archived and non-archived)

  1. Get only archived requirements

{
  "filter": "[{\"value\":[1],\"type\":\"list\",\"field\":\"isArchived\"}]"
}

Expected Output: List of only archived requirements

  1. Sort requirements by name in ascending order

{
  "projectKey": "MAC",
  "sort": "[{\"property\":\"name\",\"direction\":\"ASC\"}]"
}

Expected Output: Requirements sorted alphabetically by name

  1. Sort requirements by creation date (newest first)

{
  "projectKey": "MAC",
  "sort": "[{\"property\":\"createdDate\",\"direction\":\"DESC\"}]"
}

Expected Output: Requirements sorted by creation date, newest first

  1. Sort requirements by entity key

{
  "projectKey": "MAC",
  "sort": "[{\"property\":\"entityKey\",\"direction\":\"ASC\"}]"
}

Expected Output: Requirements sorted by entity key (MAC-RQ-1, MAC-RQ-2, etc.)

  1. Sort requirements by linked test case count

{
  "projectKey": "MAC",
  "sort": "[{\"property\":\"linkedTcCount\",\"direction\":\"DESC\"}]"
}

Expected Output: Requirements sorted by number of linked test cases, highest first

  1. Complex filter: Requirements by owner with specific state

{
  "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

  1. Multi-field sort: Priority first, then creation date

{
  "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)

  1. Filter requirements by specific release and cycle

{
  "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)

  1. Filter requirements by release only

{
  "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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
sortNoSort Records - refer json schema, Possible property - name, entityKey, associatedVersion, priorityAlias, createdDate, createdByAlias, updatedDate, updatedByAlias, requirementStateAlias, linkedTcCount, linkedDfCount, attachmentCount, createdSystem, owner[{"property":"name","direction":"ASC"}]
limitNoNumber of records (default 10).
scopeNoScope 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.project
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
viewIdNoViewId 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.
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
udfFilterNoUser-defined field filter as JSON string (default '[]')[]
filterTypeNoPass 'QMETRY' or 'JIRA'QMETRY
folderPathNoFolder 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".
projectKeyNoProject key - unique identifier for the projectdefault
isJiraFilterNo'false' if using qmetry filter
getSubEntitiesNoWhether to include sub-entities.
folderSortOrderNoFolder sort order (ASC or DESC)
folderSortColumnNoFolder sort column (default 'name')
hideEmptyFoldersNoWhether to hide empty folders.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool automatically resolves viewId, supports pagination, filtering, and returns a JSON with 'data' array and pagination info. No side effects are mentioned, but they are not expected given the annotations. The description adds useful behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured: brief summary, parameter list, output description, use cases, examples, hints. Some repetition (e.g., sort fields listed twice), but the length is justified by the tool's complexity (17 parameters). The front-loaded summary helps quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 17 parameters, no output schema, and no nested objects, the description is comprehensive: covers all parameters, provides 17 examples, explains auto-resolution, filter/sort formats, and pagination. The only minor gap is the lack of detailed response structure beyond 'data array and pagination info', but the examples implicitly show the output context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline 3. The description adds extensive meaning: defaults, auto-resolution behavior for viewId and folderPath, filter and sort format examples, and multiple examples for filter/sort combinations. This far exceeds the baseline by making all 17 parameters actionable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Fetch QMetry requirements' and differentiates from sibling tools like 'qmetry_fetch_requirement_details' (singular) and 'qmetry_fetch_requirements_linked_to_test_case' (linked). The verb-noun combination is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use Cases' section lists six common scenarios, and the 'Hints' provide a step-by-step workflow (e.g., always use the same projectKey, auto-resolution of viewId). However, there is no explicit 'when not to use' this tool versus the sibling 'qmetry_fetch_requirement_details', though the context of listing vs. single detail is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SmartBear/smartbear-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server