Skip to main content
Glama

List Org Runs

listOrgRuns
Read-onlyIdempotent

List runs across every team in an organization, filtered by status, agent, team, source, evaluation issues and time. Intended for external monitoring: one call covers the whole org instead of one per team. Requires an organization Admin, Executive, or Owner role, and an API key scoped to all teams you can access — a key pinned to a single team is rejected, because this endpoint spans every team in the organization.

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of runs per page (1-500, default 20). The cap is higher than the team runs endpoint's because this route serves bulk export: at 100 requests a minute per key, page size is what bounds how fast a month of runs can be pulled.
orgIdYesThe organization's unique identifier
sinceNoAlias of `completed_after`, kept because it is the name the public team runs endpoint ships. Prefer `completed_after`: this endpoint carries a creation and a start window too, and only the column-named pair says which one this is.
untilNoAlias of `completed_before`, kept because it is the name the public team runs endpoint ships. Prefer `completed_before`.
cursorNoResume after the run a previous page ended on: pass the `next_cursor` that page returned, with the same filters and sort_order. Runs created or resolved in between cannot shift a boundary you have already passed, so a sweep sees every run exactly once, and a sweep that started under the default 7-day window keeps that window on every page. This list has no offset parameter: skipping rows costs the database every skipped row, and a run created between two requests shifts every later offset by one, so an offset sweep can repeat or miss a run. 400 when the value is not a cursor this endpoint issued.
sourceNoFilter to runs created from this source (e.g. api, scheduling)
statusNoFilter to runs with this status. `needs_attention` is the monitoring status: runs that are waiting on a human or failed, plus runs whose latest evaluation flagged a critical issue — a run can finish as `completed` and still have accomplished nothing.
team_idNoFilter to runs on this team
agent_idNoFilter to runs for this agent
count_onlyNoSkip row selection and enrichment. The normal list response shape is returned with an empty row array and the matching total.false
has_issuesNoFilter on the run's latest successful evaluation: true returns only runs it flagged, false only runs it did not. Only the latest evaluation counts — an older flag does not match — and a run whose latest evaluation errored, or that has none, counts as unflagged. Omit to return both.
sort_orderNoSort direction on created_at (default desc)desc
created_afterNoReturn runs created at or after this ISO-8601 timestamp. Every run has a creation time, so this is the window that returns all runs in a period whatever state they reached — unlike the started and completed windows below, which exclude runs that never started and runs still in flight respectively. When the request carries no lower time bound (`created_after`, `started_after`, `completed_after` or `since`), this defaults to 7 days ago and `default_window_applied` is true in the response: an organization's run history is unbounded, and a monitor wants what is recent. An upper bound alone keeps the default floor. Pass any lower bound to replace it.
include_totalNoReturn `total`, the count of every matching run ignoring pagination. Off by default: counting walks every match where the page stops at `limit`, so on a large organization it costs orders of magnitude more than the rows themselves. Ask for it when you are driving a pager, not when you are polling. Implied by `count_only`.false
started_afterNoReturn runs that started at or after this ISO-8601 timestamp. Runs that never started are excluded. Pair with `started_before` to bound a stuck-run query to a window — without a lower bound, `status=running` also counts every run left running months ago.
created_beforeNoReturn runs created before this ISO-8601 timestamp (exclusive). Pair with `created_after` for a period. A closed creation window is also the stable one to paginate: results are ordered by creation time, so runs arriving mid-sweep cannot shift a closed window's pages.
issue_severityNoOnly runs whose latest successful evaluation has at least one failing rubric at this severity (critical | medium | low). Implies has_issues.
started_beforeNoReturn runs that started before this ISO-8601 timestamp. Combine with status=running to find stuck runs — `since`/`until` filter on completion, so they never match a run that is still going.
completed_afterNoReturn runs completed at or after this ISO-8601 timestamp. Runs that have not completed are excluded, including every stuck one — reach for `started_after`/`started_before` to bound those. Alias of `since`; pass one or the other, not both.
completed_beforeNoReturn runs completed before this ISO-8601 timestamp (exclusive). Runs that have not completed are excluded. Alias of `until`; pass one or the other, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / status / enum
      Previous value: -[
      -  "not_started",
      -  "pending",
      -  "starting",
      -  "running",
      -  "waiting",
      -  "completed",
      -  "failed",
      -  "interrupted",
      -  "stopped",
      -  "needs_attention"
      -]New value: +[
      +  "not_started",
      +  "pending",
      +  "starting",
      +  "running",
      +  "waiting",
      +  "completed",
      +  "failed",
      +  "interrupted",
      +  "expired",
      +  "stopped",
      +  "needs_attention"
      +]
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely extra operational context: the required admin/executive/owner role and the constraint that an API key pinned to a single team is rejected. It does not restate annotation content, adding real value beyond the structured fields.

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?

Three tightly packed sentences: purpose/scope, the monitoring rationale, then the hard auth prerequisite. The gating information is front-loaded and nothing is wasted.

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

Completeness4/5

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

For a 20-parameter read tool with no output schema and full annotation coverage, the description supplies the selection-critical facts: org-wide scope, the monitoring use case, and the role/key prerequisites. Pagination, the default 7-day window and return shape are left to the schema, which is acceptable, though a mention of the pagination model would round it out.

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% and the per-parameter descriptions are unusually thorough (aliasing, defaults, pagination semantics, rate-limit rationale). The description itself adds no parameter-level meaning, so it sits at the baseline of 3 with the schema doing all the heavy lifting.

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 runs') plus a precise scope ('across every team in an organization'), immediately distinguishing it from the team-scoped runs siblings. An agent can tell this apart from listRuns/listTeamRuns 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?

'Intended for external monitoring: one call covers the whole org instead of one per team' gives a clear when-to-use and implies the alternative of calling per team. It stops short of naming the concrete sibling tool (e.g. listRuns) that the per-team path would use, so the routing is implied rather than explicit.

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