Skip to main content
Glama

get_launches_trends

Read-onlyIdempotent

Aggregate launch trends over a window: daily pass rates, most-failing tests, flaky tests, and slowest runs.

Instructions

Aggregate a project over a window: pass rate over time, the tests that fail most, the flaky ones, duration trends and the slowest tests. IMPORTANT: there is no single pass rate in this response. trends.passRate is a SERIES, one row per day, each carrying total_runs, passed_runs and pass_rate; to answer a question about the whole window you have to sum the daily totals yourself rather than average the daily rates, which would weight a quiet day the same as a busy one. And it is a rate over LAUNCHES that ended green, not over tests that passed, and the two differ widely; for the test-level figure use summary.testPassRate from get_launches_statistics. In the failing section, total_runs counts ATTEMPT ROWS rather than launches, so failure_rate is failed attempts over attempts and a test retried three times in one launch contributes three. That section ranks over the WHOLE window and says nothing about the present: a test that failed heavily early on and was fixed still tops the list, and no field in the row - there is no lastStatus and no lastSeen - reveals that it is green today. It answers what has failed most, never what is failing now; for that, read the newest launch with get_launch_tests. Flakiness is ranked by flip_count, the number of times a test changed result between consecutive ATTEMPTS, retries included, alongside instability_score which weighs how evenly it splits between pass and fail. Attempts, not launches: a test that fails twice and passes on the third try in every run scores high here while never once turning a launch red, and flip_count can exceed the number of launches in the window. Only passed and failed attempts are counted, so skipped and flaky rows are absent from both figures. For per-launch flipping, read get_test_history and group by runId. days defaults to 30, so a quiet project returns empty series, and the flaky, slowest and tests-by-tag sections are additionally capped at 90 days however much you pass, while the trend series itself honours the full range: so a 365-day call answers two different windows in one payload. Counts and rates in this response come back as STRINGS, total_runs as "45" and failure_rate as "80.00", so coerce them before comparing or summing. Use include[] to compute only the sections you need and topN to size the lists. Reach for get_launches_statistics to page through individual launches, and get_launch_tests when you have one launch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoLookback period in days (1-365)
tagsNoFilter runs by these tags
topNNoLimit for top-N lists (failing, flaky, slowest tests)
includeNoWhich trends to include in response
projectIdYesProject UUID to analyze

Schema Changelog

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

  1. First observedv1.5.0

TDQS

A5/5.0
Behavior5/5

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

The description goes far beyond the readOnly/idempotent annotations by exposing critical behavioral caveats: passRate is a per-day series requiring manual summation, rates are over green launches not passed tests, failure_rate counts attempt rows rather than launches, rankings describe the whole window and never current status, flakiness uses flip_count over attempts, skipped/flaky rows are excluded, and numeric values arrive as strings. This is extensive, non-obvious behavior that an agent must know to use results correctly.

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 delivers a distinct, non-redundant warning or instruction. It opens with a scannable summary of what is computed, then front-loads the most dangerous misinterpretation (no single pass rate), and systematically proceeds through failure, flakiness, bounds, types, options, and alternatives. No filler exists despite the length.

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 complex aggregation tool with no output schema, the description covers the shape of the response, the meaning of each major section, the units of measurement, known limitations, silent behaviors (quiet projects return empty series), and exactly how to interpret values for decision-making. Given the tool's complexity, this description is unusually complete and leaves little to chance.

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?

Even though schema already covers all parameters, the description adds crucial semantics: daily series with quiet-day bias, attempts versus launches, 90-day caps regardless of days for some sections while the full range applies elsewhere, and string coercion for counts and rates. It also contextualizes days, include, and topN by explaining their downstream effects on the response, which the schema does not provide.

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?

Description begins with specific verb+resource: 'Aggregate a project over a window' and lists distinct deliverables (pass rate, failing tests, flaky tests, duration trends, slowest tests). It clearly distinguishes itself from siblings by naming get_launches_statistics and get_launch_tests as alternatives, so an agent can immediately tell what this tool uniquely does.

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?

Explicit guidance is provided for when to use this tool vs alternatives: paginate individual launches with get_launches_statistics, read newest launch with get_launch_tests, per-launch flipping with get_test_history. It also instructs on include[] and topN to control which sections are computed, leaving no ambiguity about scope.

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