TeamShared

process_run_list

List Process runs in this org. Each row includes stream_id and work_id.

Pass source=events to fold every run from the append-only event log — the primary event stream — without touching process_runs. The template, stage, subject and activity filters read process_runs and are ignored with source=events.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No
`stage`	No	Filter by template stage slug
`offset`	No
`source`	No	'row' (default) reads process_runs; 'events' reconstructs the list from stream_events alone (#343 cutover)
`status`	No	Filter: active, completed, cancelled, failed
`process`	No	Filter by process slug (board-pickup)
`work_id`	No	Filter by the linked work item (UUID)
`activity`	No	Filter active runs: running, or waiting (on a human step)
`template`	No	Filter by template slug (claim); 'none' lists runs with no template
`project_id`	No	Filter by the project the run belongs to (UUID)
`parent_run_id`	No	Filter: the fan-out children of this run UUID
`subject_entity_id`	No	Filter by subject entity UUID

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 17, 2026

addedInput schema / properties / project_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by the project the run belongs to (UUID)"
+}

addedInput schema / properties / work_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by the linked work item (UUID)"
+}

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / parent_run_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter: the fan-out children of this run UUID"
+}

Changed5 schema fields changedOct 15, 2026

addedInput schema / properties / activity

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter active runs: running, or waiting (on a human step)"
+}

addedInput schema / properties / stage

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by template stage slug"
+}

changedInput schema / properties / status / description

Previous value: -"Filter: active, completed, cancelled"New value: +"Filter: active, completed, cancelled, failed"

addedInput schema / properties / subject_entity_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by subject entity UUID"
+}

addedInput schema / properties / template

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by template slug (claim); 'none' lists runs with no template"
+}

Changed1 schema field changedSep 17, 2026

addedInput schema / properties / source

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "'row' (default) reads process_runs; 'events' reconstructs the list from stream_events alone (#343 cutover)"
+}

AddedSep 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose a non-obvious behavioral trait: source=events reconstructs runs from the append-only event log without touching process_runs, and that the template/stage/subject/activity filters are silently ignored in that mode. That filter-suppression warning is exactly the kind of gotcha an agent needs. It omits pagination/limit behavior, but the important caveat is covered.

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-loaded with the primary purpose, then a second short paragraph for the source-mode caveat. Every sentence carries information and nothing is padded, though the prose is somewhat dense and could separate the filter-ignored warning more sharply.

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 12-parameter, zero-required list tool with an output schema present, the description covers the main behavioral trap and the row contents; return shape needn't be restated. It stops short of mentioning pagination semantics for limit/offset, which is the only notable remaining gap.

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 high (83%), so the baseline is 3, but the description adds meaning the schema does not: it explains what source=events does at the storage level and, critically, that four of the filters become no-ops when that mode is selected. That interaction between parameters is real added value.

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?

The description opens with a specific verb+resource ("List Process runs in this org") and adds scope detail (each row includes stream_id and work_id), which distinguishes it from process_run_get and process_run_events. It does not explicitly name those siblings, so it falls short of a 5.

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?

It gives one concrete routing rule — pass source=events to read from the event log instead of process_runs — which is genuine usage guidance. However, it offers no guidance on when to prefer this tool over process_run_get, process_run_events, or agent_run_list, and no exclusions for the default path.

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

All TeamShared tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.