Skip to main content
Glama

get_launch_tests

Read-onlyIdempotent

Retrieve all test attempts from a launch with results, errors, and artifact links, using titlePath to count distinct tests across retries.

Instructions

Get every test inside one launch, with results, error messages and stack traces for the failures. IMPORTANT: rows are one per retry ATTEMPT, not one per test, so a retried test appears more than once and the row count can exceed the launch stats counts, while the stats on the launch itself count tests rather than attempts. Two traps follow, and both have produced a wrong count. First, testId is minted per ROW, so every attempt has a different one and deduplicating on testId still counts attempts: the identity of a test across its attempts is titlePath, optionally with filePath. Second, retry is 0-based but a retry:0 row is NOT guaranteed to exist - a launch can hold a retry:1 row whose first attempt was never stored - so counting rows where retry is 0 undercounts. Count distinct titlePath. Each row also carries status, previousStatus, durationMs, tags and errors. previousStatus reads superseded on an attempt a later one replaced, which looks like the clean way to filter, and is not: on a measured launch of 4472 rows, dropping the superseded ones left 4460 against 4457 real tests, because a retried attempt can carry its own earlier result there instead. The launch stats embedded in this response follow the same convention as everywhere else: total EXCLUDES skipped, so a launch with total 4417 and skipped 40 really does hold 4457 distinct tests, and passed counts first-time passes with flaky held separately. Use this once you have a launch id, which get_launches_statistics gives you; use get_test_history to follow one test across launches instead. For each failed test that has artifacts the response carries an attachments array of id, name, contentType, size and url. The url is fully qualified: if it is an API URL, fetch it with the same X-MCP-Key header you use for this server, while presigned storage URLs need no header. That is how you reach screenshots, traces, videos and source files when investigating a failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of tests to return
offsetNoPagination offset
searchNoSearch in test title path or file path
launchIdYesRun/launch UUID to get tests from. Obtain from get_launches_statistics or get_launches_trends.
statusesNoFilter by ATTEMPT-ROW status, not by how a test ended (default: all). A test that failed once and passed on retry still returns its failed row here, so counting the filtered rows, or even counting distinct titlePath over them, answers how many tests had this status at SOME attempt - never how many ended that way. A launch whose own stats.failed is 0 can return 15 failed rows across 13 titles. For tests that ENDED failed, fetch the rows unfiltered and keep the highest-retry row per titlePath, or read stats.failed on the launch itself.
includeErrorsNoInclude error details for failed tests

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 / statuses / description
      Previous value: -"Filter by test status (default: all statuses)"New value: +"Filter by ATTEMPT-ROW status, not by how a test ended (default: all). A test that failed once and passed on retry still returns its failed row here, so counting the filtered rows, or even counting distinct titlePath over them, answers how many tests had this status at SOME attempt - never how many ended that way. A launch whose own stats.failed is 0 can return 15 failed rows across 13 titles. For tests that ENDED failed, fetch the rows unfiltered and keep the highest-retry row per titlePath, or read stats.failed on the launch itself."
  2. First observedv1.5.0

TDQS

A4.8/5.0
Behavior5/5

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

The description goes far beyond annotations by exposing non-obvious behavior: rows are per retry attempt, retry is 0-based but a retry:0 row may not exist, testId is per-row rather than per-test, previousStatus 'superseded' is explicitly unreliable, and launch stats exclude skipped tests. It also documents authentication requirements for artifact URLs, which is valuable operational behavior not visible in annotations.

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 long, but it is front-loaded with a clear one-sentence summary followed by essential caveats. Nearly every sentence earns its place because the retry-attempt semantics are genuinely non-obvious and easy to get wrong. It is slightly verbose in explaining examples and traps, but the structure stays readable.

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?

There is no output schema, yet the description fully compensates by listing row fields (status, previousStatus, durationMs, tags, errors) and explaining the attachments array with url, name, id, contentType, size. It also covers pagination semantics indirectly through limit/offset in the schema and covers retry counting pitfalls, test-identity semantics, launch-stats conventions, and artifact authentication. An agent has enough context to invoke the tool and interpret results correctly.

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 description coverage is 100%, so the baseline is already strong. The description adds real semantic value beyond the schema by explaining that statuses filters by ATTEMPT-ROW status rather than final test outcome, and by noting where launchId comes from (get_launches_statistics or get_launches_trends). It does not re-explain limit, offset, or search, which is appropriate since the schema covers them.

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: 'Get every test inside one launch, with results, error messages and stack traces for the failures.' It also distinguishes this tool from related siblings by noting get_test_history is for following a test across launches and that get_launches_statistics is the source of the launch id. The caveat about one row per retry attempt further clarifies exactly what the tool returns.

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 states when to use this tool: 'Use this once you have a launch id, which get_launches_statistics gives you' and provides the alternative for a different need: 'use get_test_history to follow one test across launches instead.' It also warns against using row-level filters for test-level counts, giving clear guidance on what this tool should not be used for.

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