How do I use tuskr-mcp-server?

1. Click on "Install 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., "@tuskr-mcp-server List all test cases in the 'Login' 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.

tuskr-mcp-server

by BoomBidiBuyBuy

Overview Schema Related Servers Score Discussions

Python

Remote

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.

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>

Related MCP server: MCP DevOps Test Server

Command Line Parameters

The MCP server supports the following command line parameters:

--transport: Transport type for the MCP server. Options: http (default) or stdio
--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 with MCP_TRANSPORT environment variable)
Host: 0.0.0.0 (can be overridden with MCP_HOST environment variable)
Port: 8000 (can be overridden with MCP_PORT environment 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"
      ]
    }
  }
}

Development

Setup

Clone repo
Install development dependencies: uv sync --dev
Create .env from .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

Available Tools

3 tools

create_test_runA

Creates a new test run in a project.

Args: name: a new test run name project: name or project ID where to create a test run test_case_inclusion_type: One of 'ALL' or 'SPECIFIC'. If you specify 'ALL', all test cases in the project will be included in the test run. If you specify 'SPECIFIC', then you will have to indicate the test cases to include as explained below. test_cases: list of IDs, keys or names. Required if you have set test_case_inclusion_type to 'SPECIFIC'. description: description of a test run deadline: YYYY-MM-DD date assigned_to: ID, name, or email of the user. If specified, the test run will be assigned to this user

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`project`	Yes
`deadline`	No
`test_cases`	No
`assigned_to`	No
`description`	No
`test_case_inclusion_type`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description is the sole source for behavioral traits. It describes the parameters and their meanings but does not disclose side effects, permissions, error conditions, or idempotency. The 'creates' verb implies writing, but no further behavioral context is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description starts with a clear purpose sentence, followed by an organized list of parameter explanations. While concise, it could be slightly more compact by integrating some parameter details. No wasted words, but the structure is clear and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all parameters adequately but lacks information about the return value of the created test run, error handling, permissions, or any side effects. Given the tool has 7 parameters and no output schema, some additional context would be beneficial for full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides detailed explanations for all 7 parameters, including constraints like 'One of ALL or SPECIFIC' for test_case_inclusion_type, and format requirements for deadline (YYYY-MM-DD). This adds significant value since the schema only contains titles, with 0% description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Creates a new test run in a project,' specifying the verb (creates), resource (test run), and scope (in a project). This distinctly differentiates it from sibling tools list_projects and list_test_runs, which are for listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It implicitly implies use for creation, but lacks guidance on when not to use or any exclusions. The parameter explanations provide some context but not usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsA

Retrives list of projects based on various filter criteria.

Args: filter_name: to filter projects with name containing the specified value filter_status: to filter projects by their status. Two supported values 'active' or 'archived' page: controls number of records in output, every page contains 100 records. Default is 1.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`filter_name`	No
`filter_status`	No

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description discloses pagination (100 records per page) and filter behavior, but omits details like authentication, rate limits, or whether sorting is applied. It adequately covers the retrieval behavior but could be more comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: a one-line summary followed by clear bullet points for arguments. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains pagination and filtering well. It lacks return value details but is otherwise complete for a list tool with well-documented parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description fully compensates by explaining each parameter's purpose and accepted values (e.g., 'filter_status' supports 'active' or 'archived', page size is 100). This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a list of projects with filtering. The verb 'Retrives' (though misspelled) and resource 'projects' are specific, and it distinguishes from siblings that deal with test runs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates this tool is for listing projects with filters, but does not provide explicit guidance on when to use it versus alternatives like list_test_runs or create_test_run. It implies usage context but lacks exclusion cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_test_runsA

Retrieves list of test runs of a project with support for various filters.

