Gridly — AI copilot for WooCommerce

Save new product text

apply_product_content

Destructive

Saves new names, descriptions or short descriptions you (the AI) have written for specific products. Call get_brand_voice first and follow the user's saved style. Preview first (shows before/after), then confirm. Always show the preview to the user and get their explicit approval before calling again with confirm=true and the preview_id. Paid plans only. SEO title and meta description are saved in Yoast SEO's format (or Rank Math's if the product already uses it). 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": "apply_product_content"
  }
}

Input Schema

Name	Required	Description
`items`	No
`store`	No	Store address or id. Leave empty if you have only one store.
`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.
`preview_id`	No	The preview_id returned by the preview call (required with confirm=true).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The annotations already declare destructiveHint=true and openWorldHint=true, but the description adds critical workflow context: this is a mutation requiring preview and explicit user approval, and SEO fields are saved in Yoast or Rank Math format. It does not fully clarify whether omitted item fields leave existing content untouched, but the preview/confirm model and destructive annotation together give adequate safety context.

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?

The description is front-loaded with purpose and then gives the operational workflow in a logical order. It is dense and occasionally repetitive around preview and confirmation, but every sentence carries useful procedural information for a multi-step mutation.

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?

Given a five-parameter mutation tool with no output schema, the description covers the essential workflow, plan restriction, SEO formatting, and scheduling behavior. It does not describe the preview response beyond before/after and preview_id, but it provides enough for correct invocation.

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 80%, and the schema already documents store, confirm, apply_at, and preview_id. The description adds meaningful semantics beyond that: it explains the preview-confirm workflow, that preview_id comes from the preview call, that apply_at uses store-local time in YYYY-MM-DDTHH:MM, and that meta_title/meta_description follow SEO plugin formatting.

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?

The description opens with a specific verb and resource: saves new names, descriptions, or short descriptions for specific products, and clarifies that this is for text the AI has written. This distinguishes it from generic update_products by scoping it to AI-authored product content, so an agent can select it without opening the schema.

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 explicitly states the required sequence: call get_brand_voice first, preview before/after, show the preview to the user, obtain explicit approval, then call again with confirm=true and preview_id. It also states paid plans only and how to schedule later application with apply_at, leaving no ambiguity about when and how to use the tool.

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?