Skip to main content
Glama

List workflow runs

list_workflow_runs
Read-onlyIdempotent

Use this when someone asks about recent or failed runs of a durable workflow in a Croncool project. Returns each run's id, workflow name, status, timings and error code, newest first by default, 20 per page with a cursor, filterable by workflow and status. Not for one run's steps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNonewest (default) or oldest first
limitNoRuns per page, from 1 to 100; defaults to 20
cursorNoThe nextCursor of the previous page with the same project, workflow, status and sort; absent for the first page
statusNoOnly runs in this status: pending, running, completed, failed or cancelled
projectIdYesProject id
workflowNameNoOnly runs of this workflow name

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
runsYesRun identity, status, timings and machine error code. Workflow inputs, outputs and error messages are excluded.
hasMoreYes
nextCursorYesCursor for the next page with the same filters; null on the last page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / cursor / description
      Previous value: -"Opaque nextCursor from an earlier call with the same project, workflow, status, and sort filters"New value: +"The nextCursor of the previous page with the same project, workflow, status and sort; absent for the first page"
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of runs to return (default 20, max 100)"New value: +"Runs per page, from 1 to 100; defaults to 20"
    • changedInput schema / properties / projectId / description
      Previous value: -"Project id whose workflow runs should be listed (required)"New value: +"Project id"
    • changedInput schema / properties / sort / description
      Previous value: -"Order of the returned runs (default newest first)"New value: +"newest (default) or oldest first"
    • changedInput schema / properties / status / description
      Previous value: -"Only return runs in this status"New value: +"Only runs in this status: pending, running, completed, failed or cancelled"
    • changedInput schema / properties / workflowName / description
      Previous value: -"Only return runs of this workflow"New value: +"Only runs of this workflow name"
    • addedOutput schema / properties / nextCursor / description
      Added value: +"Cursor for the next page with the same filters; null on the last page"
    • addedOutput schema / properties / runs / description
      Added value: +"Run identity, status, timings and machine error code. Workflow inputs, outputs and error messages are excluded."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: newest-first default ordering, 20-per-page pagination with a cursor, and the returned field set (id, workflow name, status, timings, error code). It does not discuss rate limits or cursor expiry, but for a read-only list tool this is solid.

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?

Two sentences, zero filler, with the usage trigger front-loaded before the return and pagination details. Every clause earns its place.

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?

An output schema exists, yet the description still summarizes the returned fields, and the pagination/cursor and default-sort behavior are all disclosed. Nothing an agent needs to call this six-parameter list tool correctly is missing.

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?

Schema description coverage is 100%, so the schema already documents projectId, workflowName, status, sort, limit and cursor. The description restates the defaults and filters but adds no syntax or format detail beyond the schema, which is the expected baseline when the schema carries the load.

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 and resource (list workflow runs) scoped to a Croncool project, and explicitly carves out the sibling territory with "Not for one run's steps." An agent can distinguish it from get_workflow_run or get_job_runs without opening any schema.

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?

"Use this when someone asks about recent or failed runs" gives a concrete trigger, and the closing exclusion ("Not for one run's steps") steers away from the detail sibling. It stops short of naming the alternative tool explicitly, so the routing is clear but not fully enumerated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources