Skip to main content
Glama

list_testcase

Retrieve test cases with comprehensive filters for run, status, tags, environment, and branch. View results from specific or multiple runs with pagination and sorting.

Instructions

List test cases with comprehensive filtering options. Provide a run scope: by_testrun_id or counter for specific runs, OR a cross-run filter (by_branch, by_time_interval, by_author, by_commit, by_environment, by_pages) which resolves the matching runs internally — you do NOT need to call list_testruns first. Without a run scope the tool returns an empty result with a warning explaining what to provide. Combine per-case filters (status, tags, runtime, artifacts, attempt number) with any run scope. page/limit paginate WITHIN the resolved run(s); limit is snapped to the nearest of 10, 25, 50, 100 (data-handler's allowed page sizes).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-indexed page number for pagination within the resolved run(s) (default: 1). Requires a run scope (by_testrun_id, counter, or a cross-run filter). To page across runs, use by_pages.
sortNoCase list sort order.
limitNoTest cases per page within the resolved run(s). Snapped to the nearest of 10, 25, 50, 100 (data-handler's allowed page sizes) — other values are adjusted, not rejected. Requires a run scope (by_testrun_id, counter, or a cross-run filter); it does not resolve runs on its own.
by_tagNoFilter by tag(s). Single tag or comma-separated. Example: 'smoke' or 'smoke,regression'. (ID/Counter is required while using this parameter)
searchNoSearch test title or title path.
counterNoTest run counter number. Alternative to by_testrun_id. Not required when using a cross-run filter (by_branch, by_commit, by_author, by_environment, by_time_interval, by_pages). Example: 43.
by_pagesNoList test cases by page number. Does not require testrun_id or counter. Returns test cases from all test runs on the specified page.
by_shardNo1-based shard index — scope results to a single shard of a sharded run.
by_authorNoFilter by commit author name (case-insensitive, partial match). Does not require testrun_id or counter. First lists test runs by the specified author, then returns test cases from those test runs.
by_branchNoFilter by git branch name. Does not require testrun_id or counter. First lists test runs on the specified branch, then returns test cases from those test runs. Example: 'main', 'develop'.
by_commitNoFilter by git commit hash (full or partial). Does not require testrun_id or counter. First lists test runs with the specified commit, then returns test cases from those test runs.
by_statusNoFilter by status: 'passed', 'failed', 'flaky', 'skipped', 'interrupted', 'incomplete', or 'running'. (ID/Counter is required while using this parameter)
projectIdYesProject ID (Required). The TestDino project identifier.
by_artifactsNoFilter test cases that have artifacts available (screenshots, videos, traces). Set to true to list only test cases with artifacts. (ID/Counter is required while using this parameter)
by_testrun_idNoTest run ID(s). Single ID or comma-separated for multiple runs (max 20). Example: 'test_run_123' or 'run1,run2,run3'. Not required when using a cross-run filter (by_branch, by_commit, by_author, by_environment, by_time_interval, by_pages).
by_environmentNoFilter by environment. Does not require testrun_id or counter. First lists test runs in the specified environment, then returns test cases from those test runs. Example: 'production', 'staging', 'development'.
by_testsuite_idNoFilter by suite ID.
by_time_intervalNoFilter by time interval. Does not require testrun_id or counter. First lists test runs in the specified time period, then returns test cases from those test runs. Supports: '1d' (last day), '3d' (last 3 days), 'weekly' (last 7 days), 'monthly' (last 30 days), or '2024-01-01,2024-01-31' (date range).
by_total_runtimeNoPer-test duration filter. Numbers are SECONDS by default; suffix with `ms` for milliseconds or `s` for seconds. Examples: '>10', '<1000ms', '>5s'. (ID/Counter or a run scope is required while using this parameter)
by_attempt_numberNoExact retry count filter. 0 = initial/no-retry (attempt_count=1), 1 = one retry (attempt_count=2). (ID/Counter is required while using this parameter)
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels: it reveals that missing run scope returns an empty result with a warning, limit values are snapped to allowed page sizes rather than rejected, cross-run filters resolve runs internally, and page/limit paginate within resolved runs. This level of detail is essential for an agent to predict behavior accurately.

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 a single, dense paragraph but is well-structured: it opens with the core purpose, then explains run scoping requirements, cross-run filters, per-case filters, and pagination behavior. Every sentence adds essential information for a 20-parameter tool, and there is no fluff. It is appropriately sized for the complexity.

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?

Given 20 parameters, no output schema, and no annotations, the description adequately covers the run-scope requirement, the empty-result warning, pagination snapping, filter combinability, and cross-run resolution behavior. It provides enough context for an agent to determine the correct invocation and expected behavior, including error cases, without needing external documentation.

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

Parameters4/5

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

Schema coverage is 100%, so individual parameters are already well-documented. The description adds value by providing a mental model: the distinction between run scopes (by_testrun_id/counter) and cross-run filters (by_branch, etc.), and the statement that per-case filters can be combined with any run scope. This goes beyond the schema's itemized descriptions, though it duplicates some schema content like limit snapping.

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 clearly states the tool's purpose with a specific verb and resource: 'List test cases with comprehensive filtering options.' It immediately distinguishes itself from sibling list_testruns by explaining that cross-run filters resolve runs internally, so users don't need to call list_testruns first. This is a clear, specific purpose that differentiates it from similar list tools.

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

Usage Guidelines5/5

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

Provides explicit usage guidance: 'Provide a run scope: by_testrun_id or counter for specific runs, OR a cross-run filter...' and even states 'you do NOT need to call list_testruns first,' directly addressing an alternative tool. It also warns about the empty-result case without a run scope and explains pagination semantics. These are clear when-to-use and when-not-to-use instructions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/testdino-hq/testdino-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server