TestOps MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TESTOPS_URL | Yes | The URL of the TestOps server. | |
| TESTOPS_TOKEN | Yes | The API token for authentication. | |
| NODE_TLS_REJECT_UNAUTHORIZED | No | Set to '0' to disable TLS verification (for self-signed certificates or corporate proxies). | 1 |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project_listA | List all projects with pagination |
| project_find_by_nameA | Find a project by exact or partial name match |
| project_get_by_idB | Get a project by its ID |
| project_get_test_case_treesA | Get test case trees for a project. Use the returned tree IDs with testcase_list_in_tree. |
| launch_listB | List launches for a project with pagination |
| launch_getC | Get a launch by ID |
| launch_createB | Create a test run (launch). Body requires name and projectId. |
| launch_stopB | Close/stop a running launch (ends the run on TestOps). |
| launch_get_statisticC | Launch run summary: counts by test status and progress (ready). |
| launch_list_test_resultsA | Flat paginated test results for a launch (rows: id, name, testCaseId, status, duration, etc.). |
| testplan_listA | List test plans for a project with pagination |
| testplan_getB | Get a test plan by ID |
| testplan_get_test_casesA | Get test cases from a test plan with pagination |
| testplan_runC | Create a launch from a test plan. Body requires launchName. |
| testplan_syncB | Sync test plan with its source: refreshes the test case list in the plan to match the current source. |
| testplan_get_statA | Test plan statistics: automated/manual counts, durations. Useful before running to estimate effort. |
| testcase_getC | Get a test case by ID |
| testcase_get_detailA | Aggregated card: name, description, tags, custom fields, and step texts as a simple list. |
| testcase_get_scenarioB | Normalized scenario JSON (scenarioSteps, step bodies, expected results). |
| testcase_get_stepC | Alias for testcase_get_scenario. |
| testcase_get_custom_fieldsC | Get custom field values for a test case |
| testcase_updateA | Update test case metadata (name, description, status, tags, etc.). Does NOT change steps or custom fields — use testcase_set_scenario / testcase_update_custom_fields for those. |
| testcase_update_stepB | Update one scenario step by its step id. |
| testcase_set_scenarioC | Replace all steps in a test case scenario |
| testcase_update_custom_fieldsB | Update custom field values for a test case |
| testcase_createB | Create a new test case in TestOps. Required: name and projectId. Optional: steps, customFields, tags, precondition, etc. |
| testcase_list_in_treeB | List test cases under a project tree with pagination. Use parentNodeId to page into a folder. |
| testcase_search_by_aqlC | Search test cases using AQL query with pagination |
| project_get_custom_fieldsA | Get custom field definitions for a project with pagination. Returns { items, total, page, size } for chunked fetching. |
| project_get_custom_field_valuesA | Get available values for a custom field with pagination. Returns { items, total, page, size } so the model can fetch in chunks. |
| pingA | Test tool to verify server connectivity |
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 31 tools
Each tool targets a distinct entity and action, with no overlapping purposes. Aliases like testcase_get_step for testcase_get_scenario are clearly documented as such.
All tools follow a consistent verb_noun pattern with underscores, e.g., project_list, testcase_create. Even multi-word actions like testcase_update_custom_fields maintain the pattern.
31 tools is on the higher side but well-scoped for a full-featured test management server. Each tool has a clear purpose and covers core workflows without being excessive.
The tool set lacks any delete operations for projects, test plans, launches, or test cases. This is a significant gap for CRUD completeness and will likely cause agent failures when deletion is needed.