Skip to main content
Glama
TCSoftInc

TestCollab MCP Server

by TCSoftInc

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TC_API_URLNoTestCollab API base URL. Use https://api-eu.testcollab.io for EU region.https://api.testcollab.io
TC_API_TOKENYesAPI token from TestCollab user profile
TC_DEFAULT_PROJECTNoDefault 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

CapabilityDetails
tools
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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:

  • id, title, description, steps, priority (0=Low, 1=Normal, 2=High)

  • suite (ID or title), created_by, reviewer, poster (user IDs)

  • created_at, updated_at, last_run_on (dates)

  • tags, requirements (arrays of IDs or names)

  • under_review, is_automated (0 or 1)

  • run_count, avg_execution_time, failure_rate

Filter types:

  • text: equals, notEqual, contains, notContains, startsWith, endsWith, isBlank

  • number: equals, notEqual, greaterThan, greaterThanOrEqual, lessThan, lessThanOrEqual, inRange

  • date: equals, notEqual, greaterThan, lessThan, inRange

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:

  • Included test cases count

  • Test plan configurations

  • Test plan runs

  • Current execution progress status

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:

  • title_contains

  • status: 0/1/2/3 or draft/ready/finished/finished_with_failures

  • priority: 0/1/2 or low/normal/high

  • archived: true/false

  • created_by: creator user ID

  • test_plan_folder: folder ID or folder title

  • release: release ID or release title

  • created_at_from/to, updated_at_from/to, start_date_from/to, end_date_from/to, last_run_from/to

  • filter: raw filter object for advanced keys (merged with explicit 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:

  • Ask follow-up questions for missing required information.

  • Do not infer or auto-generate required values like project_id.

Execution flow:

  1. POST /testplans

  2. POST /testplantestcases/bulkAdd (optional)

  3. POST /testplanconfigurations (optional)

  4. POST /testplans/assign (optional)

Optional:

  • project_id

  • title (defaults to "Test Plan DD Month YYYY HH:mm:ss" if omitted)

  • description

  • priority (0=Low, 1=Normal, 2=High)

  • test_plan_folder (ID or title)

  • release (ID or title)

  • start_date, end_date

  • custom_fields

  • test_cases (test_case_ids/selector/tag_id/tag_name/assignee; assignee supports user ID/"me"/name)

  • override_assignees (default false: keeps default case assignees, assigns only cases with none)

  • configurations

  • assignment (supports user IDs/"me"/names; if user says "assign to me", use "me")

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:

  • id (test plan ID)

All other fields are optional and only provided fields are updated.

Fields:

  • title

  • description (null to clear)

  • priority: 0/1/2 or low/normal/high

  • status: 0/1/2/3 or draft/ready/finished/finished_with_failures

  • test_plan_folder: ID/title/null

  • release: ID/title/null

  • start_date, end_date (null to clear)

  • archived

  • custom_fields (null/[] to clear)

  • assignee (single-user convenience)

  • assignment (advanced assignment payload)

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:

  • title: New title

  • suite: Move to different suite

  • description: New description (HTML)

  • priority: 0 (Low), 1 (Normal), 2 (High)

  • steps: Replaces all existing steps

  • steps_patch: Patch steps by step number (1-based) without replacing all steps

  • tags: Replaces all existing tags

  • requirements: Replaces all existing requirements

  • custom_fields: Update specific custom 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:

  • title: Filter suites by title substring.

  • title_contains: Filter suites by title substring (applied at API level).

  • parent: Filter suites by parent suite ID.

  • description: Filter suites by description substring.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 20 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues