Amazon Seller MCP Server — AgentXray

Did my changes work?

did_my_changes_work

Read-onlyIdempotent

The MEASURED outcome of changes this seller approved and applied through AgentXray: what changed, when, and what happened to conversion in the fortnight afterwards. Verdicts are deliberately conservative — at low volume 'inconclusive' is the honest answer and the reasons say exactly why (thin traffic, day-to-day swing, another change to the same listing inside the window). A change whose window has not closed yet reports status 'measuring' with the date it can first be read. Use for 'did that change work', 'was it worth it'.

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": "did_my_changes_work"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Max changes to return (default 10, max 25).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare the safe-read profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: conservative verdict logic, why 'inconclusive' is returned at low volume, and the 'measuring' status for windows that have not closed. This is exactly the behavioral nuance an agent needs to interpret results.

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?

Leads with what is measured, then qualifies verdict behavior, then gives use cases — well front-loaded. Dense but each clause (conservative verdicts, reasons, 'measuring' status) carries real information, though it runs long for a one-parameter 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?

With no output schema, the description carries the return-value burden and does so well: verdicts, the reasons behind them, status values, and dates. It could be slightly more explicit about the response shape/fields, but an agent has enough to call and interpret it.

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%, so the single 'limit' parameter (default 10, max 25) is already fully documented. The description adds no syntax or format detail beyond that, which is the correct baseline for a fully-covered schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: the measured conversion outcome of changes the seller applied, plus what changed and when. An agent can tell this is an outcome-measurement tool rather than a plain change list. It does not, however, name the obvious sibling get_my_changes to disambiguate.

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?

Gives explicit trigger phrases ('did that change work', 'was it worth it'), so the agent knows the intent this tool serves. It stops short of naming alternatives or stating when-not to use it (e.g., vs get_my_changes).

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

All Amazon Seller MCP Server — AgentXray 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?