How do I use testmonitor-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@testmonitor-mcp What are the latest test run results in the Alpha project?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

testmonitor-mcp

by deanchong

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

TestMonitor MCP server

A local Node.js MCP server that lets AI agents interact with TestMonitor through 173 tools generated from the official TestMonitor REST API specification. Uses the official MCP SDK and stdio transport; no build step or public web server is needed.

Supports projects, members, applications, versions, requirements, risks, test cases and folders, test runs, test results, issues, comments, attachments, teams, users, webhooks, custom fields, and status lookups. See TOOLS.md for the complete catalog. Available operations still depend on your TestMonitor permissions and subscription.

Local installation (optional)

Requires Node.js 22 or later. Skip this manual installation if you use the npx configuration below.

git clone https://github.com/deanchong/testmonitor-mcp.git
cd testmonitor-mcp
npm ci
cp .env.example .env

Edit .env with your instance URL and Personal Access Token. In TestMonitor, open My Account → API → Create token. Keep the token private; .env is excluded from Git.

TESTMONITOR_URL=https://yourcompany.testmonitor.com
TESTMONITOR_TOKEN=your-token
TESTMONITOR_READ_ONLY=false

Start manually with:

node --env-file=.env src/index.js

The process waits for MCP messages on stdin. It is not an interactive command prompt. Protocol messages are the only stdout output. npm start also works when the environment variables are already exported; it does not automatically load .env.

Related MCP server: TestRail MCP Server

Connect your AI agent

Configure your AI agent harness to launch this server as a local stdio MCP server. The harness starts the process and discovers its tools. GitHub provides the downloadable package; each user supplies their own TestMonitor URL and token.

Recommended: launch with npx

Requires Node.js 22+, npm (which includes npx), and Git on the machine running the harness. No manual clone or npm ci is needed for this option.

Add this entry to your harness's MCP configuration, preserving any existing servers. This example uses the common mcpServers structure; adapt the outer structure to your harness while keeping the command, arguments, and environment values:

{
  "mcpServers": {
    "testmonitor": {
      "command": "npx",
      "args": [
        "--yes",
        "--package=github:deanchong/testmonitor-mcp#main",
        "testmonitor-mcp"
      ],
      "env": {
        "TESTMONITOR_URL": "https://yourcompany.testmonitor.com",
        "TESTMONITOR_TOKEN": "your-personal-access-token",
        "TESTMONITOR_READ_ONLY": "false"
      }
    }
  }
}

Replace the URL and token with your own values, then restart or reconnect your harness. Create a token in TestMonitor under My Account → API → Create token. Keep your configuration private or use your harness's secret-management mechanism. Set TESTMONITOR_READ_ONLY to true if you only need read access.

On launch, npx downloads the specified GitHub revision and installs its dependencies into npm's local cache when needed, then starts testmonitor-mcp. The harness communicates with that process over stdio, and the process calls your TestMonitor API. --yes allows package installation without an interactive prompt. The public repository alone does not automatically register or launch the server. See npm exec / npx documentation.

If the harness cannot find npx, use its full executable path (which npx on macOS/Linux or where npx on Windows). Windows harnesses may require npx.cmd or their documented command-shell wrapper.

The example uses #main, which follows a moving branch. For repeatable startup, replace main with a reviewed commit's full SHA from this repository. npm caching means you should not assume every launch fetches the latest code. This repository does not need to be published to npm for the GitHub package command to work.

Alternative: launch an installed copy with node

Complete Local installation above and configure the harness to launch your installed copy:

{
  "mcpServers": {
    "testmonitor": {
      "command": "node",
      "args": [
        "--env-file=/absolute/path/to/testmonitor-mcp/.env",
        "/absolute/path/to/testmonitor-mcp/src/index.js"
      ]
    }
  }
}

Replace both placeholders with actual absolute paths. For Windows JSON, use escaped backslashes, such as C:\\Users\\you\\testmonitor-mcp\\src\\index.js. If your client cannot find Node, use its absolute executable path. Clients with a different configuration format need the same command and arguments. Restart or reconnect after changing settings. This option runs the local checkout; update it explicitly with git pull --ff-only followed by npm ci.

npx versus node

Command	Package setup	What runs
`npx`	Downloads the specified package and installs dependencies when needed; can reuse npm's cache	The package's `testmonitor-mcp` executable
`node`	You clone/download the project and install dependencies first	The local `src/index.js` file

Both start the same Node.js MCP server. Choose npx for configuration-based installation or node for a local checkout you manage yourself. This project implements stdio only; a harness that accepts only remote MCP URLs needs a separately configured transport or gateway. The GitHub URL is not an MCP endpoint.

Try the connection

Suggested agent requests:

“List my TestMonitor projects.”
“Find login test cases in project 7.”
“Create a test case for a failed login in project 7.”
“List result statuses, then record the outcome for test case 42 in run 5.”

Tool arguments

Each tool publishes its JSON Schema to the agent. Arguments are grouped into path, query, and body; only applicable groups are present. Operation names follow the upstream operation IDs in snake_case. The upstream GetTestRuneCollection typo is exposed as get_test_run_collection.

List test cases:

{
  "name": "get_test_case_collection",
  "arguments": {
    "query": {
      "project_id": 7,
      "query": "login",
      "limit": 25,
      "page": 1,
      "order": "-name",
      "filter": { "draft": false },
      "with": ["requirements", "risks"]
    }
  }
}

Create a test case:

{
  "name": "post_test_case",
  "arguments": {
    "body": {
      "project_id": 7,
      "name": "Valid login",
      "instructions": ["Open the login page", "Enter valid credentials", "Submit"],
      "expected_result": "The dashboard is displayed"
    }
  }
}

