Pizza Developer

Create delivery

create_delivery

Create a shipped public delivery from selected undelivered batches: batches no other delivery carries, including ready Batches of several finished workflow runs. Supply its name (a free-form label; a release number like 2.4.0 is common but not required) and a factual summary. To record a release that shipped before the project used Pizza Developer, omit batchIds and pass shippedAt, the real past ship date (ISO date or date-time); without shippedAt it ships now. A delivery without batches never completes a workflow run's Delivery stage. In a run of a workflow that starts at Delivery, any ready Batches no delivery carries can go in, and the call completes the run's Delivery stage. When the project has a workflow that starts at Delivery, create_delivery outside a workflow run is refused and the refusal names that workflow. It publishes to the Public Delivery Page and its feed, so publish must be true, set only when the vibe coder asked to publish this Delivery. 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>",
      "name": "<name>",
      "summary": "<summary>",
      "publish": "<publish>"
    },
    "name": "create_delivery"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Delivery name, a free-form label such as 2.4.0.
`metrics`	No	Optional client measurements, stored on the workflow step this call completes.
`publish`	Yes	True only when the vibe coder asked to publish this Delivery.
`summary`	Yes	Factual summary of what shipped.
`batchIds`	No	Undelivered Batches to include.
`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.
`shippedAt`	No	Ship date, as an ISO date or date-time.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

addedInput schema / properties / publish

Added value: +{
+  "const": true,
+  "description": "True only when the vibe coder asked to publish this Delivery.",
+  "type": "boolean"
+}

changedInput schema / required

Previous value: -[
-  "projectId",
-  "name",
-  "summary"
-]New value: +[
+  "projectId",
+  "name",
+  "summary",
+  "publish"
+]

Changed3 schema fields changedOct 9, 2026

addedInput schema / properties / name

Added value: +{
+  "description": "Delivery name, a free-form label such as 2.4.0.",
+  "minLength": 1,
+  "type": "string"
+}

removedInput schema / properties / version

Removed value: -{
-  "description": "Version label, such as 2.4.0.",
-  "minLength": 1,
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "projectId",
-  "version",
-  "summary"
-]New value: +[
+  "projectId",
+  "name",
+  "summary"
+]

First observedOct 3, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write and external-visibility profile is partly covered. The description adds real value beyond that: it publishes to the Public Delivery Page and its feed, publish must be literally true, batchless deliveries never complete a run's Delivery stage, and rule text plus project context is sent to a separate provider (TypeSafe). It does not describe the returned record shape, but for a mutation with annotations that is a tolerable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the batchIds/shippedAt rule are front-loaded, and nearly every sentence carries unique constraints, so little is wasted. However, the whole definition is a single dense paragraph that interleaves workflow-stage semantics, refusal behavior, publishing, and third-party rule evaluation, making it hard to scan and easy for an agent to miss a clause.

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 an 8-parameter, nested-object mutation with no output schema, the description covers the important call-time decisions: which batches are eligible, when to backfill with shippedAt, the publish gate, and workflow-run interaction. The only missing piece is any hint of the returned record (only obliquely referenced via the requestId retry note), which matters slightly given no output schema exists.

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 still earns extra by attaching intent to specific parameters: shippedAt must be the real past ship date (not a placeholder), publish is set only when the user asked to publish, and batchIds must contain batches no other delivery carries. metrics and requestId semantics are left to the schema, which is acceptable given full coverage.

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 first sentence names a specific verb (Create), a specific resource (shipped public delivery), and the exact input scope (selected undelivered batches, including ready batches from several finished workflow runs). That is enough to distinguish it from update_delivery, delete_delivery, list_deliveries, 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 Guidelines5/5

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

It spells out the alternative paths: supply batchIds for a normal ship, omit batchIds and pass shippedAt to backfill a pre-adoption release, omit both to ship now. It also states the refusal condition when a Delivery-starting workflow exists and explains the in-workflow-run case, so the agent knows when the tool will be rejected and why.

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?