Creates an archive plan for Amazon Ads entities. Use to permanently archive campaigns, ad groups, or ads, knowing archiving cannot be undone; prefer pausing when possible.
Build (not apply) an archive. Archiving cannot be undone; prefer pausing.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| note | No | ||
| entity | Yes | ||
| market | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is non-read-only and non-destructive. The description adds meaningful behavioral context: the operation builds rather than applies, and archiving 'cannot be undone,' which warns about irreversibility. These statements complement the annotations and do not contradict them, so no annotation contradiction is flagged.
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?
The description is a single, tightly written sentence with the primary action and warning front-loaded. Every word contributes: 'Build (not apply)' disambiguates the action, and 'Archiving cannot be undone; prefer pausing' delivers critical caution without excess.
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 tool with four parameters and zero schema-level descriptions, this description is too sparse. It explains the overall action and irreversibility but omits parameter meanings, prerequisites, and what the planned archive output looks like. Even with an output schema present, the description does not close the gap for correct invocation.
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?
Schema description coverage is 0%, and the description provides no information about the four parameters (ids, note, entity, market). An agent cannot infer what 'ids' refers to, what entity/market mean, or how note is used. The description carries none of the burden of explaining input semantics.
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?
The description states a specific verb and resource: 'Build (not apply) an archive.' The parenthetical 'not apply' explicitly distinguishes this from the apply_plan sibling, which helps an agent separate planning from execution. However, it never defines what archiving actually entails or what 'build' produces, so it is clear but not maximally precise.
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?
The guidance is largely implied rather than explicit. 'Build (not apply)' hints that this is the planning step before apply_plan, and 'prefer pausing' offers a cautionary alternative. But it does not explicitly name sibling tools or state concrete conditions for when to choose archiving over pausing or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.