Pizza Developer

Start workflow run

start_workflow

Start a run of one workflow from an Idea, a planned existing Batch whose Work has not begun, or a new batch plan (name and ordered works, as in create_batch_plan). A workflow that starts at Delivery takes none of them: the run begins on its Start to Delivery connection, and create_delivery, or update_delivery adding a Batch, completes it. With batch, the Batch is planned and the run started in one call, its review step is skipped, and edgeId can name the Batch stage route; a retry while that run is open returns the same run. A Batch run governs that Batch's Work queue until it is ready. The run is pinned to the workflow's current revision and returns its current step. Each instruction body is sent once per run; a document already sent earlier in the run comes back as a uri reference. Inside a workflow run, rules are checked by TypeSafe, a separate provider, which receives the record, the text of each Rule, and the project context a Rule refers to.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "workflowId": "<workflowId>"
    },
    "name": "start_workflow"
  }
}

Input Schema

Name	Required	Description
`batch`	No	New Batch plan to create and start the run from.
`edgeId`	No	Batch stage route to take when the run starts from a Batch.
`ideaId`	No	Idea to start the run from.
`batchId`	No	Planned Batch to start the run from.
`projectId`	Yes	Id of the Project.
`workflowId`	Yes	Id of the Workflow.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it explains batch-run creation, skipped review step, edgeId routing, idempotent retry behavior while a run is open, and that a Batch run governs that Batch's Work queue until ready. It also discloses revision pinning, return of the current step, one-time instruction body delivery, document URI references, and TypeSafe rule evaluation by a separate provider.

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?

The description is front-loaded with the core purpose and source options, and nearly every sentence adds operational meaning. It is dense and includes several long, nested clauses, but it does not waste space on filler.

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

Completeness5/5

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

For a complex mutation tool with six parameters, nested batch objects, annotations, and no output schema, the description covers the critical missing pieces: entry modes, Delivery exception, batch semantics, retry behavior, revision pinning, current-step return, and downstream rule evaluation. An agent has enough context to select and invoke it correctly.

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 already 100%, so the baseline is 3. The description earns additional credit by clarifying the mutually exclusive source parameters (ideaId, batchId, and batch) and by explaining that edgeId names the Batch stage route and that batch creates and starts in one call.

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 description uses a specific verb and resource ('Start a run of one workflow') and enumerates the three valid starting sources: an Idea, a planned Batch, or a new batch plan. It also distinguishes the Delivery-start exception by naming create_delivery and update_delivery as the relevant alternative path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool: for starting from an Idea, a planned existing Batch whose Work has not begun, or a new batch plan. It also states when this tool does not apply — workflows starting at Delivery take none of those sources — and routes the agent to create_delivery or update_delivery adding a Batch.

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

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.

Resources

Need Help?