Skip to main content
Glama

Pizza Developer

by com.pizzadeveloper
OverviewDiscussionsAdmin

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDelivery name, a free-form label such as 2.4.0.
metricsNoOptional client measurements, stored on the workflow step this call completes.
summaryYesFactual summary of what shipped.
batchIdsNoUndelivered Batches to include.
projectIdYesId of the Project.
requestIdNoOptional 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.
shippedAtNoShip date, as an ISO date or date-time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • 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"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations mark it as a non-destructive, open-world write, and the description goes well beyond that: it explains workflow-stage completion semantics ('completes the run's Delivery stage'), that a batch-less delivery never completes that stage, the refusal behavior, and the backfill mode. It doesn't cover post-creation visibility/permissions of the public page, but the mutation semantics are richly disclosed.

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?

Purpose is front-loaded and each sentence carries a distinct rule (backfill, default ship-now, stage completion, refusal). It is dense with long, clause-heavy sentences that could be split for readability, but little is padding.

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 seven-parameter mutation with nested metrics and no output schema, the description supplies the conditional behaviors that determine correctness: stage-completion coupling with workflows, the refusal case, and backfill semantics. Nothing essential to a correct call is missing.

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, but the description adds real meaning beyond the schema: name is a free-form label (release number common but optional), summary must be factual, and critically the shippedAt/batchIds interaction (omit batchIds + pass real past shippedAt for pre-toolship releases). metrics and requestId are left entirely to the schema.

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?

Opens with a specific verb+resource+scope: 'Create a shipped public delivery from selected undelivered batches.' It is immediately distinguishable from siblings like update_delivery, delete_delivery, create_batch_plan, and start_workflow, and clarifies that batches must be undelivered and unclaimed by another delivery.

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 names explicit modes and exclusions: normal creation from batchIds, the historical-backfill path (omit batchIds and pass shippedAt), the default 'ships now' behavior, and the refusal condition when the project has a Delivery-starting workflow and the call is made outside a run. An agent can pick the right invocation path without inference.

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

All Pizza Developer toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep 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.

Resources