Testkube MCP
The official Testkube MCP server: an agent runs test workflows in Kubernetes and reads run logs, artifacts and metrics.
- 1,679 ★ on the repository
- Last commit
Broad access
Why this level
- Creates, runs and aborts test workflows in Kubernetes, which means executing code in your cluster.
- The access token opens the whole Testkube environment.
Install
- Works in
Manual install
testkube mcp serveLocal mode, requires `testkube login` or an API key.
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Creates, runs and aborts test workflows in Kubernetes, which means executing code in your cluster.
- The access token opens the whole Testkube environment.
This is third-party code. Review the repository files before installing.
What it does
Testkube is an open platform for running and tracking tests in Kubernetes: API, E2E, load and others. Its MCP server gives an agent up to forty-three tools in groups. Workflows: list, read, create from YAML or JSON, update and run (`run_workflow`). Runs: logs (`fetch_execution_logs`), details, metrics and resource usage history, waiting for completion, abort. Then come artifacts, workflow templates, schemas, labels, resource groups, agents and dashboard links. The server works in two modes. The local one starts with `testkube mcp serve` over stdio or Streamable HTTP, signing in through `testkube login` or an API key. The control plane mode exposes a built-in `/organizations/{orgId}/environments/{envId}/mcp` endpoint. There is also a Docker image configured with `TK_ACCESS_TOKEN`, `TK_ORG_ID` and `TK_ENV_ID`.
Who it is for. QA and DevOps teams on Kubernetes that run tests through Testkube and want to dig into failed runs together with an agent.
Good fit when
- A nightly run failed and the agent reads logs, metrics and artifacts to find the cause.
- A workflow has to be created from a test description and run right away.
- After a release the agent waits for several runs to finish and summarizes the results.
- A team uses JSONPath queries to find workflows with outdated configuration.
Not a fit when
- Tests run outside Testkube, for example directly in CI.
- The cluster is production and token rights are not limited to the needed environments.
- The agent must not abort running executions without approval.
Example request
Show the latest failed runs of the `checkout-e2e` workflow, go through the logs and suggest what to fix.MCP
- Transport
- stdio, http
- Authentication
- API key
Environment variables
TK_ACCESS_TOKENrequired, secret- Testkube access token.
TK_ORG_IDrequired- Testkube organization ID.
TK_ENV_IDrequired- Testkube environment ID.
Limitations
It needs a Testkube account, an organization and environment ID and an access token. Tools that create, run and abort workflows change cluster state, so give the token only the rights it needs. Two query tools are registered conditionally, and the insight tools need a control plane that serves `/insights/*` endpoints. Over HTTP it needs a separate inbound token of at least 32 bytes and HTTPS.
How to disable. Remove the MCP connection from the client and stop the container or the `testkube mcp serve` process. Revoke the access token in Testkube settings.
FAQ
How do I start the local MCP server?
Sign in with `testkube login` or `testkube set context` with an API key and run `testkube mcp serve`. The default transport is stdio, and for HTTP add `--transport=shttp`.
How do I use the Docker image?
Pass `TK_ACCESS_TOKEN`, `TK_ORG_ID` and `TK_ENV_ID` through `-e` and run the image interactively with `-i`. For HTTP add `--transport=shttp` and `TK_MCP_SHTTP_AUTH_TOKEN`.
Which tools help analyse runs?
`fetch_execution_logs` reads logs, `get_execution_info` returns details, `get_workflow_execution_metrics` returns metrics, `list_artifacts` and `read_artifact` show artifacts, and `wait_for_executions` waits for completion.
Is a separate token needed in HTTP mode?
Yes, `TK_MCP_SHTTP_AUTH_TOKEN` is the inbound client token and must be stored separately from `TK_ACCESS_TOKEN`. Remote clients connect over HTTPS only.
How does control plane mode differ from local mode?
The local server runs on your machine with `testkube mcp serve` and calls the Testkube API. In control plane mode the endpoint is built into the API and access is checked with an environment token.
Discussion
No questions or reviews yet.
Related
MCP serversKeploy MCP generates API tests from an OpenAPI spec, runs them and lists uncovered endpoints.
kogiQA MCP gives an agent a browser that finds page elements without selectors, for debugging web apps and writing e2e tests
An MCP server from the AWS load testing solution: an agent reads scenarios and runs and starts JMeter, K6 and Locust tests
The official MCP server debugger: web UI, automation CLI and terminal UI in one package
BrowserStack MCP Server: testing on real devices
BrowserStack MCP Server
The official BrowserStack MCP server: real devices, automated tests and test cases driven by an agent from your editor
Official Qase MCP server with 42 tools: cases, runs, defects, CI reports and search in the QQL query language
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| Testkube MCP (this card) | yes | API key | 1,679 | |
| Vibetest Use | no | API key | 835 | launches browser agents to check a site; Testkube MCP manages workflows of any tests in your cluster |
| TestDriver | yes | API key | 356 | an agent runs UI tests on cloud machines through computer vision; Testkube MCP orchestrates tests inside Kubernetes |
README in short
The `pkg/mcp` package is built on the mcp-go library, with tools defined as small interfaces and separate clients for the CLI and for the control plane. The documentation describes tool categories and safe HTTP operation.