Record a result (look up the actual status ID with get_test_result_states_collection first):

{
  "name": "post_test_result",
  "arguments": {
    "body": {
      "test_case_id": 42,
      "test_run_id": 5,
      "draft": false,
      "test_result_status_id": 2,
      "description": "Dashboard displayed as expected."
    }
  }
}

Upload an attachment using post_test_case_attachment, post_issue_attachment, or post_test_result_attachment. The file is supplied as { "filename": "note.txt", "base64": "aGVsbG8=", "mimeType": "text/plain" } in body.file, with the entity ID in path. Files are limited to 14 million base64 characters (approximately 10 MiB). The server does not read local files. Result create/update tools use JSON; add attachments separately after obtaining the result ID.

Behavior and configuration

Environment variable	Purpose
`TESTMONITOR_URL`	Required HTTPS instance URL, optionally ending in `/api/v1`
`TESTMONITOR_TOKEN`	Required Personal Access Token
`TESTMONITOR_READ_ONLY`	`true` exposes and permits only GET tools; defaults to `false`
`TESTMONITOR_TIMEOUT_MS`	Request timeout, default `30000`, range 1–300000
`TESTMONITOR_TOOLS`	Optional comma-separated exact tool names; unknown names fail startup

Use the tool allowlist to reduce the catalog for agents with tool-count limits, for example:

TESTMONITOR_TOOLS=get_project_collection,get_test_case_collection,post_test_case,get_test_run_collection,get_test_result_states_collection,post_test_result

Tool responses contain { status, ok, data } and optionally retryAfter. HTTP failures set MCP isError: true. TestMonitor validation details are retained.
Collections return one page with the original data, links, and meta envelope. Request subsequent pages explicitly with query.page. The API's documented limit is 5–100, with a default of 15.
Filters use bracket notation, nested custom-field filters are supported, and array filters use the JSON-array form documented in the introduction. Relations use comma-separated values. Descending sort values are added to upstream enums because the introduction explicitly documents them.
Requests use Bearer authentication, HTTPS, a fixed configured origin, redirect rejection, cancellation, and a timeout. Responses are capped at 10 MiB.
Failed requests are not retried automatically, avoiding duplicate writes. Inspect errors before deciding whether another attempt is appropriate; timed-out writes may have succeeded remotely.
Writes, deletes, comments, user administration, and webhooks operate on the live instance. MCP annotations identify mutations; they are hints for the agent, not an approval system. Use TestMonitor account permissions, read-only mode, and an allowlist to constrain access.
Schemas preserve upstream validation and incomplete definitions. The API remains authoritative for business rules and fields whose types are underspecified. Deprecated endpoints remain available and are identified in their descriptions.

Development and validation

npm run generate
npm run check
npm test

The tests use the MCP client over in-memory transport and a real stdio child process, with mocked HTTP responses. They cover tool discovery, schema validation, JSON writes, batch requests, pagination/filter encoding, multipart uploads, access restrictions, and errors. They do not access a live TestMonitor instance.

The checked-in spec/openapi.yaml is the official version 8.3.1 specification retrieved on 2026-09-06 from docs.testmonitor.com/openapi.yaml. It is kept for reproducible generation and retains its upstream license metadata. The upstream license name and URL disagree; this project does not reinterpret them. To update, replace that file with a reviewed upstream specification, run npm run generate, review the generated changes, and run tests. Runtime startup never downloads documentation.

Source layout: scripts/generate.js builds the catalog; src/client.js handles HTTP; src/server.js validates and dispatches MCP tools; src/index.js starts stdio transport. src/operations.json and TOOLS.md are generated files.

Available Tools

173 tools

archive_projectB

Destructive

Archive a project. Archive a project using its unique identifier. Archived projects are read-only and no longer appear in the project overview.

Inputs: path (required).

archive_userB

Destructive

Archive a user. Archive a user using its unique identifier.

Archived users can no longer sign in or be assigned to projects and test runs, but their historical data is preserved.

Inputs: path (required).

clone_test_runB

Destructive

Clone a test run. Create a copy of an existing test run using its unique identifier.

The cloned test run optionally includes the same test cases and user assignments, allowing you to quickly set up a new test run with similar configurations.

Inputs: body (required), path (required).

close_test_runB

Destructive

Close a test run. Close a test run using its unique identifier, marking it as completed. Closed test runs can be reopened if further testing is needed.

Inputs: path (required).

delete_applicationB

Destructive

Delete an application. Delete an application using its unique identifier. Deleted applications are moved to the trash and can be restored later if needed.

Inputs: path (required).

delete_folderA

Destructive

Delete a folder. Delete a test case folder using its unique identifier. Deleted folders are moved to the trash and can be restored later if needed.

When you delete a folder, all test cases and subfolders within that folder are also moved to the trash.

Inputs: path (required).

delete_issueB

Destructive

Delete an issue. Delete an issue using its unique identifier. Deleted issues are moved to the trash and can be restored later if needed.

Inputs: path (required).

delete_issue_attachmentC

Destructive

Delete an attachment from an issue. Delete an attachment from an issue using its unique identifier.

Inputs: path (required).

delete_issue_taskC

Destructive

Delete a task. Delete a task using its unique identifier.

Inputs: path (required).

delete_issue_test_resultC

Destructive

Unlink a test result from an issue. Unlink a test result from an issue using its unique identifier.

Inputs: path (required).

delete_milestoneB

Destructive

Delete a milestone. Delete a milestone using its unique identifier. Deleted milestones are moved to the trash and can be restored later if needed.

