TestCollab MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TC_API_URL | No | TestCollab API base URL. Use https://api-eu.testcollab.io for EU region. | https://api.testcollab.io |
| TC_API_TOKEN | Yes | API token from TestCollab user profile | |
| TC_DEFAULT_PROJECT | No | Default project ID (makes project_id optional in every tool call) |
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": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_project_contextA | Get project context including project name, description, application type, suite tree, tags, test_case_custom_fields, test_plan_custom_fields, requirements, test plan folders, releases, and project users. Returns the metadata needed to resolve human-readable names (e.g. suite titles, tag names, folder titles, release titles, user names) to numeric IDs used by other tools. Also returns the project description and app_type (web_app, mobile_app, api, desktop_app, other) which should inform the style of test steps you generate. IMPORTANT: Call this tool at the start of every conversation before using any other TestCollab tool. This avoids errors from unresolved suite names, tag names, or custom field references. |
| list_test_casesA | List test cases from a TestCollab project with optional filtering, sorting, and pagination. Tip: Call get_project_context first to resolve suite/tag/custom field names to IDs. Note: list_test_cases may omit full step details; use get_test_case for a complete test case with steps. Filter fields include:
Filter types:
Example filter: { "priority": { "filterType": "number", "type": "greaterThanOrEqual", "filter": 1 }, "title": { "filterType": "text", "type": "contains", "filter": "login" } } |
| create_test_caseA | Create a new test case in TestCollab. Tip: Call get_project_context first to resolve suite/tag/custom field names to IDs. Required: title Optional: project_id, suite (ID or title), description, priority (0=Low, 1=Normal, 2=High), steps, tags, requirements, custom_fields, attachments Steps format: [{ "step": "action", "expected_result": "result" }] Custom fields format: [{ "id": 5, "name": "field_name", "value": "value", "valueLabel": "display" }] Example: { "title": "Verify login", "priority": 2, "steps": [ { "step": "Navigate to login", "expected_result": "Page loads" }, { "step": "Enter credentials", "expected_result": "Login succeeds" } ] } |
| get_test_planA | Fetch a single test plan with summary details:
Required: id or title Optional: project_id, include_configurations, include_runs, runs_limit, runs_offset, runs_sort Example: { "id": 812, "project_id": 16 } or { "title": "Release 3.0 Regression", "project_id": 16 } |
| list_test_plansA | List test plans from a TestCollab project with optional filtering, sorting, and pagination. Optional filters:
Example: { "project_id": 16, "title_contains": "Release", "status": "ready", "priority": "high", "created_by": 27, "sort_by": "updated_at", "sort_order": "desc", "limit": 25, "offset": 0 } |
| create_test_planA | Create a test plan in TestCollab using a single MCP tool call. Before calling this tool:
Execution flow:
Optional:
Example: { "project_id": 16, "title": "Release 2.9 Regression", "priority": 1, "test_cases": { "test_case_ids": [101, 102, 103] }, "configurations": [ [{ "field": "Browser", "value": "Chrome" }, { "field": "OS", "value": "Windows" }] ], "assignment": { "executor": "team", "assignment_criteria": "testCase", "assignment_method": "automatic", "user_ids": [27, 31] } } |
| update_test_planA | Update an existing test plan in TestCollab. Required:
All other fields are optional and only provided fields are updated. Fields:
Example: { "id": 812, "title": "Release 3.0 Regression", "status": "ready", "test_plan_folder": "Mobile", "assignee": "me" } |
| get_test_plan_casesA | Get all cases in a plan with steps, expected results, linked datasets (parameters and indexed rows), active status system names and per-configuration status. Provide run_id to get the token owner's assigned execution IDs, revision steps, saved datasets and datasetResults row/step coordinates. |
| report_test_case_resultA | Report one executed_test_case_id in a run, with a status system name (custom statuses supported), comment, additional time in milliseconds, step_results or dataset_results by dataset ID and zero-based row/step indexes. Up to 10 attachments across the call, including step and row files. file_path: stdio only, 10 MB/file. file_name plus content_base64: 1 MB decoded/file. The API token determines the executor. |
| report_resultsA | Report a structured list of results for the caller's assigned executions in a plan. Defaults to the latest run; configuration_id selects matrix executions. Optionally set plan custom_fields and mark omitted assigned executions skipped after all supplied results succeed. Records MCP provenance; no report-file parsing, auto-create or builds. |
| delete_test_planA | Delete a test plan from TestCollab. WARNING: This permanently deletes the test plan and related execution data. Required: id (test plan ID) Optional: project_id |
| update_test_caseA | Update an existing test case in TestCollab. Only provided fields will be updated. Tip: Call get_project_context first to resolve suite/tag/custom field names to IDs. Tip: If you need existing steps (e.g., to fill missing expected results), call get_test_case first and then use steps_patch. Required: id (test case ID) Optional fields:
Example: { "id": 1712, "title": "Updated login test", "priority": 2 } Example - patch a single step: { "id": 1714, "steps_patch": [ { "step_number": 1, "expected_result": "Appropriate expected result" } ] } |
| get_test_caseA | Fetch a single test case with full details, including steps and expected results. Required: id (test case ID) Optional: project_id, parse_reusable_steps (default: true) Example: { "id": 1835, "parse_reusable_steps": true } |
| create_suiteA | Create a new test suite in TestCollab. Tip: Call get_project_context first to see existing suites and resolve parent suite names to IDs. Required: title Optional: project_id, parent (suite ID or title), description Examples: Root suite: { "title": "Authentication" } Child suite: { "title": "Login", "parent": "Authentication" } With description: { "title": "API Tests", "description": "Tests for REST API endpoints" } |
| list_suitesA | List all test suites in a TestCollab project as a hierarchical tree. Returns the complete suite tree with parent-child relationships. Each suite node includes: id, title, parent_id, children (nested suites). Optional filter:
|
| get_suiteA | Get details of a specific test suite by ID. Returns the suite's title, description, parent_id, and other metadata. Required: id (suite ID) Optional: project_id |
| update_suiteA | Update an existing test suite in TestCollab. Only provided fields will be updated. Required: id (suite ID) Optional: project_id, title, description Note: To move a suite to a different parent, use the move_suite tool instead. Example: { "id": 42, "title": "Renamed Suite", "description": "Updated description" } |
| delete_suiteA | Delete a test suite from TestCollab. WARNING: This will delete the suite and may affect child suites and test cases. Use with caution. Required: id (suite ID) Optional: project_id |
| move_suiteA | Move a test suite to a different parent suite, or to root level. Tip: Call get_project_context first to see the current suite tree. Required: id (suite ID), parent (new parent ID, title, or null for root) Optional: project_id Examples: Move under a parent: { "id": 10, "parent": "Authentication" } Move to root level: { "id": 10, "parent": null } |
| reorder_suitesA | Set the sort order of sibling suites under a given parent. Tip: Call get_project_context or list_suites first to see current suite IDs and order. Required: parent (parent suite ID, title, or null for root), suite_ids (ordered array of suite IDs) Optional: project_id Example - reorder root-level suites: { "parent": null, "suite_ids": [5, 3, 8, 1] } Example - reorder children of "Authentication": { "parent": "Authentication", "suite_ids": [12, 10, 15] } |
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 20 tools
Most tools have clearly distinct resource/action targets, such as suite CRUD versus plan CRUD versus case read/write. The main ambiguity is between report_test_case_result and report_results, which both report execution results but at different granularity; descriptions help, though an agent could still hesitate between them.
Tool names consistently use snake_case with a verb_noun pattern: get_test_case, create_test_plan, update_suite, delete_suite, move_suite, reorder_suites, report_results, and get_project_context. Singular/plural variation follows the operation (get_suite vs list_suites), which is predictable and readable.
Twenty tools is somewhat heavy but reasonable for a test-management surface spanning cases, plans, suites, execution reporting, and project context. Each tool broadly earns its place, though the two reporting tools add some redundancy.
Suite lifecycle coverage is strong, and plans and cases have substantial create/read/update coverage. However, test cases lack a delete operation, and there is no clear tool for adding or removing cases from an existing plan after creation, which are notable lifecycle gaps.