Skip to main content
Glama

list_pipeline_runs

Read-only

Retrieve recent pipeline runs, newest first, with filters for project, pipeline, branch, status, and result to inspect build outcomes.

Instructions

Recent runs (builds), newest first. status: inProgress, completed, notStarted, ... result: succeeded, failed, canceled, partiallySucceeded.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_pipeline_runs"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNo
branchNo
resultNo
statusNo
projectNo
pipeline_idNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.4/5.0
Behavior3/5

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

The annotations establish safe read-only behavior, while the description adds recent-run scope and newest-first ordering. It does not clarify the default project/pipeline scope, result truncation or pagination, or how combined status and result filters behave.

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 two compact lines front-load the resource and ordering and contain no filler. The telegraphic fragments, unexplained ellipsis, and compressed filter line make the wording somewhat cryptic rather than fully polished.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The annotations and output schema already cover safety and return shape, so return-value prose is unnecessary. For a tool with six optional, otherwise undocumented parameters, though, the missing unfiltered scope, limiting/pagination behavior, and sibling-selection guidance leave clear invocation gaps.

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?

With 0% schema description coverage, the examples for status and result provide useful filter vocabulary absent from the schema. However, the status list is explicitly incomplete, and the description does not explain top as a result limit or how branch, project, and pipeline_id narrow the query, so it only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Recent runs (builds), newest first" identifies the resource as pipeline executions and states the result ordering; together with the tool name, the listing operation is clear. It does not explicitly distinguish this tool from list_pipelines or get_pipeline_run.

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

Usage Guidelines3/5

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

The focus on recent runs and the status/result vocabulary imply use for browsing or filtering build history. There is no explicit guidance about prerequisites or when to use get_pipeline_run for a single run, get_pipeline_log for logs, or list_pipelines for pipeline definitions.

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