tuskr-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TUSKR_API_TOKEN | Yes | API token | |
| TUSKR_TENANT_ID | Yes | Tenant ID |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List Tuskr projects from your local projects config. |
| list_sectionsC | List Tuskr project sections. |
| list_test_suitesB | List Tuskr test suites (main folders) for a project. |
| create_test_suiteC | Create a Tuskr test suite (main folder). |
| create_sectionC | Create a Tuskr section under a suite. |
| get_sections_treeC | List Tuskr project sections in nested tree form. |
| get_test_cases_by_sectionC | Get project test-cases by section; optional automated_filter: any, automated, manual, unset. |
| get_test_caseB | Get one detailed test-case by key (C-xxxx) or id. |
| create_test_case_minimalB | Create a Tuskr test-case with steps and Tuskr custom fields (automated, steps, optional pre_conditions/priority). |
| search_test_casesC | Search test-cases by key/title/steps text; optional automated_filter. |
| get_case_stepsC | Get normalized ordered steps for one case. |
| set_test_case_automatedB | Set the custom Tuskr field |
| set_test_cases_automated_bulkC | Set |
| validate_tuskr_setupC | Check env, project mapping, AutoGen test-case type, and custom fields for an app. |
| list_test_runsC | List test runs for a project (read-only). |
| get_test_runA | Get one test run by id; set include_results=true for paginated run results (read-only). |
| health_checkA | Validate Tuskr env/auth and API connectivity. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
All tools target distinct resources or operations (sections, test cases, suites, runs, projects) with clear boundaries. Even similar tools like set_test_case_automated and set_test_cases_automated_bulk are differentiated by single vs. bulk operation. No two tools are easily confused.
Naming mostly follows verb_noun snake_case (create_section, list_projects). However, 'health_check' and 'validate_tuskr_setup' deviate slightly (health_check is noun_verb, validate_tuskr_setup is verb_noun but longer). Overall pattern is consistent enough for an agent to predict tool names.
With 17 tools, the server is slightly above the typical 3-15 range but still appropriate for a test management domain that covers projects, suites, sections, test cases, test runs, and setup validation. Each tool serves a clear purpose without bloat.
The tool set covers creation and reading for most resources but lacks update and delete operations everywhere except for a single automated field update on test cases. Missing general test case update, test suite update/delete, test run creation, and any deletion. This leaves notable gaps for full lifecycle management.