Growwer MCP server

Deliver an order

growwer_deliver_seller_order

DestructiveIdempotent

Delivers an accepted seller order to the buyer for review by submitting the published post URL with publication confirmation, or a link addition without one.

Instructions

Use this when a seller has published an accepted order: delivers a post order with the URL of the post and publicationDateConfirmed, and a link addition with neither, for the buyer to review.

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": {
      "id": "<id>",
      "requestId": "<requestId>"
    },
    "name": "growwer_deliver_seller_order"
  }
}

Input Schema

Name	Required	Description
`id`	Yes
`url`	No	The URL of the published post. It is checked to be a URL without `<` or `>`, as the web does; whether the post carries the links is not checked here.
`requestId`	Yes	Required. A new UUID for each distinct write (8 to 128 letters, digits, ".", "_", ":" or "-"). Calling the tool again with the same requestId and arguments returns the first result without writing twice; send a new one for a new write.
`publicationDateConfirmed`	No	Must be true. Confirms the post is live, or for an order with a scheduled publication date, that it will be published on that date.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 30, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is carried by structured data. The description adds real value by disclosing the conditional shape of the payload ('with the URL ... and publicationDateConfirmed' vs 'with neither'), but it says nothing about the irreversible state change implied by destructiveHint or what delivery does to the order lifecycle.

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?

A single sentence with the trigger front-loaded, so it is compact and leads with the actionable condition. But the clause 'a link addition with neither' is dense and requires the reader to resolve 'neither' back to two previously named parameters, costing a re-read.

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

Completeness3/5

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

For a destructive, idempotent mutation with no output schema, the description covers the precondition and payload shape but omits consequences: what delivery commits, whether it can be undone, and what the buyer-review state means for subsequent calls. Adequate to invoke, thin for predicting effects.

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 75% and the schema descriptions are already detailed (including idempotency semantics for requestId). The description still adds genuine meaning by tying url and publicationDateConfirmed to the order mode, which the schema does not express. With 'neither' left ambiguous about which parameters it refers to, it stops short of a 5.

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 ('delivers') and resource ('seller order') and even splits behavior by order type: post orders take the post URL plus publicationDateConfirmed, link additions take neither. That is more than a restatement of the name, but it never distinguishes itself from close siblings like growwer_deliver_seller_order_update or growwer_deliver_seller_order_draft.

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

Usage Guidelines3/5

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

'Use this when a seller has published an accepted order' gives a clear triggering condition, so the agent knows the precondition. However, there is no explicit statement of when NOT to use it and no routing to the near-identical sibling tools (deliver_seller_order_update, deliver_seller_order_draft), leaving the alternative selection to inference from names.

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

Deploy Server