Skip to main content
Glama

list_testcase

List test cases with filters on status, browser, tags, error, or run ID. Also filter test runs by branch, author, or time interval to narrow results.

Instructions

List test cases with comprehensive filtering options. You can filter by test run (ID or counter), status, spec file, error category, browser, tags, runtime, artifacts, error messages, attempt number, branch, time interval, environment, author, or commit hash. When using test run filters (by_branch, by_commit, by_author, by_environment, by_time_interval, by_pages, page, limit, get_all), the tool first lists test runs matching those criteria, then returns test cases from those filtered test runs. Use this to find specific test cases across your test runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectIdYesProject ID (Required). The TestDino project identifier.
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 test run filters (by_branch, by_commit, by_author, by_environment, by_time_interval, by_pages, page, limit, get_all).
counterNoTest run counter number. Alternative to by_testrun_id. Not required when using test run filters (by_branch, by_commit, by_author, by_environment, by_time_interval, by_pages, page, limit, get_all). Example: 43.
by_statusNoFilter by status: 'passed', 'failed', 'skipped', or 'flaky'.(ID/Counter is required while using this parameter)
by_spec_file_nameNoFilter by spec file name. Example: 'login.spec.js' or 'user-profile.spec.ts'. (ID/Counter is required while using this parameter)
by_error_categoryNoFilter by error category. Example: 'timeout_issues', 'element_not_found', 'assertion_failures', 'network_issues'. (ID/Counter is required while using this parameter)
by_browser_nameNoFilter by browser name. Example: 'chromium', 'firefox', 'webkit'. (ID/Counter is required while using this parameter)
by_tagNoFilter by tag(s). Single tag or comma-separated. Example: 'smoke' or 'smoke,regression'. (ID/Counter is required while using this parameter)
by_total_runtimeNoFilter by total runtime. Use '<60' for less than 60 seconds, '>100' for more than 100 seconds. Example: '<60', '>100', '<30'. (ID/Counter is required while using this parameter)
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_error_messageNoFilter by error message (partial match, case-insensitive). Example: 'Test timeout of 60000ms exceeded'. (ID/Counter is required while using this parameter)
by_attempt_numberNoFilter by attempt number. Example: 1 for first attempt, 2 for second attempt. (ID/Counter is required while using this parameter)
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_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_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).
limitNoNumber of results per page (default: 1000, max: 1000). Does not require testrun_id or counter. When used alone, first lists test runs, then returns test cases from those test runs.
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_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_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.
pageNoPage number for pagination (default: 1). Does not require testrun_id or counter. When used alone, first lists test runs on the specified page, then returns test cases from those test runs.
get_allNoGet all results up to 1000 (default: false). Does not require testrun_id or counter. When used alone, first lists all test runs, then returns test cases from those test runs.

