Gridly — AI copilot for WooCommerce

Bulk-edit products

update_products

Destructive

Changes prices, sale prices, stock, status, categories or tags for many products at once. Works in two steps: a preview shows exactly what would change (nothing is changed), then confirm=true applies it and records it so it can be undone. Always show the preview to the user and get their explicit approval before calling again with confirm=true and the preview_id. Max 500 products per change. Paid plans only. 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_products"
  }
}

Input Schema

Name	Required	Description
`ids`	No
`sku`	No
`tag`	No
`price`	No	Change the regular price.
`stock`	No	Only for products that track stock.
`store`	No	Store address or id. Leave empty if you have only one store.
`search`	No
`status`	No
`confirm`	No	Set true ONLY after the user approved the preview.
`add_tags`	No
`apply_at`	No	Only with confirm=true: apply later. Store local time, YYYY-MM-DDTHH:MM, between 5 minutes and 90 days from now.
`category`	No
`preview_id`	No	The preview_id returned by the preview call (required with confirm=true).
`sale_price`	No	percent_off = sale price is X% below the (new) regular price; clear = remove the sale.
`set_status`	No
`stock_status`	No
`add_categories`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds crucial context: a preview shows exactly what would change without applying it, confirm=true applies and records for undo. It also discloses limits (500 products, paid plan requirement) and the 5-minute-to-90-day scheduling window, none of which the annotations convey.

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-loaded with the core purpose and workflow, and most sentences carry weight. Slightly dense, with the apply_at instruction repeated in both body and schema, but overall efficient for a complex tool.

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 a destructive 17-param bulk tool with no output schema, the description covers the safety-critical workflow thoroughly. It is somewhat incomplete on how products are selected and the exact preview return shape, but the core invocation path is well covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 41%, so the description must compensate. It clarifies the most consequential params—confirm, preview_id, apply_at, and the price mode semantics—but leaves the selection mechanism (ids, sku, tag, search, store) and the distinction between status/set_status/stock_status unaddressed, leaving a meaningful gap for 17 params.

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 (bulk-edit) and enumerates the exact fields changed (prices, sale prices, stock, status, categories, tags) and the scope (many products at once). This is easily distinguishable from read-oriented siblings like find_products or top_products.

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 workflow, instructs to always show the preview and get explicit user approval before confirming, and names the scheduling alternative via apply_at. It also states hard constraints (max 500 products, paid plans only).

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?