Skip to main content
Glama

list_test_collections

Read-onlyIdempotent

Find test collections filtered by folder, release, or status to locate a collection UUID for detailed execution results.

Instructions

List Test Collections in a project - the groupings used for sprint, release or ad-hoc manual testing. Each entry returns id, name, status, priority, environment, assignedTo, folderId/folderName, releaseId/releaseName, start and end dates, and stats (totalTests, passed, failed, blocked, notExecuted, skipped, inTesting), plus a pagination block. Use it to find a collection UUID, filtered by folder, release or status; then call get_test_collection for one collection with its individual test cases and their execution status. A Test Collection is one grouping of cases, not the top-level Executions-page container, so use list_executions to find those. For the case library itself rather than runs of it, use list_test_cases. Shadow collections created inside an execution are never listed, and archived ones only with includeDeleted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of collections to return
offsetNoPagination offset
statusNoFilter by collection status. Unlike case and release statuses, a collection status is NOT project-configurable: the storage layer accepts only these four, so ignore whatever test_run_status get_project reports for this purpose. An unrecognised value is rejected rather than quietly ignored.
folderIdNoFilter by folder UUID. Omit to list all collections.
rootOnlyNoIf true, only return collections not in any folder (root level)
projectIdYesProject UUID to list collections from
releaseIdNoFilter by release UUID
includeDeletedNoInclude archived collections

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 / status / description
      Previous value: -"Filter by collection status"New value: +"Filter by collection status. Unlike case and release statuses, a collection status is NOT project-configurable: the storage layer accepts only these four, so ignore whatever test_run_status get_project reports for this purpose. An unrecognised value is rejected rather than quietly ignored."
  2. First observedv1.5.0

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds meaningful behavioral context: shadow collections are excluded, archived collections require includeDeleted, and the response includes a pagination block. These are details an agent cannot infer from annotations alone.

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 dense but not padded; it front-loads the purpose and return contents, then handles sibling distinctions and behavioral caveats. Every sentence adds information an agent needs before calling the tool.

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 tool with no output schema, the description adequately enumerates the returned fields, mentions pagination, names the filter dimensions, and differentiates it from nearby siblings. Nothing essential to selecting and invoking the tool correctly is missing.

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 coverage is 100%, so the baseline is 3. The description reinforces that folderId, releaseId, and status are filters and that the tool is meant for finding a collection UUID, but it does not need to repeat what the schema already documents in full.

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: "List Test Collections in a project." It also distinguishes this tool from list_executions, list_test_cases, and get_test_collection, making its scope unambiguous.

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?

It explicitly tells the agent when to use this tool: to find a collection UUID filtered by folder, release, or status, then call get_test_collection. It also gives exclusion rules: shadow collections are never listed, archived ones need includeDeleted, and executions/case libraries belong to other tools.

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