Inputs: path (required).

delete_requirementB

Destructive

Delete a requirement. Delete a requirement using its unique identifier. Deleted requirements are moved to the trash and can be restored later if needed.

Inputs: path (required).

delete_riskA

Destructive

Delete a risk. Delete a risk using its unique identifier. Deleted risks are moved to the trash and can be restored later if needed.

Inputs: path (required).

delete_teamB

Destructive

Delete a team. Delete a team using its unique identifier. Deleted teams are moved to the trash and can be restored later if needed.

Inputs: path (required), query.

delete_team_memberC

Destructive

Remove a member from a team. Remove a member from a team using the team and user identifiers.

Inputs: path (required).

delete_test_caseB

Destructive

Delete a test case. Delete a test case using its unique identifier. Deleted test cases are moved to the trash and can be restored later if needed.

Inputs: path (required).

delete_test_case_attachmentB

Destructive

Delete an attachment from a test case. Delete a specific attachment from a test case using both the test case identifier and the attachment identifier. This permanently removes the file from the test case.

Inputs: path (required).

delete_test_environmentB

Destructive

Delete an environment. Delete a test environment using its unique identifier. This action is permanent and cannot be undone.

Inputs: path (required).

delete_test_result_attachmentC

Destructive

Delete an attachment from a test result. Delete an attachment from a test result using its unique identifier.

Inputs: path (required).

delete_test_runB

Destructive

Delete a test run. Delete a test run using its unique identifier. Deleted test runs are moved to the trash and can be restored later if needed.

Inputs: path (required).

delete_userA

Destructive

Delete a user. Permanently delete a user using its unique identifier. This action cannot be undone.

Consider archiving the user instead if you want to retain their data and history.

Inputs: path (required).

delete_webhookB

Destructive

Delete a webhook. Delete a webhook using its unique identifier. This action is permanent and cannot be undone.

Inputs: path (required).

get_applicationB

Read-onlyIdempotent

Get a specific application. Retrieve a specific application using its unique identifier. Use the relations parameter to include associated data in a single request.

Inputs: path (required), query.

get_application_collectionC

Read-onlyIdempotent

Get all applications. Retrieve all applications.

Apply sorting and pagination to organize the results. Include related data using the relations parameter.

Inputs: query.

get_application_versionsC

Read-onlyIdempotent

Get all versions for an application. Retrieve all versions for an application using its unique identifier.

Inputs: path (required).

get_custom_field_collectionB

Read-onlyIdempotent

Get all custom fields. Retrieve all custom fields for a project. Use the model parameter to filter custom fields by resource type (i.e., requirements, risks, test cases, test runs, or issues).

Inputs: query (required).

get_folderB

Read-onlyIdempotent

Get a specific folder. Retrieve a specific test case folder using its unique identifier. This endpoint returns all details of the folder, including its name, description, and parent folder.

Inputs: path (required).

get_folders_collectionB

Read-onlyIdempotent

Get all folders. Retrieve all test case folders from a project.

Use the parent identifier to filter folders by their parent folder, allowing you to navigate the folder hierarchy level by level.

Inputs: query (required).

get_issueB

Read-onlyIdempotent

Get a specific issue. Retrieve a specific issue using its unique identifier. Use the relations parameter to include associated data in a single request.

Inputs: path (required), query.

get_issue_attachmentsC

Read-onlyIdempotent

Get all attachments for an issue. Retrieve all attachments for an issue using its unique identifier.

Inputs: path (required).

get_issue_categories_collectionB

Read-onlyIdempotent

Get project issue categories. Retrieve all issue categories configured for a project. Issue categories classify issues by their type, such as bug, feature, or test design.

Inputs: path (required), query.

get_issue_collectionB

Read-onlyIdempotent

Get all issues. Retrieve all issues from a project.

Apply custom filters, sorting, and pagination to find the issues you need. Include related data using the relations parameter.

Inputs: query (required).

get_issue_commentsC

Read-onlyIdempotent

Get all comments for an issue. Retrieve all comments for an issue using its unique identifier.

Inputs: path (required).

get_issue_priorities_collectionB

Read-onlyIdempotent

Get project issue priorities. Retrieve all issue priorities configured for a project. Issue priorities indicate the urgency of an issue.

Inputs: path (required), query.

get_issue_resolutions_collectionB

Read-onlyIdempotent

Get project issue resolutions. Retrieve all issue resolutions configured for a project. Issue resolutions describe how an issue was resolved.

Inputs: path (required), query.

get_issue_statuses_collectionB

Read-onlyIdempotent

Get project issue statuses. Retrieve all issue statuses configured for a project. Issue statuses track the current state of an issue in your workflow.

Inputs: path (required), query.

get_issue_tagsC

Read-onlyIdempotent

Get all tags for an issue. Retrieve all tags assigned to an issue using its unique identifier.

Inputs: path (required).

get_issue_tags_collectionB

Read-onlyIdempotent

Get all issue tags. Retrieve all tags that are currently used on issues within a project.

Tags are labels that help categorize and organize issues, making it easier to filter and group related issues.

Inputs: query (required).

get_issue_taskC

Read-onlyIdempotent

Get a specific task. Retrieve a specific task using its unique identifier.

Inputs: path (required).

get_issue_tasksC

Read-onlyIdempotent

Get all tasks for an issue. Retrieve all tasks for an issue using its unique identifier.

Inputs: path (required).

get_issue_test_resultsC

Read-onlyIdempotent

Get all test results linked to an issue. Retrieve all test results linked to an issue using its unique identifier.

Inputs: path (required).

get_milestoneC

Read-onlyIdempotent

