tool4seller-mcp

Apply product changes

apply_product_changes

Destructive

Executes a confirmed product change plan for prices, titles, item highlights, generic keywords, bullet points, or descriptions. Requires a one-time confirmation receipt and an idempotency key. Success means Amazon accepted the submission, not that changes are live. Review Sandbox simulates execution.

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": {
      "planId": "<planId>",
      "confirmationReceipt": "<confirmationReceipt>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "apply_product_changes"
  }
}

Input Schema

Name	Required	Description
`planId`	Yes	Confirmed immutable workflow plan ID. If this call times out or disconnects, do not prepare a replacement plan: query get_workflow_plan, or retry this exact plan with the same idempotency key. An INDETERMINATE item means Amazon may have accepted the write and must be reconciled before any retry.
`idempotencyKey`	Yes	Client-generated key unique to this plan. Generate a new key for every newly prepared plan; include the planId or another random value. Reuse the exact key only when retrying apply for this same plan; never reuse it for a newly prepared plan.
`confirmationReceipt`	Yes	One-time receipt returned by confirm_workflow_plan for this exact plan. A receipt for the current plan does not confirm subsequent plans.

Output Schema

Name	Required	Description	Default
`items`	No
`planId`	No
`status`	No
`storeId`	No
`summary`	No
`planHash`	No
`policyId`	No
`warnings`	No
`createdAt`	No
`expiresAt`	No
`simulated`	No
`parameters`	No
`confirmedAt`	No
`nextActions`	No
`planVersion`	No
`continuation`	No
`workflowType`	No
`executionMode`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 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 and openWorldHint=true, but the description adds genuinely non-obvious behavior: success means Amazon accepted the submission, not that changes are live. It also discloses the one-time nature of the receipt and the need to reconcile INDETERMINATE outcomes before retrying — exactly the operational context 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 short sentences, front-loaded with the action and scope, then prerequisites, then the crucial success-semantics caveat, then the sandbox pointer. Nothing is redundant with what the annotations or schema already say at length.

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

Completeness5/5

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

For a destructive, open-world mutation tool with three required parameters and an output schema, the definition supplies the prerequisites, the idempotency/retry contract, the meaning of success, and where to test safely. The one remaining gap — return-value shape — is covered by the existing output schema.

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 100% and the parameter descriptions are unusually rich (retry rules for planId, key-reuse rules for idempotencyKey, one-time semantics for confirmationReceipt). The description repeats the receipt and idempotency requirements without adding format or syntactic detail beyond the schema, so the baseline 3 applies.

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 (executes) and a specific resource (a confirmed product change plan) and enumerates exactly which product fields are in scope: prices, titles, item highlights, generic keywords, bullet points, descriptions. That enumeration lets an agent separate it from siblings like apply_campaign_changes or apply_targeting_changes without opening a schema.

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

Usage Guidelines4/5

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

Implicitly but clearly routes the agent through the workflow: it needs a confirmation receipt from confirm_workflow_plan and a plan built by prepare_product_changes, and it points to Review Sandbox for simulation. It does not explicitly name prepare_product_changes as the alternative or state when a plan should be cancelled rather than applied, so it falls short of a full when/when-not statement.

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

All tool4seller-mcp 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?