qtm4j-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QTM4J_API_KEY | Yes | QTM4J Open API key | |
| QTM4J_BASE_URL | No | API base URL | https://qtmcloud.qmetry.com/rest/api/latest |
| QTM4J_PROJECT_ID | No | Default project ID (avoids passing it in every call) | |
| NODE_TLS_REJECT_UNAUTHORIZED | No | Set to '0' for self-signed certs |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_test_cycleB | Create a new test cycle (run) in QTM4J. Returns the cycle ID. |
| search_test_caseB | Search for a test case by key (e.g. PE26-TC-2). Returns test case ID and version. |
| search_test_casesA | Paginated POST /testcases/search. Returns the raw API JSON (includes data, total, startAt, maxResults when provided). Use startAt/maxResults for paging; summaryContains adds a leading ~ for contains-style summary filter when not already present. |
| list_all_project_test_casesA | Fetches all pages of /testcases/search for a project until a short page or maxPages. Merges rows and dedupes by test case key when present. Use for exporting or counting beyond a single page. |
| create_test_caseB | Create a new test case in QTM4J. Returns testCaseId, versionNo, and optional folderId / pickedFolder / folderWarning. Use folderId, or autoPickFolder with optional folderKeywords. |
| list_cycle_test_casesB | List all test cases in a test cycle with their execution IDs. |
| add_test_case_to_cycleB | Add a test case to a test cycle. Returns the execution ID. |
| update_execution_statusC | Update execution result (Pass/Fail) for a test case execution in a cycle. |
| close_test_cycleB | Close a test cycle by setting its status to Done. |
| get_attachment_urlB | Get a presigned URL for uploading an attachment to a test case execution. |
| add_test_case_stepsB | Create test steps on a test case version (POST …/teststeps). steps[].stepDetails is required. |
| add_test_case_to_foldersB | Add a test case version to folders (PUT …/versions/{no} with folders.add). Use folder ids from list_test_case_folders. |
| create_test_case_folderB | Create a testcase folder (POST /projects/{projectId}/testcase-folders). parentId -1 = root. |
| get_test_caseA | GET /testcases/{id}; on failure resolves by key via search. Optional versionNo returns version details instead of slim record. |
| get_test_case_detailsB | GET /testcases/{id}/versions/{no} full version payload. Optional fields= comma-separated. |
| get_test_case_stepsB | POST …/teststeps/search (QTM4J GetTestStepRequest). Pagination: query startAt & maxResults (max 100). Body is {} to list all steps, or { filter: { stepDetails?, testData?, expectedResult? } } — no projectId in the filter. Optional sort is a query parameter. |
| list_test_case_foldersC | GET /projects/{id}/testcase-folders plus flatFolders (id, name, path). |
| remove_test_case_from_foldersB | Remove a test case version from folders (PUT …/versions/{no} with folders.delete). |
| update_test_case_descriptionB | Update the description field on a test case version (PUT …/testcases/{id}/versions/{no} with description). |
| update_test_case_stepA | Edit an existing test step (PUT …/versions/{v}/teststeps with a JSON array). stepId is the numeric id from get_test_case_steps. Provide at least one of stepDetails, expectedResult, testData. |
| update_test_case_summaryA | Update the summary (title) on a test case version (PUT …/testcases/{id}/versions/{no} with summary). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Each tool has a clearly distinct purpose. Even similar operations like 'get_test_case' vs 'get_test_case_details' are differentiated by their descriptions and the level of detail returned. The three 'add_' tools target different entities (steps, cycle, folders), so no ambiguity.
All tool names follow a consistent 'verb_noun' pattern with snake_case. Verbs like 'add_', 'create_', 'get_', 'list_', 'update_' are used appropriately, making the tool set predictable and easy to navigate.
21 tools is well-scoped for a test management server. Each tool serves a specific function without overloading the user. The count is large enough to cover essential operations but not excessive.
The tool set lacks several obvious operations: no 'list_test_cycles' (only list test cases within a cycle), no delete tools for test cases, cycles, or folders, no 'remove_test_case_from_cycle'. These gaps could hinder agents from completing full workflows.