Get a specific milestone. Retrieve a specific milestone using its unique identifier. Use the relations parameter to include associated data in a single request.

Inputs: path (required), query.

get_milestone_collectionB

Read-onlyIdempotent

Get all milestones. Retrieve all milestones from a project.

Apply custom filters, sorting, and pagination to find the milestones you need. Include related data using the relations parameter.

Inputs: query (required).

get_milestone_types_collectionB

Read-onlyIdempotent

Get all milestone types. Retrieve all milestone types configured for a project. Milestone types categorize milestones by their purpose, such as releases or sprints.

Inputs: path (required), query.

get_my_issue_collectionB

Read-onlyIdempotent

Get all assigned issues. Retrieve all issues assigned to the authenticated user.

Apply custom filters, sorting, and pagination to find the issues you need. Include related data using the relations parameter.

Inputs: query.

get_my_issue_tasks_collectionC

Read-onlyIdempotent

Get all assigned tasks. Retrieve all tasks assigned to the authenticated user. Apply pagination to navigate through the results.

Inputs: query.

get_my_project_collectionB

Read-onlyIdempotent

Get all assigned projects. Retrieve all projects that the authenticated user is a member of.

Apply custom filters, sorting, and pagination to find the projects you need. Include related data using the relations parameter.

Inputs: query.

get_my_test_run_collectionA

Read-onlyIdempotent

Get all assigned test runs. Retrieve all test runs assigned to the currently authenticated user.

Apply custom filters, sorting, and pagination to find the test runs you need. Include related data using the relations parameter.

Inputs: query (required).

get_projectC

Read-onlyIdempotent

Get a specific project. Retrieve a specific project using its unique identifier.

Inputs: path (required).

get_project_collectionB

Read-onlyIdempotent

Get all projects. Retrieve all projects.

Apply custom filters, sorting, and pagination to find the projects you need. Include related data using the relations parameter.

Inputs: query.

get_project_members_collectionC

Read-onlyIdempotent

Get all project members. Retrieve all members of a project. Project members have access to the project's resources and can perform actions based on their roles.

Inputs: path (required), query.

get_requirementB

Read-onlyIdempotent

Get a specific requirement. Retrieve a specific requirement using its unique identifier.

This endpoint returns all details of the requirement, including its name, description, type, and custom fields.

Use the relations parameter to include associated data in a single request.

Inputs: path (required), query.

get_requirement_collectionB

Read-onlyIdempotent

Get all requirements. Retrieve all requirements from a project.

Apply custom filters, sorting, and pagination to find the requirements you need. Include related data using the relations parameter.

Inputs: query (required).

get_requirement_tagsA

Read-onlyIdempotent

Get all tags for a requirement. Retrieve all tags assigned to a specific requirement using its unique identifier.

Inputs: path (required).

get_requirement_tags_collectionB

Read-onlyIdempotent

Get all requirement tags. Retrieve all tags that are currently used on requirements within a project.

Tags are labels that help categorize and organize requirements, making it easier to filter and group related requirements.

Inputs: query (required).

get_requirement_test_casesC

Read-onlyIdempotent

Get test cases assigned to a requirement. Retrieve all test cases assigned to a specific requirement using its unique identifier.

Inputs: path (required).

get_requirement_types_collectionB

Read-onlyIdempotent

Get all requirement types. Retrieve all requirement types configured for a project. Requirement types classify requirements by their nature, such as functional or non-functional.

Inputs: path (required), query.

get_riskB

Read-onlyIdempotent

Get a specific risk. Retrieve a specific risk using its unique identifier.

This endpoint returns all details of the risk, including its name, description, classification, and custom fields.

Use the relations parameter to include associated data in a single request.

Inputs: path (required), query.

get_risk_classifications_collectionC

Read-onlyIdempotent

Get all risk classifications. Retrieve all risk classifications configured for a project. Risk classifications categorize risks by their type.

Inputs: path (required), query.

get_risk_collectionB

Read-onlyIdempotent

Get all risks. Retrieve all risks from a project.

Apply custom filters, sorting, and pagination to find the risks you need. Include related data using the relations parameter.

Inputs: query (required).

get_risk_tagsC

Read-onlyIdempotent

Get all tags for a risk. Retrieve all tags assigned to a specific risk using its unique identifier.

Inputs: path (required).

get_risk_tags_collectionB

Read-onlyIdempotent

Get all risk tags. Retrieve all tags that are currently used on risks within a project.

Tags are labels that help categorize and organize risks, making it easier to filter and group related risks.

Inputs: query (required).

get_risk_test_casesC

Read-onlyIdempotent

Get test cases assigned to a risk. Retrieve all test cases assigned to a specific risk using its unique identifier.

Inputs: path (required).

get_symbols_collectionC

Read-onlyIdempotent

Get all symbols. Retrieve all available symbols.

Inputs: no named parameters.

get_teamC

Read-onlyIdempotent

Get a specific team. Retrieve a specific team using its unique identifier.

Inputs: path (required), query.

get_team_collectionB

Read-onlyIdempotent

Get all teams. Retrieve all teams.

Apply custom filters, sorting, and pagination to find the teams you need. Include related data using the relations parameter.

Inputs: query.

get_team_membersB

Read-onlyIdempotent

Get all members of a team. Retrieve all members of a specific team using its unique identifier.

Inputs: path (required).

get_test_caseA

Read-onlyIdempotent

Get a specific test case. Retrieve a specific test case using its unique identifier.

This endpoint returns all details of the test case, including its steps, expected results, priority, and custom fields.

Use the relations parameter to include associated data in a single request.

Inputs: path (required), query.

