Skip to main content
Glama
Sign In
BoomBidiBuyBuy

tuskr-mcp-server

by BoomBidiBuyBuy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

List Test Cases

list_test_cases

Retrieves a project's test cases with filters so you can discover test case keys before recording results with add_test_run_results.

Instructions

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

Use this to discover the test case keys a project actually contains before recording results against them with add_test_run_results.

Input Schema

NameRequiredDescriptionDefault
pageNocontrols number of records in output, every page contains 100 records. Default is 1.
filter_keyNoto filter test cases with key containing the specified value
filter_nameNoto filter test cases with name containing the specified value
filter_projectYesspecifies the project ID to filter the test cases associated with a particular project
filter_test_suiteNoID of the test suite to filter the test cases by. Only the ID works: a suite's key or name returns zero rows, not an error. Find suite IDs with list_test_suites.
filter_custom_fieldsNomaps a custom field's key to the value to filter on, e.g. {'priority_band': '<option-id>'}. The field key is whatever the tenant named it, so any project's own field set can be filtered here. Only fields applicable to test cases can be filtered; a field scoped to test run results is not reachable through this endpoint. Verified live by field type: dropdown: pass the option's ID, not its displayed label. Read the ID off any case that already has the field set, where it is returned inline as customFields.<field>.id. checkbox: pass a bool or the lowercase string 'true'/'false'. A bool is normalised to the lowercase form Tuskr expects. text: matches on substring, not equality. steps: NOT filterable. Tuskr accepts the parameter and returns every case in the project unfiltered. Numbers and multi-select remain unverified. Tuskr ignores a filter it does not understand instead of rejecting it, so a filter that fails to narrow the results means the field type or value shape is unsupported, not that nothing matched.
filter_test_case_typeNoID of the test case type to filter by. Read the ID off the testCaseTypeId field of any case row. Only the ID form is verified; a type's displayed name is untested as a filter value. Verified live: a valid ID narrows the result set, and an unknown value returns zero rows rather than an error or the unfiltered set, so an empty result can mean a mistyped ID, not that no case has that type.
filter_test_suite_sectionNoID of the test suite section to filter the test cases by. Only the ID works: a section name returns zero rows. Find section IDs with list_test_suites.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A3.8/5.0
Behavior3/5

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

No annotations exist, so the description carries the burden. "Retrieves" implies a read-only operation, but the description says nothing about pagination behavior, result ordering, or what happens with unsupported filters — all of which live in the schema instead.

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?

Two sentences: the first front-loads what the tool does, the second front-loads when to use it. No filler or repetition.

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?

For an 8-parameter list tool with no output schema, the description plus the highly detailed schema is nearly sufficient. It stops short of describing the return shape or page-size limit, but the schema already carries that.

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% and the schema documents each filter's quirks in detail (suite IDs vs names, custom field types, empty-result semantics). The description itself only says "various filters," adding nothing beyond the structured data, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ("Retrieves list of test cases of a project") plus the filtering capability. It carves out a role relative to add_test_run_results, though it does not explicitly distinguish itself from list_test_suites or get_test_run_results, so it falls short of a full 5.

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?

Gives a concrete scenario ("discover the test case keys a project actually contains before recording results") and names the follow-up tool add_test_run_results. No explicit when-not or alternative-for-the-same-data guidance, so not a 5.

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