Skip to main content
Glama

list_test_cases

Read-onlyIdempotent

List test cases in a project with filtering by folder, status, priority, tags, or search, plus pagination and automation status.

Instructions

List test cases in a project with filtering and pagination. Can filter by folder, status, priority, tags, or a search query. The cases come back in an array called cases, the available status and priority values under meta, and the row count under pagination.total; there is no top-level total. Every row also carries createdAt and updatedAt, and updatedAt tracks edits to the case DEFINITION only: recording a manual result, or an automated test running against the case, does not move it, so updatedAt equal to createdAt means never edited rather than never used. There is no lastExecutedAt on a row - for when a case was last actually run, use get_case_execution_history for manual results or get_test_case with includeRecentExecutions for automated ones. Every case row also carries hasLinkedAutotests and linkedAutotestCount, which is the cheapest way to answer whether a case is automated - they count links made with link_autotest_to_case, the same narrow definition the automationStatus filter uses and the same one behind get_coverage_gaps summary and automationRate. Only the unlinkedAutotests section of that tool additionally treats a [TC-N] title marker as coverage. meta.availablePriorities can contain the entry custom, which is a marker rather than a priority a case can hold. Each case includes a shareUrl for sharing in Slack, Jira and the like. To resolve a user-facing TC-30 (a displayId) to its internal numeric id, pass search: "TC-30", since search matches the case number and accepts the TC- prefix, then read the matching case id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoFilter by tags (any matching tag)
limitNoNumber of cases to return
offsetNoPagination offset
searchNoSearch in case title, description, or case number
statusNoFilter by case status (e.g., Draft, Ready, Approved). Values are project-specific.
folderIdNoFilter to cases held DIRECTLY by this folder UUID. It does NOT recurse, so a container folder answers with 0 however many cases sit nested beneath it, and that zero looks exactly like an empty folder. For a subtree count call get_folder with includeStats and read statistics.totalCases; to list the cases, walk the tree with list_folders and ask for each suite. Omit to list every case in the project.
priorityNoFilter by priority (e.g., Low, Medium, High, Critical). Values are project-specific.
projectIdYesProject UUID to list cases from
includeDeletedNoInclude archived/deleted cases
automationStatusNoFilter by automation status: "automated" (has linked autotests) or "not_automated" (no linked autotests)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv1.5.3
    • changedInput schema / properties / folderId / description
      Previous value: -"Filter by specific folder UUID. Omit to list all cases in project."New value: +"Filter to cases held DIRECTLY by this folder UUID. It does NOT recurse, so a container folder answers with 0 however many cases sit nested beneath it, and that zero looks exactly like an empty folder. For a subtree count call get_folder with includeStats and read statistics.totalCases; to list the cases, walk the tree with list_folders and ask for each suite. Omit to list every case in the project."
  2. First observedv1.5.0

TDQS

A5/5.0
Behavior5/5

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

Even though annotations already declare the operation read-only and idempotent, the description adds extensive behavioral detail: return shape, updatedAt semantics, absence of lastExecutedAt, the meaning of linkedAutotestCount, the custom priority marker, and the no-top-level-total quirk. This goes well beyond what annotations provide.

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 long but every sentence earns its place; it front-loads the primary purpose and then packs edge cases, return-shape details, and exclusions without padding. The structure moves from what the tool does, to return shape, to caveats, to alternatives — a clear logical flow.

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 list endpoint with no output schema, the description is extraordinarily complete: it covers return fields, pagination shape, field semantics, filter behavior, deletion handling, automation interpretation, and alternatives for missing data. There is no meaningful gap left for an agent to discover by trial and error.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds crucial semantics beyond the schema: search accepts TC- prefix, folderId does not recurse and a zero result can look like an empty folder, automationStatus uses the same narrow definition as linkedAutotests, and availablePriorities.custom is a marker rather than a real priority. These details materially improve correct tool usage.

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 opens with a specific verb and resource — 'List test cases in a project with filtering and pagination' — and immediately communicates the tool's scope. It clearly distinguishes listing cases from related sibling tools like get_execution_cases or list_test_collections.

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?

The description explicitly directs agents to alternatives when appropriate, such as using get_folder for subtree counts, get_case_execution_history for manual execution history, and get_test_case with includeRecentExecutions for automated runs. It also explains how to resolve display IDs with search, giving concrete when-to-use guidance.

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

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/m00nreport/mcp-server'

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