TeamShared

process_run_create

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

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
`due_at`	No	Optional due date-time for the instance
`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)
`template`	No	Open an instance from a process template (e.g. claim). The template is frozen into the run, which starts in its first stage. Replaces process / playbook_slug.
`project_id`	No	Optional project UUID to bind this run (writes Project --runs--> Process)
`owner_agent`	No	Optional owner label for the instance
`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.
`subject_entity_id`	No	Optional ontology entity UUID the instance is about (a policyholder, a candidate). One entity can have many instances.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 15, 2026

addedInput schema / properties / due_at

Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional due date-time for the instance"
+}

addedInput schema / properties / owner_agent

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional owner label for the instance"
+}

addedInput schema / properties / subject_entity_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional ontology entity UUID the instance is about (a policyholder, a candidate). One entity can have many instances."
+}

addedInput schema / properties / template

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Open an instance from a process template (e.g. claim). The template is frozen into the run, which starts in its first stage. Replaces process / playbook_slug."
+}

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?

No annotations are supplied, so the description carries the full burden, and it does meaningful work: it discloses freeze/immutability semantics (playbook/skill versions + steps, current step, status, stream_id=run:{id}), the side effect that human/gate steps open and link a Work item, and the start stage for Board Pickup. It does not state authorization requirements, idempotency/duplicate-run behavior, or error modes.

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 verb and resource in the first clause, then layered detail in short sentences with no filler. The final negational line is slightly digressive but pays for itself as disambiguation; overall length is proportionate to a 9-parameter creation tool.

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?

With an output schema present, return values need no coverage, and the description fills the important gaps: what the run captures at creation, the Work-item side effect, and the three creation paths. For a mutation tool with zero annotations it is still missing permission/auth requirements and re-creation semantics, which keeps it off a 5.

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 description coverage is 100%, so 3 is the baseline and the description exceeds it by clarifying that process and playbook_slug are interchangeable routes to the same entry point ('process or playbook_slug=board-pickup'), which the schema does not spell out. It adds little on the other seven parameters, which the schema already documents individually.

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?

Specific verb + resource ('Create a Process run') with the three admissible sources named up front (catalog process, launchable playbook, template). The 'Not a Camunda / Zeebe / LangGraph workflow' line further pins the concept against the most likely misconception, so an agent can separate it from process_run_advance/complete/get even before reading the 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?

Gives real selection context: Board Pickup starts at Scan, and any playbook carrying tool_recipe.process_steps or a skill sequence can start a run with no catalog entry. It stops short of explicit routing against siblings (when to call process_run_advance or process_run_get instead) and states no prerequisites or failure conditions.

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

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.