Pizza Developer

Create workflow

create_workflow

Create a named workflow: a route of stages that requests in the project follow. name is unique in the project; description says which requests it handles. Nodes are Start, optional Idea, Batch, optional Delivery, optional Workflow (the step that improves the Workflow itself after a run), and Finish. Start can connect to an existing Batch without Idea, and Batch can connect to Workflow or Finish without Delivery. Start can also connect to Delivery, for a workflow that only creates or adds to a Delivery: Start to Delivery to Finish, or Start to Delivery to Workflow to Finish, with no Batch node. Each edge.data must contain instructionDocumentIds (existing project document IDs) and contextKinds (features and/or dictionary; each adds only a short outline, top-level feature names or dictionary words, that the agent expands with the read tools). edge.data may also carry rulesetIds, an ordered list of the project's ruleset IDs attached to that connection; leaving it out attaches none. Select documents on connections; do not create Instructions, Dictionary, or Features nodes or put text on lines. Projects work without a Workflow.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Workflow name, unique in the Project.
`edges`	Yes	Connections between stages, each with its Instructions, context kinds, and Rulesets.
`nodes`	Yes	Workflow stages.
`projectId`	Yes	Id of the Project.
`requestId`	No	Optional unique ID for this create. After a timeout, retry with the same requestId and arguments: the record already created is returned instead of a duplicate.
`description`	Yes	Which requests this Workflow handles.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 9, 2026

addedInput schema / properties / edges / items / additionalProperties
```
Added value: +{}
```

addedInput schema / properties / edges / items / properties

Added value: +{
+  "data": {
+    "additionalProperties": {},
+    "properties": {
+      "contextKinds": {
+        "description": "Outlines added on this connection.",
+        "items": {
+          "enum": [
+            "features",
+            "dictionary"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "instructionDocumentIds": {
+        "description": "Ids of the Project's Instructions sent on this connection.",
+        "items": {
+          "minLength": 1,
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "rulesetIds": {
+        "description": "Ordered ids of the Rulesets checked on this connection.",
+        "items": {
+          "minLength": 1,
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "instructionDocumentIds",
+      "contextKinds"
+    ],
+    "type": "object"
+  },
+  "id": {
+    "description": "Connection id, unique in the Workflow.",
+    "minLength": 1,
+    "type": "string"
+  },
+  "source": {
+    "description": "Id of the node the connection leaves.",
+    "minLength": 1,
+    "type": "string"
+  },
+  "target": {
+    "description": "Id of the node the connection enters.",
+    "minLength": 1,
+    "type": "string"
+  }
+}

addedInput schema / properties / edges / items / required

Added value: +[
+  "id",
+  "source",
+  "target",
+  "data"
+]

addedInput schema / properties / edges / items / type
```
Added value: +"object"
```
addedInput schema / properties / edges / maxItems
```
Added value: +8
```
addedInput schema / properties / nodes / items / additionalProperties
```
Added value: +{}
```

addedInput schema / properties / nodes / items / properties

Added value: +{
+  "data": {
+    "additionalProperties": {},
+    "properties": {
+      "resourceKind": {
+        "description": "Stage this node stands for.",
+        "enum": [
+          "start",
+          "idea",
+          "batch",
+          "delivery",
+          "workflow",
+          "finish"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "resourceKind"
+    ],
+    "type": "object"
+  },
+  "id": {
+    "description": "Node id, unique in the Workflow.",
+    "minLength": 1,
+    "type": "string"
+  },
+  "position": {
+    "description": "Position on the canvas.",
+    "properties": {
+      "x": {
+        "type": "number"
+      },
+      "y": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "x",
+      "y"
+    ],
+    "type": "object"
+  }
+}

addedInput schema / properties / nodes / items / required
```
Added value: +[
+  "id",
+  "position",
+  "data"
+]
```
addedInput schema / properties / nodes / items / type
```
Added value: +"object"
```
addedInput schema / properties / nodes / maxItems
```
Added value: +6
```

First observedOct 3, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only tell the agent this is a non-read, non-destructive write. The description goes well beyond that, disclosing what gets created, the semantics of omitted fields ('leaving it out attaches none'), and how context is materialized ('each adds only a short outline... that the agent expands with the read tools'). This is rich behavioral context the annotations cannot supply.

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 purpose and organized from general concept to node kinds to edge rules. Dense but every sentence carries structural information; a few long compound sentences could be trimmed, but nothing is filler.

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 complex graph-construction tool with no output schema, the description covers the valid stage topologies, required edge payloads, and prohibitions thoroughly. It does not describe the return value or idempotency behavior (left to the schema's requestId), but the calling contract is otherwise complete.

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 nonetheless adds semantic depth, explaining that edge.data must carry instructionDocumentIds and contextKinds, that rulesetIds is an ordered per-connection list, and that contextKinds only add outlines — meaning beyond the terse schema text.

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+resource ('Create a named workflow') and immediately defines what a workflow is ('a route of stages that requests in the project follow'), so an agent understands the artifact rather than just the operation. The detail on node kinds and edge contents further distinguishes it from generic create_* siblings.

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?

Provides strong construction guidance ('do not create Instructions, Dictionary, or Features nodes', 'Select documents on connections') and notes that 'Projects work without a Workflow', implying optionality. However, it never states when to reach for this versus update_workflow/start_workflow or list_workflows, leaving the tool-selection decision implicit.

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

All Pizza Developer tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?