get_test_case_applicationsB

Read-onlyIdempotent

Get all applications for a test case. Retrieve all applications assigned to a specific test case using its unique identifier.

Applications represent different versions or variants of your software that need to be tested.

Inputs: path (required).

get_test_case_attachmentsC

Read-onlyIdempotent

Get all attachments for a test case. Retrieve all attachments associated with a specific test case using its unique identifier.

Inputs: path (required).

get_test_case_collectionA

Read-onlyIdempotent

Get all test cases. Retrieve all test cases from a project.

Use the folder identifier to filter test cases by specific folders, or apply custom filters, sorting, and pagination to find the test cases you need. Include related data using the relations parameter.

Inputs: query (required).

get_test_case_commentsC

Read-onlyIdempotent

Get all comments for a test case. Retrieve all comments for a test case using its unique identifier.

Inputs: path (required).

get_test_case_issuesC

Read-onlyIdempotent

Get all issues for a test case. Retrieve all issues associated with a specific test case using its unique identifier.

Inputs: path (required).

get_test_case_requirementsC

Read-onlyIdempotent

Get all requirements for a test case. Retrieve all requirements assigned to a specific test case using its unique identifier.

Inputs: path (required).

get_test_case_risksB

Read-onlyIdempotent

Get all risks for a test case. Retrieve all risks assigned to a specific test case using its unique identifier.

Inputs: path (required).

get_test_case_tagsC

Read-onlyIdempotent

Get all tags for a test case. Retrieve all tags assigned to a specific test case using its unique identifier.

Inputs: path (required).

get_test_case_tags_collectionB

Read-onlyIdempotent

Get all test case tags. Retrieve all tags that are currently used on test cases within a project.

Tags are labels that help categorize and organize test cases, making it easier to filter and group related test cases.

Inputs: query (required).

get_test_case_test_resultsC

Read-onlyIdempotent

Get all test results for a test case. Retrieve the complete execution history for a specific test case using its unique identifier.

Inputs: path (required).

get_test_case_test_runsB

Read-onlyIdempotent

Get all test runs for a test case. Retrieve all test runs that include a specific test case using its unique identifier.

Inputs: path (required).

get_test_environmentC

Read-onlyIdempotent

Get a specific environment. Retrieve a specific test environment using its unique identifier.

Inputs: path (required).

get_test_environment_collectionC

Read-onlyIdempotent

Get all environments. Retrieve all test environments.

Apply sorting and pagination to organize the results.

Inputs: query.

get_test_resultB

Read-onlyIdempotent

Get a specific test result. Retrieve a specific test result using its unique identifier. Use the relations parameter to include associated data in a single request.

Inputs: path (required), query.

get_test_result_attachmentsC

Read-onlyIdempotent

Get all attachments for a test result. Retrieve all attachments for a test result using its unique identifier.

Inputs: path (required).

get_test_result_collectionB

Read-onlyIdempotent

Get all test results. Retrieve all test results from a project.

Apply custom filters, sorting, and pagination to find the test results you need. Include related data using the relations parameter.

Inputs: query (required).

get_test_result_commentsC

Read-onlyIdempotent

Get all comments for a test result. Retrieve all comments for a test result using its unique identifier.

Inputs: path (required).

get_test_result_issuesB

Read-onlyIdempotent

Get all issues for a test result. Retrieve all issues linked to a test result using its unique identifier.

Inputs: path (required).

get_test_result_states_collectionB

Read-onlyIdempotent

Get all test result statuses. Retrieve all test result statuses configured for a project. Test result statuses define the possible outcomes when executing a test case.

Inputs: query (required).

get_test_runB

Read-onlyIdempotent

Get a specific test run. Retrieve a specific test run using its unique identifier.

This endpoint returns all details of the test run, including its name, environment, state, and custom fields.

Use the relations parameter to include associated data in a single request.

Inputs: path (required).

get_test_run_collectionB

Read-onlyIdempotent

Get all test runs. Retrieve all test runs from a project.

Apply custom filters, sorting, and pagination to find the test runs you need. Include related data using the relations parameter.

Inputs: query (required).

get_test_run_states_collectionA

Read-onlyIdempotent

Get all test run states. Retrieve all available test run states. Test run states represent the lifecycle stages a test run can be in, such as open, in progress or closed.

Inputs: no named parameters.

get_test_run_tagsC

Read-onlyIdempotent

Get all tags for a test run. Retrieve all tags assigned to a specific test run using its unique identifier.

Inputs: path (required).

get_test_run_tags_collectionA

Read-onlyIdempotent

Get all test run tags. Retrieve all tags that are currently used on test runs within a project.

Tags are labels that help categorize and organize test runs, making it easier to filter and group related test runs.

Inputs: query (required).

get_test_run_test_casesB

Read-onlyIdempotent

Get all test cases for a test run. Retrieve all test cases assigned to a specific test run using its unique identifier.

Inputs: path (required).

get_test_run_test_resultsB

Read-onlyIdempotent

Get all test results for a test run. Retrieve all test results for a specific test run using its unique identifier.

Inputs: path (required).

get_test_run_usersC

Read-onlyIdempotent

Get all users for a test run. Retrieve all users assigned to a specific test run using its unique identifier.

Inputs: path (required).

get_test_suiteC

Read-onlyIdempotent

Get a specific test suite. Retrieve a test suite (folder) using its identifier. DEPRECATED.

Inputs: path (required).

get_test_suites_collectionC

Read-onlyIdempotent

Get all test suites.. Get all test suites (root folders). This endpoint is deprecated. We recommend updating your code. DEPRECATED.

Inputs: query (required).

