Pizza Developer

Create work

create_work

Create a Work in a Batch that is not ready. It always starts planned; begin_work starts it. In a workflow run, the Batch plan with the new Work is checked against the rulesets on the connection the run entered Batch on, until one of its Works is done; a Must rule that does not pass refuses the write. 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>",
      "batchId": "<batchId>",
      "title": "<title>",
      "size": "<size>"
    },
    "name": "create_work"
  }
}

Input Schema

Name	Required	Description
`size`	Yes	Work size.
`title`	Yes	Work title.
`labels`	No	Labels on the Work.
`batchId`	Yes	Id of the Batch.
`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`	No	What changes and where.

Schema Changelog

Changes observed during successful MCP inspections.

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 say non-read-only and non-destructive; the description adds real behavioral substance: rule evaluation against connection rulesets during a workflow run, that a failing Must rule refuses the write, and that TypeSafe (a separate provider) receives the record, rule text, and project context. That external-data-sharing disclosure is exactly the kind of context annotations cannot convey.

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-loads the action and initial state in the first two clauses, then adds ruleset and provider context. The workflow-run sentence is dense and syntactically tangled ("the connection the run entered Batch on"), costing some readability, but each clause carries information.

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?

Covers creation semantics, resulting state, validation behavior, and third-party disclosure for a 7-parameter mutation with no output schema. It never says what is returned on success (created Work id/shape), which is the main remaining gap given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every parameter (including the requestId idempotency contract and the size enum) is documented in the schema itself. The description adds no parameter-level meaning, which is acceptable at full coverage but is the baseline, not a value-add.

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 and resource ("Create a Work"), the pre-condition ("in a Batch that is not ready"), the resulting initial state ("always starts planned"), and explicitly names the sibling that performs the next step (begin_work). An agent can distinguish this from begin_work and create_batch_plan without opening any 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?

Clearly scopes usage to non-ready Batches and routes the 'start it' case to begin_work. It does not explicitly state what to do if the Batch is already ready (presumably use create_batch_plan or update_batch), so the exclusion is implied rather than enumerated.

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?