Skip to main content
Glama

get_test_run_results

Read-only

Paginate execution results for a Jira test run or cycle, with an option to return only the latest execution per item. Use startAt and maxResults to page through values.

Instructions

Page through the execution results of a test run / test cycle (GET /testrun/{key}/testresults/page). An item can have several executions; onlyLastExecutions=true keeps only the most recent one per item, so it never returns more values than the run has items. Creating a run already seeds one 'Not Executed' execution per item (that execution IS the item's last one), so with onlyLastExecutions=false — the default — total starts at the item count, not at 0. Older Zephyr Scale builds have no /page endpoint: the deprecated flat GET /testrun/{key}/testresults is then read and paginated client-side, and onlyLastExecutions is resolved from the run object, whose items[] name the id of each item's last execution; the note in the response says which path produced the values (a run that does not exist still surfaces as a 404). Values come in the order the API returns them, which is neither run-item order nor execution order. Returns { startAt, maxResults, total, count, isLast, values, note? } where total is the size of the set being paged — the number of results on the server, or the post-deduplication count when onlyLastExecutions is true — and isLast is startAt + count >= total.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
startAtNo0-based index of the first result to return (default 0)
maxResultsNoMaximum number of results to return (default 50; the API server-side default is 200)
testRunKeyYesTest run (cycle) key, e.g. PROJ-R123 (PROJ-C123 on older instances)
onlyLastExecutionsNotrue returns only the last execution of each run item; omitted means the API default (false — all executions)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.5

TDQS

A4.6/5.0
Behavior5/5

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

With readOnlyHint already covering safety, the description adds substantial behavior: pagination semantics, the total/isLast formula, the note field indicating which path produced values, unspecified ordering, and 404 on missing runs. This is far beyond what annotations convey.

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?

Front-loads the purpose and every sentence carries information, but it is delivered as a single dense paragraph mixing return-value, fallback, and parameter detail. Slightly heavy for a description, though little is wasted.

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?

No output schema exists, so the description fully documents the return shape ({ startAt, maxResults, total, count, isLast, values, note? }) and the meaning of total and isLast. An agent has everything needed to call and interpret results.

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 coverage is 100% (baseline 3), and the description adds real meaning: onlyLastExecutions deduplication behavior and the fact that a newly created run already seeds one 'Not Executed' execution so total starts at the item count. It also clarifies maxResults client vs server defaults implicitly.

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?

States a specific verb (page through) and resource (execution results of a test run / test cycle), including the underlying endpoint. It is clearly distinguishable from siblings like get_test_run, get_test_run_summary, and get_latest_result_for_test_case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: onlyLastExecutions semantics, the default, and the older-build fallback path. It does not explicitly name an alternative tool or state when to prefer this over, say, get_latest_result_for_test_case, so it stops short of full when/when-not guidance.

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

Deploy Server

Other Tools