get_userC

Read-onlyIdempotent

Get a specific user. Retrieve a specific user using its unique identifier.

Inputs: path (required).

get_user_collectionA

Read-onlyIdempotent

Get all users. Retrieve all users.

Apply custom filters, sorting, and pagination to find the users you need. Include related data using the relations parameter.

Inputs: query.

get_versions_collectionC

Read-onlyIdempotent

Get all versions. Retrieve all versions across all applications.

Apply sorting and pagination to organize the results. Include related data using the relations parameter.

Inputs: query.

get_webhookC

Read-onlyIdempotent

Get a specific webhook. Retrieve a specific webhook using its unique identifier.

Inputs: path (required).

get_webhook_collectionC

Read-onlyIdempotent

Get all webhooks. Retrieve all webhooks. Apply pagination to find the webhooks you need.

Inputs: query (required).

get_webhook_event_collectionA

Read-onlyIdempotent

Get all webhook events. Retrieve all available webhook events.

Webhook events define the triggers that cause a webhook to send a notification, such as when a test case is created or a requirement is updated.

Inputs: no named parameters.

make_admin_userB

Destructive

Grant user admin privileges. Grant a user admin privileges using its unique identifier.

Admin users have full access to all settings and resources across the account.

Inputs: path (required).

mark_test_result_not_viewedC

Destructive

Mark a test result as not viewed. Mark a test result as not viewed using its unique identifier.

Inputs: path (required), query.

mark_test_result_viewedC

Destructive

Mark a test result as viewed. Mark a test result as viewed using its unique identifier.

Inputs: path (required), query.

move_test_caseC

Destructive

Move a test case to a folder. Move a test case to a different folder within the project using its unique identifier.

This allows you to reorganize your test cases into a logical folder structure for better organization and navigation.

Inputs: path (required), query.

move_test_runB

Destructive

Move a test run. Move a test run to a different milestone within the project using its unique identifier.

Moving a test run preserves all its test cases, test results, and configuration.

Inputs: body (required), path (required).

my_accountA

Read-onlyIdempotent

Get authenticated user. Retrieve the user account details for the currently authenticated user.

Inputs: no named parameters.

open_test_runB

Destructive

Open a test run. Open a previously closed test run using its unique identifier. Reopening a test run allows you to continue creating and updating test results.

Inputs: path (required).

post_applicationC

Destructive

Create an application. Create a new application.

Inputs: body (required).

post_batch_delete_applicationsB

Destructive

Delete multiple applications. Delete multiple applications in a single request. Deleted applications are moved to the trash and can be restored later if needed.

Inputs: body (required).

post_batch_delete_issuesC

Destructive

Delete multiple issues. Delete multiple issues in a single request. Deleted issues are moved to the trash and can be restored later if needed.

Inputs: body (required).

post_batch_delete_milestonesB

Destructive

Delete multiple milestones. Delete multiple milestones in a single request. Deleted milestones are moved to the trash and can be restored later if needed.

Inputs: body (required).

post_batch_delete_requirementsB

Destructive

Delete multiple requirements. Delete multiple requirements at once in a single request. Specify the requirement identifiers you want to delete, and all selected requirements will be moved to the trash. Deleted requirements can be restored later if needed.

Inputs: body (required).

post_batch_delete_risksA

Destructive

Delete multiple risks. Delete multiple risks at once in a single request. Specify the risk identifiers you want to delete, and all selected risks will be moved to the trash. Deleted risks can be restored later if needed.

Inputs: body (required).

post_batch_delete_teamsA

Destructive

Delete multiple teams. Delete multiple teams at once in a single request. Specify the team identifiers you want to delete, and all selected teams will be moved to the trash. Deleted teams can be restored later if needed.

Inputs: body (required).

post_batch_delete_test_casesA

Destructive

Delete multiple test cases. Delete multiple test cases at once in a single request. Specify the test case identifiers you want to delete, and all selected test cases will be moved to the trash. Deleted test cases can be restored later if needed.

Inputs: body (required).

post_batch_delete_test_runsA

Destructive

Delete multiple test runs. Delete multiple test runs at once in a single request. Specify the test run identifiers you want to delete, and all selected test runs will be moved to the trash. Deleted test runs can be restored later if needed.

Inputs: body (required).

post_batch_update_issuesB

Destructive

Update multiple issues. Update multiple issues in a single request. This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required).

post_batch_update_requirementsA

Destructive

Update multiple requirements. Update multiple requirements at once in a single request. Specify the requirement identifiers and the fields you want to update, and all selected requirements will receive the same field values. This endpoint supports partial updates.

Inputs: body (required).

post_batch_update_risksB

Destructive

Update multiple risks. Update multiple risks at once in a single request. Specify the risk identifiers and the fields you want to update, and all selected risks will receive the same field values. This endpoint supports partial updates.

Inputs: body (required).

post_batch_update_test_casesB

Destructive

Update multiple test cases. Update multiple test cases at once in a single request. Specify the test case identifiers and the fields you want to update, and all selected test cases will receive the same field values. This endpoint supports partial updates.

Inputs: body (required).

post_batch_update_test_runsB

Destructive

Update multiple test runs. Update multiple test runs at once in a single request. Specify the test run identifiers and the fields you want to update, and all selected test runs will receive the same field values. This endpoint supports partial updates.

Inputs: body (required).

post_folderC

Destructive

Create a folder. Create a new folder within a project to organize test cases.

Folders provide a hierarchical structure for managing large numbers of test cases, making them easier to navigate and maintain.

Inputs: body (required).

post_issueC

Destructive

Create an issue. Create a new issue within a project.

