Gridly — AI copilot for WooCommerce

Create a discount code

create_coupon

Creates a coupon (percent or fixed amount) with optional expiry, usage limits and category restriction. 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. 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": "create_coupon"
  }
}

Input Schema

Name	Required	Description
`code`	No
`store`	No	Store address or id. Leave empty if you have only one store.
`amount`	No
`confirm`	No	Set true ONLY after the user approved the preview.
`expires`	No	Last valid day, YYYY-MM-DD (valid until the end of that day).
`apply_at`	No	Only with confirm=true: apply later. Store local time, YYYY-MM-DDTHH:MM, between 5 minutes and 90 days from now.
`categories`	No	Limit to these product categories (names).
`preview_id`	No	The preview_id returned by the preview call (required with confirm=true).
`usage_limit`	No
`discount_type`	No
`minimum_amount`	No
`usage_limit_per_user`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true — they say nothing about the two-step commit protocol. The description supplies critical behavior the annotations omit: a mandatory preview/approval cycle, a preview_id that must round-trip, paid-plan gating, and the apply_at window semantics.

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?

Four tightly packed sentences with the core action front-loaded and the workflow instructions following in execution order. The final sentence is long and carries slightly overloaded conditions (confirm + preview_id + apply_at + time format + window), but nothing is redundant.

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 12-parameter mutation tool with no output schema, the description covers the risky parts (irreversibility, approval gating, scheduling window) well and references the preview_id returned by the preview call. It does not state which parameters are required or what the preview returns (e.g. predicted discount value), leaving a small gap for an agent assembling the call.

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?

With 50% schema coverage across 12 params, the description meaningfully compensates: it documents the confirm/preview_id pairing, the apply_at format and local-time basis, and the categories/expiry/usage-limit options. Gaps remain for code, store, amount, minimum_amount, usage_limit_per_user, and the meaning of the three discount_type enum values (e.g. fixed_cart vs fixed_product), which the description only gestures at.

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?

Names a specific verb and resource ('Creates a coupon') and immediately scopes the variants (percent or fixed amount) plus optional features (expiry, usage limits, category restriction). No sibling tool covers coupon creation, so no differentiation is needed, and an agent can identify the tool's function from the first clause alone.

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 a workflow: preview first, show the preview to the user for explicit approval, then call again with confirm=true and preview_id. It also names the alternative path ('to apply it later instead of now, call with confirm=true, the preview_id AND apply_at') and a hard eligibility gate ('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?