Gridly — AI copilot for WooCommerce

Update an order

update_order

Destructive

Changes an order's status and/or adds a note (private, or visible to the customer). Preview first, then confirm. Always show the preview to the user and get their explicit approval before calling again with confirm=true and the preview_id. Refunds must be done in WooCommerce itself. To apply it later instead of now, call with confirm=true, the preview_id AND apply_at (the store's local time, YYYY-MM-DDTHH:MM).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_order"
  }
}

Input Schema

Name	Required	Description
`note`	No
`store`	No	Store address or id. Leave empty if you have only one store.
`status`	No
`confirm`	No	Set true ONLY after the user approved the preview.
`apply_at`	No	Only with confirm=true: apply later. Store local time, YYYY-MM-DDTHH:MM, between 5 minutes and 90 days from now.
`order_id`	No
`preview_id`	No	The preview_id returned by the preview call (required with confirm=true).
`note_to_customer`	No	true = the customer is emailed the note.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true; the description goes further by disclosing the irreversible-looking confirm gate, the requirement to surface a preview to the user for explicit approval, and the fact that refunds are out of scope. These are real behavioral constraints an agent cannot infer from the annotations.

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

Conciseness5/5

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

Four compact sentences, front-loaded with what changes, then the safety protocol, then the exclusion, then the scheduling variant. No redundant restatement of the name or title.

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 the mutation, the approval protocol, the refund exclusion, and scheduling for an 8-parameter destructive tool with no output schema. The one gap is that it never states plainly that calling without confirm returns the preview containing preview_id, leaving the agent to infer how to obtain one.

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 63%, and the description adds the crucial relational semantics the schema cannot express: preview_id and confirm must be used together, and apply_at pairs with confirm=true. It also clarifies that the note can be private or customer-visible, tying to note_to_customer. It does not explain status transitions or order_id expectations, so it is not exhaustive.

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 (changes) plus resource (an order) and enumerates the two mutable facets: status and/or note. This clearly separates it from read-only siblings like get_order and find_orders without needing to name them.

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?

Explicitly prescribes the two-step flow (preview, then confirm with preview_id) and the human-approval gate, and explicitly excludes a related action by saying refunds must be done in WooCommerce itself. It also names the scheduling path via apply_at, so the when/when-not is unambiguous.

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

All Gridly — AI copilot for WooCommerce 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?