Skip to main content
Glama

get_launches_statistics

Read-onlyIdempotent

List project launches with pass, fail, skip, and duration stats, filter by status or tags, and compute run and test pass rates over a selected period.

Instructions

List the launches of a project, newest first, each with its own pass, fail, skip and duration figures. Every launch row carries id, launch, status, startedAt, endedAt, durationSeconds, tags and stats - the NAME of the launch is in a field called launch, not title or name. The status is REPORTED by the CI job rather than derived from the numbers beside it, and it runs BOTH ways. A launch can be stored failed with stats.failed 0, because the job failed for a reason no test recorded. And a launch that reported nothing at all can be stored passed with stats.total 0 - one here sits 75 minutes after a real run that failed 145 tests, so reading the newest launch as green clears nothing and the earlier failures still stand. Check stats.total before treating a green newest launch as evidence. Never infer one from the other; to answer what failed, read the tests with get_launch_tests. Every launch row also carries a stats object of total, passed, failed, skipped, flaky, retries and running. total EXCLUDES skipped even though skipped is printed beside it, so the identity that holds is passed + failed + flaky = total; retries counts retry ATTEMPTS, not tests that were retried, which is why it can exceed flaky. Returns launches, a summary over the whole window (totalRuns, passedRuns, failedRuns, runningRuns, runPassRate, totalTests, totalPassed, totalFailed, totalSkipped, totalFlaky, testPassRate, avgDurationSeconds), the period and filters applied, and pagination with the real total; there is no top-level total. Read the two rates carefully, because they answer different questions and neither denominator is obvious. runPassRate is the share of LAUNCHES that ended green, out of totalRuns - and totalRuns is EVERY launch in the window. Only three of the end statuses have a bucket - passedRuns, failedRuns and runningRuns - so a launch stored as finished, interrupted, timedOut or completed is counted in totalRuns and in none of them, and the three need not add up to totalRuns. That shortfall is why get_launches_trends and run_health_check answer a slightly higher run pass rate over the same window: they count only launches that passed or failed, so their denominator is smaller. testPassRate is the share of TESTS, computed as (totalPassed + totalFlaky) / totalTests: flaky counts as a pass, because a flaky test passed on a retry and the launch is green on it, and totalTests already EXCLUDES skipped, so totalPassed + totalFailed + totalFlaky is the whole of it while totalSkipped sits outside. Both rates are null, not 0, when the window held nothing at all - testPassRate with no tests, runPassRate with no launches - since nought percent would read as a verdict on work that never ran. IMPORTANT: days defaults to 30, so a project idle for longer returns an empty list, which means nothing in the window rather than nothing at all. Use limit, offset and search to page, statuses or tags to narrow. Reach for get_launches_trends when the question is about the project over time rather than about particular launches, and get_launch_tests when you have one launch and want the tests in it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoLookback period in days
tagsNoFilter by tags
limitNoNumber of launches to return
offsetNoPagination offset
searchNoSearch the launch NAME (the launch field on each row), its id, or its tags. Launches carry no trigger metadata at all - nothing records that a run was nightly, on merge or manual, and there is no branch or CI-job field - so a request naming a run by its schedule can only be resolved through a name or tag the reporter happened to set, or by startedAt. If a name search comes back empty, say the run cannot be identified rather than assuming the newest launch is the one meant: three launches here carry byte-identical stats.
statusesNoFilter by launch status. Set by the reporters through the ingest service, so this list is fixed and not project-configurable. A launch that ended without an explicit status, and whose totals did not reconcile, is stored as finished: that is usually an empty or half-reported launch, and it counts toward totalRuns while sitting in none of the passed, failed or running buckets.
projectIdYesProject UUID to query

Schema Changelog

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

  1. Changed3 schema fields changedv1.5.3
    • changedInput schema / properties / search / description
      Previous value: -"Search in launch title/ID/tags"New value: +"Search the launch NAME (the launch field on each row), its id, or its tags. Launches carry no trigger metadata at all - nothing records that a run was nightly, on merge or manual, and there is no branch or CI-job field - so a request naming a run by its schedule can only be resolved through a name or tag the reporter happened to set, or by startedAt. If a name search comes back empty, say the run cannot be identified rather than assuming the newest launch is the one meant: three launches here carry byte-identical stats."
    • changedInput schema / properties / statuses / description
      Previous value: -"Filter by run status"New value: +"Filter by launch status. Set by the reporters through the ingest service, so this list is fixed and not project-configurable. A launch that ended without an explicit status, and whose totals did not reconcile, is stored as finished: that is usually an empty or half-reported launch, and it counts toward totalRuns while sitting in none of the passed, failed or running buckets."
    • changedInput schema / properties / statuses / items / enum
      Previous value: -[
      -  "passed",
      -  "failed",
      -  "running",
      -  "interrupted"
      -]New value: +[
      +  "passed",
      +  "failed",
      +  "running",
      +  "finished",
      +  "interrupted",
      +  "timedOut",
      +  "completed"
      +]
  2. First observedv1.5.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool as readOnly, idempotent, and safe. The description goes well beyond these by exposing crucial statistical behaviors: statuses are reported by the CI job, not derived from the numbers; total excludes skipped; retries counts attempts; runPassRate and testPassRate have different denominators; rates are null when there is no data; and pagination has a real total with no top-level total. None of this contradicts the 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 unusually long, but it is packed with distinct near-miss pitfalls that are directly relevant to correct invocation and interpretation. It front-loads the purpose and row schema, then expands into statistical pitfalls that an agent would otherwise never guess. A small amount of trimming and structural formatting could improve scannability, but no sentence felt purely filler.

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?

Even though there is no output schema, the description reveals the entire launch object field set, the aggregated summary object's exact fields, the pagination behavior, the meaning of null rates, and the empty-list interpretation. It also covers how to distinguish this tool from related alternatives. For a statistical listing tool with this level of edge-case nuance, nothing needed for a careful call is missing.

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?

Though the schema already describes every parameter with 100% coverage, the description adds meaningful extra semantics: days means a lookback window and an empty list can mislead; search looks at the launch field, id, or tags and carries no trigger metadata; statuses have a fixed enum set; pagination through limit/offset is explained in context; statuses alone do not sum to totalRuns. This far exceeds the baseline of 3.

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 uses a specific verb and resource: 'List the launches of a project, newest first', then enumerates the fields returned (id, launch, status, startedAt, endedAt, durationSeconds, tags, stats). It also explicitly differentiates from siblings by telling the agent when to use get_launches_trends and get_launch_tests, so the purpose is unmistakable even among many similar 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?

The description gives explicit when-to-use guidance: get_launches_trends for questions about the project over time, get_launch_tests for a single launch's tests. It also explains under what conditions an empty list means no data in the window (days defaults to 30) and warns that a name search matching nothing should be reported as 'cannot be identified' rather than assuming the newest launch. This is far beyond a generic read tool description.

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