Skip to main content
Glama
Sign In
BoomBidiBuyBuy

tuskr-mcp-server

by BoomBidiBuyBuy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Bulk Export Test Runs

bulk_export_test_runs

Exports multiple test runs with test cases and latest results in one call, using filters to narrow large project exports.

Instructions

Exports test runs of a project together with their test cases and the latest result of each case, in one call.

One call can return several runs, where get_test_run_results needs a call per run and per page. Always narrow the export with filter_ids or the other filters when test cases are included: a project's runs with all their cases run to tens of megabytes. A response over the MCP size limit is replaced by an error saying how large it was and how to narrow it.

Run fields and the response envelope ({count, rows, meta}) are passed through as the API sends them, keys in the API's own capitalisation.

Input Schema

NameRequiredDescriptionDefault
pageNopage number to fetch, 100 runs per page. Default is 1.
filter_idsNoa test run ID, or a list of them, to export only those runs. These are the run IDs (UUIDs) the API returns, not the R-numbered keys: a key matches no run.
filter_statusNoto filter test runs by their status. Two supported values 'active' or 'archived'
trim_responseNoif True (default), each nested test case is reduced to ID, Key, Name, Suite, Section, Assigned To, Result Status, Result Created At, Result Created By and Result Issue Ids. The full case also carries its steps, expected results, preconditions and the latest result's comments, about 2 KB per case. Set it to False when those are genuinely needed, and narrow the export to a few runs.
filter_projectYesID of the project whose test runs are exported
filter_assigned_toNoid of the user to whom test runs are assigned
filter_completion_statusNoto filter test runs by completion. Two supported values 'completed' or 'incomplete'
filter_exclude_test_casesNoif True, rows carry the runs without their test cases, a few hundred bytes each. The API has been seen to return every matching run on the first page in this mode. Default is False.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and discloses important behavior: large responses can exceed the MCP size limit and return an error with guidance, run fields are passed through with API capitalization, and trim_response/filter_exclude_test_cases affect payload size. It does not mention authentication or permission requirements, but it covers the main operational risks.

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 front-loaded with the core purpose, then supplies the key usage warning and output-shape note. Every sentence contributes useful context for a tool that can return very large responses.

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

Completeness5/5

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

For a complex export tool with no output schema and no annotations, the description explains the return envelope, payload size risk, trimming behavior, and API pass-through. Combined with the fully documented input schema, an agent has enough information to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all eight parameters in detail. The description reinforces narrowing with filter_ids and mentions response shaping, but it adds little parameter semantics beyond what the schema provides.

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 states a specific verb and resource: exporting test runs of a project together with their test cases and latest results in one call. It explicitly distinguishes itself from get_test_run_results by explaining that this tool avoids per-run and per-page calls.

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

Usage Guidelines4/5

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

It gives clear context for using this tool: exporting multiple runs with cases in one call, contrasted with get_test_run_results. It also warns to narrow the export with filter_ids or other filters when test cases are included, though it does not compare against every relevant sibling such as list_test_runs or get_test_run_details.

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

Deploy Server

Other Tools