Args: filter_project: specifies the project ID to filter the test runs associated with a particular project filter_name: to filter test runs with name containing the specified value filter_key: to filter test runs with key containing the specified value filter_status: to filter test runs by their status. Two supported values 'active' or 'archived' filter_assigned_to: id of the user to whom test runs are assigned filter_incomplete: if True, fetches all pages and returns only test runs that are not 100% complete, with a trimmed payload (id, key, name, percentDone, counts, assignee, deadline, status). When False (default), returns the raw paginated response from the Tuskr API. page: controls number of records in output, every page contains 100 records. Default is 1. Ignored when filter_incomplete is True.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`filter_key`	No
`filter_name`	No
`filter_status`	No
`filter_project`	Yes
`filter_incomplete`	No
`filter_assigned_to`	No

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains pagination (100 records per page), the special filter_incomplete behavior that fetches all pages and returns a trimmed payload, and that page is ignored when filter_incomplete is True. This covers key behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with an Args list and front-loaded purpose. While a bit lengthy, every sentence adds value, and it is clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description explains the return format for filter_incomplete but only vaguely mentions 'raw paginated response' for normal usage. More detail on the normal response structure would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaningful details for each parameter: e.g., filter_name filters 'containing' value, filter_incomplete fetches all pages and returns trimmed payload, page is ignored when filter_incomplete is True. This fully explains parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Retrieves list of test runs of a project with support for various filters,' specifying the verb and resource. It distinguishes from siblings like list_projects and create_test_run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing test runs with filters but does not explicitly mention when to use this tool versus alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.2Jul 29, 2026
- First observedcreate_test_run
- First observedlist_projects
- First observedlist_test_runs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: one for listing projects, one for listing test runs, and one for creating test runs. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores: list_projects, list_test_runs, create_test_run.

Tool Count3/5

With only 3 tools, the server feels under-scoped for a test management system. While each tool is justified, the count is borderline low.

Completeness2/5

Obvious gaps exist: no create_project, no update/delete for test runs, and no tool for viewing test cases. The surface covers only basic listing and creation.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Testiny Test ManagementOAuth
io.testiny
An MCP server that provides access to Testiny projects, test cases and test runs
Testing & QA Tools Project Management
2
mission-controlOAuth
io.github.dinof777
Read and write Mission Control state via MCP — projects, tasks, subtasks, templates, status updates.
Project Management Workplace & Productivity
2
OneOAuth
ai.withone
Search, document and execute authenticated API calls across 700+ apps via one MCP server
API Testing App Automation
110
Jentic Remote MCP Server A
io.github.jentic
Remote MCP for 1,500+ APIs. Vault-managed credentials; OAuth or API key. Search, load, and execute.
API Testing Search Developer Tools
43

Related MCP Servers

tuskr-mcp
Testing & QA Tools Developer Tools
Zapkid
A
license
B
quality
D
maintenance
MCP server for Tuskr test management that allows browsing, searching, reading, creating, and updating test cases, suites, sections, and test runs from any MCP host like Cursor.
Updated 3 months ago (2026-06-04 10:01 UTC)
17
MIT
MCP DevOps Test Server
Testing & QA Tools CI/CD & DevOps
mrchris2000
A
license
A
quality
D
maintenance
Enables test execution and management through MCP clients, allowing retrieval of projects, listing tests, executing tests with browser selection, and monitoring results.
Updated 6 months ago (2026-03-06 17:53 UTC)
6
14
MIT
testrail-mcp-server
Testing & QA Tools Project Management
gracexiaowork
A
license
Not graded
quality
D
maintenance
Enables TestRail test management through MCP tools, allowing users to manage projects, test cases, runs, and results via natural language.
Updated 10 months ago (2025-11-14 20:08 UTC)
36
MIT
mcp-kiwi-tcms
Testing & QA Tools
runitsolutions
A
license
Not graded
quality
C
maintenance
Enables interaction with Kiwi TCMS test management system through MCP, supporting read and write operations on test plans, cases, runs, and executions, with API key authentication.
Updated 17 days ago (2026-08-21 01:19 UTC)
1
AGPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BoomBidiBuyBuy/tuskr-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

tuskr-mcp-server

Installation

Environment variables / .env file

Command Line Parameters

Default Values

Connect from client

HTTP Transport (Default)

Migrating from TUSKR_ACCOUNT_ID

stdio Transport (for local development)

Development

Setup

Running MCP service

HTTP Transport (Default)

stdio Transport (for local development)

Custom Host/Port

Running tests

Running linters

Dockerization

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Environment variables / `.env` file