About Tuskr MCP Server
Tuskr MCP Server is an MCP server published by BoomBidiBuyBuy in the Developer Tools category: implements MCP to talk the Tuskr.
The repository has 1 stars and 1 forks, with the last commit 5 days ago. Recent commit activity is the strongest signal that reported issues will get attention.
Install
git clone https://github.com/BoomBidiBuyBuy/tuskr-mcp-serverThis server has no ConduID identity, so agent calls to it are not receipted. Pin the version you install and review the source before granting it credentials.
Ask AI
Ask AI about Tuskr MCP Server
Powered by Claude · Grounded in docs
Security checks
Static checks derived from the repository 7 days ago. Heuristics on the source, not an audit.
- ✓README presentThe repository ships documentation.
- ✓License declaredUsable under a stated license.
- ✓Tests presentA test suite exists in the repository.
- ✓Dependencies pinnedA lockfile pins dependency versions.
- ✓No dynamic code executionSource scan found no eval, dynamic Function, or shell execution.
- !Scoped permissionsDoesn't declare a permission scope. Assume it can do anything its process can.
Releases
README
tuskr-mcp-server
Implements a Model Context Protocol (MCP) server for the Tuskr REST API
Built on the FastMCP Python SDK.
Supports access token authentication.
Tools
Every tool wraps a single Tuskr REST endpoint, relative to
https://api.tuskr.live/api/tenant/<tenant-id>/.
| Tool | Method | Endpoint | Purpose |
|---|---|---|---|
list_projects |
GET |
project |
Lists projects, filterable by name and by status (active / archived). |
list_test_cases |
GET |
test-case |
Lists a project's test cases, filterable by test suite, section, key, name, test case type and custom fields. Use it to discover the case keys a project actually contains before recording results. |
list_test_suites |
GET |
test-suite |
Lists a project's test suites, each with its embedded sections, filterable by name. Use it to find the suite and section IDs that list_test_cases filters on. |
list_test_runs |
GET |
test-run |
Lists a project's test runs, filterable by name, key, status and assignee. filter_incomplete=True walks every page and returns only runs below 100% done. |
add_test_case |
POST |
test-case |
Creates a test case in an existing suite and section. Custom-field keys and value shapes are tenant specific. The API has no delete endpoint for test cases, so try it on a sandbox project. |
create_test_run |
POST |
test-run |
Creates a test run containing all cases in the project or a named subset. |
copy_test_run |
POST |
test-run/copy |
Copies an existing run and its case selection within the same project. Results are not carried over; every case starts untested. |
add_test_run_results |
POST |
test-run-result/bulk |
Records one status against one or many cases in a run, optionally with up to two file attachments (see Attachments). Prefer a single call with a list of cases over repeated single calls. |
get_test_run_results |
GET |
test-run/<id>/results |
Fetches the cases in a run with their latest result, filterable by status. Pass status='FAILED' for a confirmation-test worklist. |
bulk_export_test_runs |
GET |
test-run/bulk-export |
Exports a project's test runs with their test cases and the latest result per case, in one call. Filterable by run IDs, status, completion status and assignee. Always narrow it with filter_ids or another filter when cases are included: a project's runs with all their cases run to tens of megabytes, so nested cases are trimmed by default (trim_response=False keeps them whole) and a response over the MCP size limit is replaced by an error naming the arguments that narrow it. filter_exclude_test_cases=True returns runs only. Run IDs are the UUIDs the API returns, not the R-numbered keys. |
get_test_run_timeline |
GET |
test-run/<id>/results, test-run/<id> |
Reports when testing in a run actually started and finished, derived from each case's resultHistory: first and last execution, span in minutes, distinct days with activity, an optional per-day breakdown and the cases never executed. Walks every results page, so it costs one call per 100 cases. Takes the run's ID, not its key. |
get_test_run_details |
GET |
test-run/<id>/details |
Fetches a run's metadata plus firstResultAt, lastResultAt and durationInMinutes. Takes the run's ID, not its key. The timestamps are null until a result is recorded, and Tuskr may leave them null for results recorded before it added the endpoint, so a null means unknown, not that the run has no results. |
set_test_run_lock |
POST |
test-run/set-lock |
Locks a run read-only, or unlocks it. One run per call. |
archive_test_runs |
POST |
test-run/archive |
Archives one or more runs by ID. The response is a bare boolean, so confirm the new state with list_test_runs(filter_status='archived'). Unarchiving is not exposed by the API and has to be done in the Tuskr UI. |
Result status keys such as PASSED and FAILED are configured per tenant, so use
the keys defined in your own account.
add_test_run_results matches a test run given by key or name across the whole
tenant, not within one project. When several projects have a run with the same key,
for example R-1, Tuskr rejects the call with Multiple test runs found matching: R-1 and records nothing. Pass the run's UUID instead; list_test_runs returns it
for a given project.
Tuskr rate-limits every plan at 10 requests/second. The bulk tools exist for that reason: batch where the endpoint allows it.
Attachments
add_test_run_results accepts an attachments list of local file paths, for
screenshots and logs. Tuskr allows two files of 5 MB each per call and attaches
every file to the result record of every test case in that call, so record cases
that need different evidence in separate calls. Both limits are checked before
the request is sent.
Attachments are off by default. The tool arguments are chosen by the model, so a
plain path would let a prompt injection upload any file the server can read.
Set TUSKR_ATTACHMENT_DIR to the one directory the server may read from. Relative
paths resolve against it, and anything that resolves outside it, including through
a symlink, is rejected. Because the server reads the files itself, this only works
when the server runs on the machine that holds them (stdio, or an HTTP instance
with the directory mounted).
The server also exposes one resource, resource://service_description, which
describes its purpose to the client.
Installation
Environment variables / .env file
Set up environment variables or configure the .env file using the .env.example template.
The following environment variables are supported:
TUSKR_TENANT_ID=<your tenant id>
TUSKR_ACCESS_TOKEN=<your access token>
(this doc desc https://tuskr.app/kb/latest/api)
and optionally
MCP_TRANSPORT=<transport type: http or stdio>
MCP_HOST=<host for HTTP transport>
MCP_PORT=<port for HTTP transport>
TUSKR_ATTACHMENT_DIR=<directory attachments may be read from>
Command Line Parameters
The MCP server supports the following command line parameters:
--transport: Transport type for the MCP server. Options:http(default) orstdio--host: Host address for HTTP transport (default:0.0.0.0)--port: Port number for HTTP transport (default:8000)
Note: The --host and --port parameters are only applicable when using the http transport.
Default Values
- Transport:
http(can be overridden withMCP_TRANSPORTenvironment variable) - Host:
0.0.0.0(can be overridden withMCP_HOSTenvironment variable) - Port:
8000(can be overridden withMCP_PORTenvironment variable)
Connect from client
HTTP Transport (Default)
Use the following template to connect the server via HTTP:
{
"mcpServers": {
"tuskr": {
"transport": "http",
"url": "http://<your-mcp-dns-or-ip>/mcp/",
"headers": {
"Authorization": "Bearer <your access token>",
"Tenant-ID": "<your-tuskr-tenant-id>"
}
}
}
}
The Authorization is mandatory.
The Tenant-ID is not required and can be set on the server side using the TUSKR_TENANT_ID env variable. It's convenient in case you have a single MCP Server for your organization.
Migrating from TUSKR_ACCOUNT_ID
Earlier versions of this server used the env var TUSKR_ACCOUNT_ID and the HTTP header
Account-ID. These continue to work, but emit a deprecation warning. Tuskr's own
documentation and UI consistently use the term "Tenant ID" (it is part of the REST URL
path: /api/tenant/<tenant-id>/), so the preferred names are now TUSKR_TENANT_ID and
the Tenant-ID HTTP header. Both names will be supported until a future major version
removes the legacy names.
To migrate an existing config, replace TUSKR_ACCOUNT_ID with TUSKR_TENANT_ID; no
other changes are required.
stdio Transport (for local development)
For local development and integration with tools like uvx, use the stdio transport:
{
"mcpServers": {
"tuskr": {
"transport": "stdio",
"command": "uvx",
"args": ["tuskr-mcp-server", "--transport", "stdio"]
}
}
}
or use uv with source code:
{
"mcpServers": {
"tuskr": {
"transport": "stdio",
"command": "uv",
"args": [
"--directory",
"/path/to/your/tuskr-mcp-server",
"run",
"src/main.py",
"--transport",
"stdio"
]
}
}
}
Integrate with Claude
Worked examples for Claude Code and the Claude desktop app. Both name the server
tuskr, so its tools appear as list_projects, list_test_runs and so on.
Claude Code
Run the server locally over stdio, with credentials passed as environment variables:
claude mcp add --transport stdio tuskr \
--env TUSKR_TENANT_ID=<your tenant id> \
--env TUSKR_ACCESS_TOKEN=<your access token> \
-- uvx tuskr-mcp-server --transport stdio
Everything after -- is the command Claude Code runs to start the server, kept
separate from Claude Code's own flags.
Or connect to a shared instance over HTTP:
claude mcp add --transport http tuskr https://<your-mcp-dns-or-ip>/mcp/ \
--header "Authorization: Bearer <your access token>" \
--header "Tenant-ID: <your-tuskr-tenant-id>"
Drop the Tenant-ID header if the instance already sets TUSKR_TENANT_ID
server-side.
claude mcp add stores the configuration without validating credentials, so a
wrong token is only reported when the server is first contacted. Run /mcp
inside a session and check that tuskr shows as connected.
Add --scope project to write the entry to the repository's .mcp.json and
share it with the team. Keep credentials out of a shared file: reference them as
--env TUSKR_ACCESS_TOKEN=${TUSKR_ACCESS_TOKEN} and let each developer supply
the value from their own environment.
Claude desktop app
Edit claude_desktop_config.json (Settings, Developer, Edit Config):
- macOS:
~/Library/Application Support/Claude/claude_desktop_config.json - Windows:
%APPDATA%\Claude\claude_desktop_config.json
For a local stdio server:
{
"mcpServers": {
"tuskr": {
"command": "uvx",
"args": ["tuskr-mcp-server", "--transport", "stdio"],
"env": {
"TUSKR_TENANT_ID": "<your tenant id>",
"TUSKR_ACCESS_TOKEN": "<your access token>"
}
}
}
}
command has to resolve on the app's own PATH, which is not the same as your
shell's. If the server fails to start, use the absolute path to uvx.
For a shared HTTP instance:
{
"mcpServers": {
"tuskr": {
"type": "http",
"url": "https://<your-mcp-dns-or-ip>/mcp/",
"headers": {
"Authorization": "Bearer <your access token>",
"Tenant-ID": "<your-tuskr-tenant-id>"
}
}
}
}
The type key is required on any entry that uses url; without it the entry is
read as a stdio server and skipped. Restart the app after editing the file.
Check it works
Ask Claude to list your Tuskr projects. It should call list_projects and come
back with project names and IDs. A useful follow-up, since it exercises a filter
and a second tool: ask which test runs in a given project are not yet finished,
which resolves to list_test_runs with filter_incomplete.
A request such as "mark TC-14 and TC-15 as passed in run TR-3" resolves to a
single add_test_run_results call. Bear in mind that several of these tools
write to Tuskr, so point the server at a sandbox project while you are still
exploring.
Development
Setup
- Clone repo
- Install development dependencies:
uv sync --dev - Create
.envfrom.env.example
Running MCP service
HTTP Transport (Default)
uv run --env-file .env src/main.py
stdio Transport (for local development)
uv run --env-file .env src/main.py --transport stdio
Custom Host/Port
uv run --env-file .env src/main.py --host 127.0.0.1 --port 9000
Running tests
The project uses pytest for testing. The following command will run all tests
uv run pytest -vsx
Running linters
The project uses the ruff tool as a linter.
The following command allows to run linter
uv run ruff check
and this command allow to fix formatting
uv run ruff format
Dockerization
The following command allows to build a docker image
docker build -t tuskr-mcp .
and then you can run it using the
docker run -it tuskr-mcp
README fetched from the repository 7 days ago. The original is authoritative.