Skip to main content
Glama
README.md
# TestMu AI Test Manager MCP

An MCP (Model Context Protocol) server for TestMu AI Test Manager, HyperExecute, and AI Insights,
built with the official [`@modelcontextprotocol/sdk`](https://github.com/modelcontextprotocol/sdk).

New to MCP, or setting this up for the first time? See [GETTING_STARTED.md](GETTING_STARTED.md)
for a step-by-step walkthrough, including how to connect Claude Desktop, Claude Code, or another
MCP client.

## What this server provides

Tools are organized by domain under `src/tools/`:

- **projects/**, **folders/** - TestMu AI Test Manager projects and test-case folders.
- **testCases/** - create/read/update test cases and their execution history.
- **testRuns/** - test runs and test-run folders, per-instance status/steps, bulk updates.
- **jira/** - link/unlink Jira issues, execution history by Jira ID.
- **environments/** - browser/OS/device environment lookup.
- **users/** - organization user lookup (for assignees).
- **attachments/** - file uploads for test steps/instances.
- **hyperexecute/** - HyperExecute job/task/scenario/session execution detail.
- **insights/** - AI-powered root cause analysis (RCA) and enriched test execution data.

## Prerequisites

- Node.js 22+
- npm
- A TestMu AI account with Test Manager access

## Installation

```bash
npm install
```

## Configuration

Copy the example environment file and fill in your TestMu AI credentials:

```bash
cp .env.example .env
```

| Variable         | Description                                                                    | Default                                   |
| ---------------- | ------------------------------------------------------------------------------- | -------------------------------------------- |
| `LT_USERNAME`    | Your LambdaTest username                                                        | —                                          |
| `LT_ACCESS_KEY`  | Your LambdaTest access key                                                      | —                                          |
| `LT_TM_BASE_URL` | Base URL for the LambdaTest Test Manager API                                    | `https://test-manager-api.lambdatest.com` |
| `LT_ORG_ID`      | Your LambdaTest account/org ID - optional, only needed by `tm.link_jiraIssue`   | —                                          |

## Build & Run

```bash
npm run build
npm start
```

## Development

Run directly from TypeScript source without a build step:

```bash
npm run dev
```

The server communicates over stdio, which is how MCP clients (e.g. Claude Desktop, Claude Code)
launch and talk to it.

## Project Structure

```rb
src/
  index.ts        # Executable entry point: wires client + server + stdio transport
  config.ts        # Environment variable loading and validation (dotenv + zod)
  server.ts         # Constructs the McpServer instance and registers tools
  client.ts          # Reusable HTTP client (get/post/patch/delete/postForm) for calling the TestMu AI API
  config/
    endpoints.ts      # Centralized registry of API endpoint paths - tools never hardcode a path
  utils/
    response.ts         # Shared defensive-parsing helpers for reading API responses
  tools/
    index.ts             # Central place where all tools are registered
    serverInfo.ts         # Orientation tool (tm.get_serverInfo)
    projects/, folders/, testCases/, jira/, testRuns/, environments/, users/,
    attachments/, hyperexecute/, insights/
                          # One domain per subfolder, one tool per file
```

## Extending with New Tools

See [CONTRIBUTING.md](CONTRIBUTING.md) for the full set of conventions this project's tools
follow (naming, file layout, input validation, response parsing, error handling, and rules for
what belongs in a tool's own description vs. internal dev notes) - read it before adding a new
tool, so the server keeps evolving consistently.

TDQS

A4.1/5.0

Scored across 39 tools

Disambiguation4/5

Tools are mostly distinct with clear resource+action targets. Some potential confusion between 'get_testCaseInstancesByTestRunId' and 'get_testCaseInstanceById' (collection vs single), but descriptions explicitly distinguish IDs and granularity. Overlap is minimal.

Naming Consistency4/5

Predominantly follows 'tm.<verb>_<noun>' pattern (e.g., create_testCases, get_testRunById). Inconsistency with 'bulkUpdate_testCaseInstances' using camelCase for 'bulkUpdate' while others use snake_case (e.g., 'add_testCasesToTestRun'). Overall convention is mostly consistent.

Tool Count3/5

39 tools is high for a single server, covering Test Manager, HyperExecute, and AI RCA. Many are read-only, but the count feels heavy. Tools are scoped to a specific domain, but some granularity could be merged (e.g., multiple get_hyperExecute* tools).

Completeness3/5

Covers main CRUD for test artifacts and execution lifecycle, plus Jira linking and RCA. Notable gaps: no deletion tools for projects/folders/test cases/runs, no listing of all projects (only by ID), and no direct update of existing test steps (only append). Core workflows are present but missing cleanup operations.

Maintenance

ActivityInactive
ResponsivenessNo issues