TeamShared

process_run_create

Create a Process run from a catalog process or a launchable playbook.

Board Pickup (process or playbook_slug=board-pickup) starts at Scan. Any playbook with tool_recipe.process_steps or a skill sequence can start a run without a hardcoded catalog entry. The run freezes playbook/skill versions + steps, current step, status, and stream_id=run:{id}. Human/gate steps open a Work item and link it. Not a Camunda / Zeebe / LangGraph workflow.

Input Schema

TableJSON Schema

Name	Required	Description
`agent`	No	Override agent attribution label
`process`	No	Optional process slug or name (board-pickup / Board Pickup). Omit when playbook_slug names a launchable playbook.
`work_id`	No	Optional work UUID (writes WorkItem --case_of--> current ProcessStep)
`project_id`	No	Optional project UUID to bind this run (writes Project --runs--> Process)
`playbook_slug`	No	Playbook to launch as a run. tool_recipe.process_steps drive the walk when present; otherwise the skill sequence is used. Enough on its own — no catalog process required.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedSep 15, 2026

changedInput schema / properties / playbook_slug / description

Previous value: -"Optional playbook whose tool_recipe.process_steps drive advancement (defaults to the process slug / catalog playbook)"New value: +"Playbook to launch as a run. tool_recipe.process_steps drive the walk when present; otherwise the skill sequence is used. Enough on its own — no catalog process required."

addedInput schema / properties / process / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / process / default
```
Added value: +null
```

changedInput schema / properties / process / description

Previous value: -"Process slug or name (board-pickup / Board Pickup)"New value: +"Optional process slug or name (board-pickup / Board Pickup). Omit when playbook_slug names a launchable playbook."

removedInput schema / properties / process / type
```
Removed value: -"string"
```
removedInput schema / required
```
Removed value: -[
-  "process"
-]
```

Changed3 schema fields changedSep 11, 2026

addedInput schema / properties / playbook_slug

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional playbook whose tool_recipe.process_steps drive advancement (defaults to the process slug / catalog playbook)"
+}

changedInput schema / properties / project_id / description

Previous value: -"Optional project UUID to bind this run"New value: +"Optional project UUID to bind this run (writes Project --runs--> Process)"

addedInput schema / properties / work_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional work UUID (writes WorkItem --case_of--> current ProcessStep)"
+}

AddedSep 10, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and does so well: it discloses that the run freezes versions/steps/status and stream_id, that human/gate steps open and link a Work item, and that this is not a Camunda/Zeebe/LangGraph workflow. It does not cover permissions or failure modes, but the main side effects are stated.

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?

Four sentences, with the core purpose first and supporting behavioral details after. Each sentence adds distinct information; the 'Not a Camunda / Zeebe / LangGraph workflow' note is the only borderline sentence but is short and useful for disambiguation.

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?

The description, combined with 100% schema parameter coverage and an output schema, gives an agent enough to invoke the tool correctly. It explains the two launch modes and the run-freezing behavior; only explicit guidance on when to prefer standing-draft/commit siblings is absent, which is a minor 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 100%, so the baseline is 3. The description adds value by explaining the process/playbook_slug relationship ('board-pickup' starts at Scan) and the conditions under which playbook_slug alone is sufficient, which goes beyond the schema's field-level descriptions.

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?

The opening sentence names a specific verb ('Create'), a specific resource ('Process run'), and the two source types ('catalog process' or 'launchable playbook'). This clearly separates it from sibling process_run_* tools that advance, complete, or read runs.

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?

It explains when a run can be started without a catalog entry ('Any playbook with tool_recipe.process_steps or a skill sequence') and calls out the Board Pickup special case. It does not explicitly name alternative tools for existing runs, but the 'Create' framing and sibling names make the intended use clear.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.