Inputs: body (required).

post_issue_attachmentC

Destructive

Upload an attachment for an issue. Upload an attachment for an issue using its unique identifier.

Inputs: body (required), path (required).

post_issue_commentC

Destructive

Post a comment on an issue. Post a comment on an issue using its unique identifier.

Inputs: body (required), path (required).

post_issue_taskC

Destructive

Create a task for an issue. Create a task for an issue using its unique identifier.

Inputs: body (required), path (required).

post_issue_test_resultsC

Destructive

Link test results to an issue. Link test results to an issue using its unique identifier.

Inputs: body (required), path (required).

post_milestoneC

Destructive

Create a milestone. Create a new milestone within a project.

Inputs: body (required).

post_projectD

Destructive

Create a project. Create a new project.

Inputs: body (required).

post_requirementC

Destructive

Create a requirement. Create a new requirement within a project.

Inputs: body (required).

post_riskC

Destructive

Create a risk. Create a new risk within a project.

Inputs: body (required).

post_teamD

Destructive

Create a team. Create a new team.

Inputs: body (required).

post_team_membersC

Destructive

Add members to a team. Add one or more users as members to a team.

Inputs: body (required), path (required).

post_test_caseC

Destructive

Create a test case. Create a new test case within a project.

Inputs: body (required).

post_test_case_attachmentC

Destructive

Upload an attachment for a test case. Upload a new attachment to a test case.

Attachments help document your test cases with supporting files such as screenshots, test data files, configuration examples, or reference documents.

Inputs: body (required), path (required).

post_test_case_commentC

Destructive

Post a comment on a test case. Post a comment on a test case using its unique identifier.

Inputs: body (required), path (required).

post_test_environmentC

Destructive

Create a environment. Create a new test environment.

Inputs: body (required).

post_test_resultC

Destructive

Create a test result. Create a new test result.

Inputs: body (required).

post_test_result_attachmentC

Destructive

Upload an attachment for a test result. Upload an attachment for a test result using its unique identifier.

Inputs: body (required), path (required).

post_test_result_commentC

Destructive

Post a comment on a test result. Post a comment on a test result using its unique identifier.

Inputs: body (required), path (required).

post_test_result_issuesC

Destructive

Link issues to a test result. Link issues to a test result using its unique identifier.

Inputs: body (required), path (required).

post_test_runC

Destructive

Create a test run. Create a new test run within a project.

Inputs: body (required).

post_userC

Destructive

Create a user. Create a new user account.

Inputs: body (required).

post_webhookD

Destructive

Create a webhook. Create a new webhook.

Inputs: body (required).

put_applicationC

Destructive

Update an application. Update an application using its unique identifier.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required), query.

put_folderB

Destructive

Update a folder. Update a test case folder using its unique identifier. You can modify the folder name, description, or parent folder relationship.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required).

put_issueB

Destructive

Update an issue. Update an issue using its unique identifier. You can modify the name, description, status, priority, category, resolution, and custom fields.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required), query.

put_issue_taskC

Destructive

Update a task. Update a task using its unique identifier.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required).

put_milestoneB

Destructive

Update a milestone. Update a milestone using its unique identifier.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required).

put_projectB

Destructive

Update a project. Update a project using its unique identifier. You can modify the name, description, and other project settings.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required).

put_requirementB

Destructive

Update a requirement. Update a requirement using its unique identifier. You can modify any field including the name, description, type, and custom fields.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required), query.

put_riskB

Destructive

Update a risk. Update a risk using its unique identifier. You can modify any field including the name, description, classification, and custom fields.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required), query.

put_teamB

Destructive

Update a team. Update a team using its unique identifier.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required), query.

put_test_caseB

Destructive

Update a test case. Update a test case using its unique identifier. You can modify any field including the name, description, steps, expected results, priority, and custom fields.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required), query.

put_test_environmentB

Destructive

Update an environment. Update a test environment using its unique identifier.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required).

put_test_resultC

Destructive

Update a test result. Update a test result using its unique identifier. You can modify the status, notes, and other fields.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required), query.

put_test_runB

Destructive

Update a test run. Update a test run using its unique identifier. You can modify any field including the name, environment, assigned test cases or users, and custom fields.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required).

put_userB

Destructive

Update a user. Update a user using its unique identifier.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required).

put_webhookB

Destructive

Update a webhook. Update a webhook using its unique identifier. You can modify the name, URL, and the events that trigger the webhook.

This endpoint supports partial updates, so you only need to include the fields you want to change.

Inputs: body (required), path (required).

remove_admin_userB

Destructive

Revoke user admin privileges. Revoke a user's admin privileges using its unique identifier.

The user will retain access to their assigned projects but will no longer have account-wide admin access.

Inputs: path (required).

restore_applicationB

Destructive

Restore an application. Restore a previously deleted application from the trash using its unique identifier.

Inputs: path (required).

restore_folderB

Destructive

Restore a folder. Restore a previously deleted test case folder from the trash using its unique identifier.

The folder will be fully recovered with all its properties, test cases, and subfolders intact.

Inputs: path (required).

restore_issueB

Destructive

Restore an issue. Restore a previously deleted issue from the trash using its unique identifier.

The issue will be fully recovered with all its properties and associations intact.

Inputs: path (required).

restore_milestoneB

Destructive

Restore a milestone. Restore a previously deleted milestone from the trash using its unique identifier.

The milestone will be fully recovered with all its properties and associations intact.

Inputs: path (required).

restore_requirementA

Destructive

Restore a requirement. Restore a previously deleted requirement from the trash using its unique identifier.

The requirement will be fully recovered with all its properties and associations intact.

