unignore_ordersRestore ignored store orders to the Import list so they can be processed again using order IDs from the import orders list.
Puts ignored store orders back on the Import list.
| Name | Required | Description | Default |
|---|---|---|---|
| order_ids | Yes | Order ids from list_import_orders. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds nothing about what is mutated or the consequence — e.g. whether orders re-enter store sync, trigger re-import, or whether the prior ignore state can be recovered. For a destructive-labelled mutation this leaves the agent without the context it needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with the effect front-loaded and zero padding. It's efficient, though the brevity comes at the cost of the behavioral detail captured elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent, open-world mutation with no output schema, the description should say what happens to the restored orders and any limits or failure modes. It supplies only the state transition sentence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with 100% schema description coverage ('Order ids from list_import_orders'), so the schema carries parameter meaning. The description adds nothing about the 500-id cap, array semantics, or partial-failure behavior, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource pair ('Puts ignored store orders back on the Import list'), which is far more specific than the title. An agent can infer it reverses ignore_orders and interacts with the import queue, though it doesn't name the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, prerequisites, or alternative named. The inverse relationship to ignore_orders and list_import_orders is only inferable from the tool name; nothing states when an agent should restore orders versus leaving them ignored.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.