Implementation Reference

  • The main handler function for list_testcase tool. Builds query params from args, makes API request to the list-testcase endpoint, and returns the JSON response.
    export async function handleListTestCases(args?: ListTestCasesArgs) {
      // Read PAT from environment variable (set in mcp.json) or from args
      const token = getApiKey(args);
    
      if (!token) {
        throw new Error(
          "Missing TESTDINO_PAT environment variable. " +
            "Please configure it in your .cursor/mcp.json file under the 'env' section."
        );
      }
    
      // Validate that at least one identifier is provided
      // Test run filters that don't require testrun_id or counter:
      // by_branch, by_commit, by_author, by_environment, by_time_interval, by_pages, page, limit, get_all
      const hasTestRunId = !!args?.by_testrun_id;
      const hasCounter = args?.counter !== undefined;
      const hasTestRunFilters = !!(
        args?.by_branch ||
        args?.by_commit ||
        args?.by_author ||
        args?.by_environment ||
        args?.by_time_interval ||
        args?.by_pages !== undefined ||
        args?.page !== undefined ||
        args?.limit !== undefined ||
        args?.get_all !== undefined
      );
    
      if (!hasTestRunId && !hasCounter && !hasTestRunFilters) {
        throw new Error(
          "At least one of the following must be provided: by_testrun_id, counter, or any test run filter (by_branch, by_commit, by_author, by_environment, by_time_interval, by_pages, page, limit, get_all)"
        );
      }
    
      try {
        const params: ListTestCasesParams = {
          projectId: String(args.projectId),
        };
    
        if (args?.by_testrun_id) {
          params.by_testrun_id = String(args.by_testrun_id);
        }
        if (args?.counter !== undefined) {
          params.counter = Number(args.counter);
        }
        if (args?.by_status) {
          params.by_status = String(args.by_status);
        }
        if (args?.by_spec_file_name) {
          params.by_spec_file_name = String(args.by_spec_file_name);
        }
        if (args?.by_error_category) {
          params.by_error_category = String(args.by_error_category);
        }
        if (args?.by_browser_name) {
          params.by_browser_name = String(args.by_browser_name);
        }
        if (args?.by_tag) {
          params.by_tag = String(args.by_tag);
        }
        if (args?.by_total_runtime) {
          params.by_total_runtime = String(args.by_total_runtime);
        }
        if (args?.by_artifacts !== undefined) {
          params.by_artifacts = String(args.by_artifacts);
        }
        if (args?.by_error_message) {
          params.by_error_message = String(args.by_error_message);
        }
        if (args?.by_attempt_number !== undefined) {
          params.by_attempt_number = Number(args.by_attempt_number);
        }
        if (args?.by_pages !== undefined) {
          params.by_pages = Number(args.by_pages);
        }
        if (args?.by_branch) {
          params.by_branch = String(args.by_branch);
        }
        if (args?.by_time_interval) {
          params.by_time_interval = String(args.by_time_interval);
        }
        if (args?.limit !== undefined) {
          params.limit = Number(args.limit);
        }
        if (args?.by_environment) {
          params.by_environment = String(args.by_environment);
        }
        if (args?.by_author) {
          params.by_author = String(args.by_author);
        }
        if (args?.by_commit) {
          params.by_commit = String(args.by_commit);
        }
        if (args?.page !== undefined) {
          params.page = Number(args.page);
        }
        if (args?.get_all !== undefined) {
          params.get_all = String(args.get_all);
        }
    
        const listTestCasesUrl = endpoints.listTestCases(params);
    
        const response = await apiRequestJson<unknown>(listTestCasesUrl, {
          headers: {
            Authorization: `Bearer ${token}`,
          },
        });
    
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(response, null, 2),
            },
          ],
        };
      } catch (error) {
        const errorMessage = error instanceof Error ? error.message : String(error);
        throw new Error(`Failed to list test cases: ${errorMessage}`);
      }
    }
  • Tool definition object with name 'list_testcase', description, and full inputSchema defining all filter parameters (projectId, by_testrun_id, counter, by_status, by_spec_file_name, by_error_category, by_browser_name, by_tag, by_total_runtime, by_artifacts, by_error_message, by_attempt_number, by_pages, by_branch, by_time_interval, limit, by_environment, by_author, by_commit, page, get_all). Only projectId is required.
    }
    
    export const listTestCasesTool = {
  • Internal ListTestCasesParams interface used to construct the API query parameters.
    interface ListTestCasesParams {
      projectId: string;
      by_testrun_id?: string;
      counter?: number;
      by_status?: string;
      by_spec_file_name?: string;
      by_error_category?: string;
      by_browser_name?: string;
      by_tag?: string;
      by_total_runtime?: string;
      by_artifacts?: string;
      by_error_message?: string;
      by_attempt_number?: number;
      by_pages?: number;
      by_branch?: string;
      by_time_interval?: string;
      limit?: number;
      by_environment?: string;
      by_author?: string;
      by_commit?: string;
      page?: number;
      get_all?: string;
    }
  • ListTestCasesArgs interface defining the accepted input argument types for the handler.
    interface ListTestCasesArgs {
      projectId: string;
      by_testrun_id?: string;
      counter?: number;
      by_status?: "passed" | "failed" | "skipped" | "flaky";
      by_spec_file_name?: string;
      by_error_category?: string;
      by_browser_name?: string;
      by_tag?: string;
      by_total_runtime?: string;
      by_artifacts?: boolean;
      by_error_message?: string;
      by_attempt_number?: number;
      by_pages?: number;
      by_branch?: string;
      by_time_interval?: string;
      limit?: number;
      by_environment?: string;
      by_author?: string;
      by_commit?: string;
      page?: number;
      get_all?: boolean;
    }
  • src/index.ts:213-217 (registration)
    Registration of 'list_testcase' in the CallToolRequestSchema handler, routing the tool name to handleListTestCases.
    if (name === "list_testcase") {
      return await handleListTestCases(
        args as Parameters<typeof handleListTestCases>[0]
      );
    }
Behavior4/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 disclosure. It clearly explains the two behavioral modes: direct filtering by test run ID/counter, and the 'run-first' approach for other filters. It also notes pagination limits (default/max 1000) and the effect of get_all. This is sufficient behavioral transparency for a read-only list operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and then lists filters. While it is somewhat long, it is well-organized with each sentence serving a distinct purpose. The duplication of schema constraints like 'Not required when...' could be trimmed, but overall it is efficient given the parameter count.

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

Completeness3/5

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

The description thoroughly explains parameters and behavioral nuances, but it does not mention the output format or what fields are returned for each test case. Given the lack of an output schema, this is a gap. Additionally, the required projectId is implicit from the schema but not highlighted in the description.

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 baseline is 3. The description adds significant value by clarifying the relationship between parameters (e.g., which filters require ID/counter and which trigger run-first behavior). It also groups filters by mode, aiding the agent in understanding possible combinations.

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 starts with 'List test cases with comprehensive filtering options,' clearly stating the verb and resource. It distinguishes from sibling tools like list_run_test_cases and list_testruns by explaining the two modes of operation (direct by test run ID or via test run filters that first list runs). This makes the tool's purpose unambiguous.

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?

The description explains when to use filter sets that require a test run ID vs those that do not, and concludes with 'Use this to find specific test cases across your test runs.' However, it does not explicitly mention when to use alternative siblings like list_run_test_cases for a specific run, leaving room for improvement in guidance.

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