Inputs: path (required).

restore_riskA

Destructive

Restore a risk. Restore a previously deleted risk from the trash using its unique identifier.

The risk will be fully recovered with all its properties and associations intact.

Inputs: path (required).

restore_teamA

Destructive

Restore a team. Restore a previously deleted team from the trash using its unique identifier.

The team will be fully recovered with all its properties and members intact.

Inputs: path (required).

restore_test_caseA

Destructive

Restore a test case. Restore a previously deleted test case from the trash using its unique identifier.

The test case will be fully recovered with all its properties, associations, and historical test results intact.

Inputs: path (required).

restore_test_runA

Destructive

Restore a test run. Restore a previously deleted test run from the trash using its unique identifier.

The test run will be fully recovered with all its test cases, test results, and configuration intact.

Inputs: path (required).

unarchive_projectB

Destructive

Unarchive a project. Unarchive a project using its unique identifier. The project will be restored to an active state and become visible in the project overview again.

Inputs: path (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.6/5.0

Scored 2026-09-13 11:15 across 173 tools

Disambiguation3/5

With 173 tools, many operations are near-identical across resource types (e.g., get_X_collection vs get_X, get_X_tags vs get_X_tags_collection), which can cause misselection without careful reading. Descriptions do distinguish them, but the sheer volume increases cognitive load and overlap risk.

Naming Consistency4/5

The dominant pattern is action_resource (get_application, post_issue, put_test_case, delete_webhook, restore_milestone) with batch and association variants, which is highly predictable. Minor deviations like 'my_account' (noun only) and mixed action verbs (open/close, archive/unarchive, mark_viewed) slightly break uniformity.

Tool Count1/5

173 tools is an extreme mismatch for a single MCP server, far exceeding practical bounds (typically 3-15) and likely to overwhelm an agent's selection process. The surface is excessively granular, with many near-duplicate operations across resources.

Completeness4/5

The server covers extensive CRUD lifecycles for core entities (applications, issues, projects, requirements, risks, teams, test cases, test runs, test results, users, webhooks, folders) including batch, restore, comments, attachments, and associations. Minor gaps exist for configuration entities like custom fields and test result states, which are read-only.

Maintenance

ActivityStale

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Backtest360A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
https://mcp.backtest360.com/mcp
MCP Server By TestMu AIB
com.lambdatest.mcp
Run, debug, and triage tests from your IDE using natural language, no dashboard switching, no manual data transfers. The TestMu AI (formerly LambdaTest) MCP Server is a single remote server exposing four tool suites: HyperExecute — analyze your project, generate YAML configs and test runner commands, then monitor jobs and sessions. Automation — pull a TestID's details plus command, network, and console logs into one chat for instant root-cause analysis. Includes mobile app upload. SmartUI — explain pixel, layout, DOM, and perceptual changes in a visual regression run, with context-aware React/HTML/CSS fixes. Accessibility — audit any public URL or a local React app against WCAG and get ready-to-apply remediation steps. Connects over https://mcp.lambdatest.com/mcp using OAuth 2.1 — no API keys in your config. One-click install in Cursor; works with Claude, GitHub Copilot, Cline, and any MCP client. Tests execute on the TestMu AI cloud: 3,000+ browsers and 10,000+ real devices.
Cloud Platforms Testing & QA Tools
881
https://mcp.lambdatest.com/mcp
mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
24
https://mcp.pentest-tools.com/mcp
Testiny Test ManagementA
io.testiny
Create and manage test cases, test runs and results in Testiny from your AI assistant.
Testing & QA Tools Project Management
152
https://app.testiny.io/api/v1/mcp-server

Related MCP Servers

TestRail MCP Server
Testing & QA Tools Project Management Developer Tools
bhayanak
A
license
Not graded
quality
D
maintenance
MCP server for TestRail that enables AI assistants to interact with TestRail's test management platform. It can query and manage projects, test cases, runs, results, plans, milestones, and more.
Updated 8 months ago (2026-03-20 17:03 UTC)
MIT
TestRail MCP Server
Testing & QA Tools Developer Tools
uarlouski
A
license
B
quality
A
maintenance
AI-native Model Context Protocol (MCP) server for TestRail. Lets Claude, Cursor, Windsurf, and other AI assistants browse projects, create and update test cases, kick off test runs, and record results through natural-language conversation — with strongly-typed tool schemas and per-project custom field validation that helps LLMs generate valid TestRail requests on the first try.
Updated 5 days ago (2026-11-08 10:29 UTC)
27
911 npm
45
Apache 2.0
Testing MCP
Testing & QA Tools Code Analysis
shalonjovan
A
license
Not graded
quality
D
maintenance
A universal AI-powered testing server built on the Model Context Protocol (MCP). Allows AI agents to inspect, execute, test, monitor, debug, and report on software projects.
Updated 4 months ago (2026-07-09 05:11 UTC)
3
GNU Lesser General Public v2.1 only
tcm-mcp
Testing & QA Tools Developer Tools
JoinFullStackDev
F
license
A
quality
B
maintenance
A stdio MCP server providing AI agents with a stable tool interface to read and write TCM test cases through REST, including search, CRUD operations, and a dry-run-to-commit safety flow.
Updated 2 months ago (2026-09-15 19:54 UTC)
5
-

TestMonitor MCP server

Local installation (optional)

Connect your AI agent

Recommended: launch with npx

Alternative: launch an installed copy with node

npx versus node

Try the connection

Tool arguments

Behavior and configuration

Development and validation

Available Tools

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

TestRail MCP Server

TestRail MCP Server

Testing MCP

tcm-mcp