testmo-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TESTMO_TOKEN | Yes | API access key (Testmo → User Profile → API access) | |
| TESTMO_INSTANCE | Yes | Your Testmo URL, e.g. https://your-team.testmo.net | |
| TESTMO_DEFAULT_FOLDER_ID | No | Default folder for new cases so Testmo doesn't auto-create one each time |
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 |
|---|---|
| testmo_list_projectsA | List all Testmo projects (id, name, run/milestone counts). |
| testmo_list_runsA | List manual test runs for a project. Supports optional name filter, open/closed filter, milestone filter and pagination. |
| testmo_get_runA | Get a single run's summary (name, status counts, totals, milestone). |
| testmo_list_resultsA | List recorded test results for a run. Note: this returns tests that have a recorded result, not necessarily every case in the run. The per-result |
| testmo_list_statusesA | List the result statuses for a project (id → name, e.g. Passed/Failed/Blocked). Needed to know which status_id to use when recording a result. |
| testmo_record_resultA | Record a result for one test in a run. |
| testmo_getA | Escape hatch: perform a raw GET against any Testmo API path (everything after /api/v1). Use for endpoints not covered by the other tools. |
| testmo_list_statesA | List workflow states for a project (run, repository_case, session). Needed for state_id when creating a run or a case. |
| testmo_list_templatesA | List case templates for a project. Needed for template_id when creating cases (and to know which custom_* fields a template accepts). |
| testmo_list_casesA | List test cases in a project's repository. Supports folder/name/template filters and pagination. |
| testmo_create_runA | Create a new manual test run in a project. Requires name, state_id (from testmo_list_states, entity 'run') and include_all. When include_all is false you must pass |
| testmo_update_runA | Update a run (PATCH). Only provided fields change. Set is_closed=true to close a run (runs cannot be re-opened via the API; false is rejected). |
| testmo_record_results_bulkA | Record results for multiple tests in a run in one request (1-100). Each item needs test_id (the per-run test id from testmo_list_results) and status_id. All items are validated before any are written — an invalid item rejects the whole batch. |
| testmo_create_casesA | Create one or more test cases (1-100) in a project's repository. Each case needs a name; folder_id/template_id/state_id are optional (defaults used). Steps and other template-specific fields go in |
| testmo_update_casesA | Update 1-100 repository cases (PATCH). Pass |
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 15 tools
Each tool targets a distinct resource and action. The only potential overlap is record_result vs record_results_bulk, but they are clearly single vs bulk operations. The escape hatch testmo_get is explicitly for uncovered endpoints, so no confusion.
The testmo_ prefix and verb_noun pattern are consistent across tools (list_projects, create_run, update_cases). The single exception is testmo_get which lacks a noun object, but as a general escape hatch this is a minor deviation.
15 tools is at the upper boundary of the ideal range but each tool serves a clear purpose in the Testmo workflow, covering projects, runs, results, cases, and supporting lookup data (statuses, states, templates).
Core CRUD for runs and cases is covered (create, list/get, update) though delete is missing. Results can be listed and recorded both single and bulk. The escape hatch covers additional GET endpoints but not other HTTP methods. Overall the main workflows are covered.