vivid-ads-commerce

Estimate delivery timing

vivid_delivery_estimate

Read-onlyIdempotent

Estimate WHEN an order would arrive at an Australian postcode — the question behind 'can I get it by Friday?'. Works the timeline through honestly: production starts only after the customer approves their digital proof (3pm Melbourne time cut-off), then the QUANTITY-based production time (1–15 items → 1 working day, 16–40 → 2, 41–100 → 3, 101–200 → 4, 201+ → the team sets the date), then transit for their postcode (metro/regional/remote bands). Returns an arrival WINDOW plus the assumptions it made. This is an ESTIMATE, never a guarantee — always relay the caveat, and for a hard deadline tell them to call 1300 721 614. Free pickup from Derrimut VIC is usually the fastest option.

Input Schema

Name	Required	Description
`product`	No	product name — used to read its real production time
`postcode`	Yes	4-digit Australian delivery postcode
`quantity`	No	how many identical items — turnaround depends on it (default 1)
`artwork_ready`	No	true if artwork is print-ready and the proof will be approved immediately

Output Schema

Name	Required	Description
`status`	Yes	outcome discriminator, e.g. ok / priced / need_size / manual_quote / unknown_product / error
`message`	No
`quantity`	No
`agent_note`	No
`turnaround`	No	quantity-aware ready-to-dispatch: { ready_to_dispatch, approve_by, working_days, basis: tier\|provisional, sentence }
`production_hours`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 24, 2026

addedInput schema / properties / quantity

Added value: +{
+  "description": "how many identical items — turnaround depends on it (default 1)",
+  "type": "number"
+}

addedOutput schema / properties / quantity
```
Added value: +{}
```

addedOutput schema / properties / turnaround

Added value: +{
+  "description": "quantity-aware ready-to-dispatch: { ready_to_dispatch, approve_by, working_days, basis: tier|provisional, sentence }"
+}

Changed1 schema field changedOct 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "agent_note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "message": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "production_hours": {},
+    "status": {
+      "description": "outcome discriminator, e.g. ok / priced / need_size / manual_quote / unknown_product / error",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status"
+  ],
+  "type": "object"
+}

AddedJul 19, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare it as a safe read; the description adds the real behavioral model — proof-approval dependency, 3pm Melbourne cut-off, quantity bands (including the 201+ manual case), postcode transit bands, and that it returns a window plus assumptions. It also flags the estimate-vs-guarantee caveat the agent must relay.

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 core question, then the timeline mechanics, then the caveat. Dense but every sentence carries decision-relevant information; slightly long but not padded.

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?

Return values are covered by an output schema, so the description rightly focuses on the causal timeline and edge cases. An agent has everything needed to call it and to caveat the result 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 coverage is 100%, so baseline is 3; the description still adds meaning by spelling out the quantity-to-production-day mapping and that postcode determines metro/regional/remote transit bands. Product and artwork_ready semantics are left mostly to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Estimate WHEN an order would arrive at an Australian postcode') and anchors it in a real customer question. It doesn't name the sibling vivid_delivery_quote, which likely overlaps, so an agent must infer the distinction.

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?

Gives clear triggering context ('can I get it by Friday?') and routes hard deadlines to a phone alternative (1300 721 614). It stops short of an explicit when-not-me vs. vivid_delivery_quote or vivid_price.

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

All vivid-ads-commerce 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?