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

Annotations already flag destructive/openWorld/non-idempotent, so the safety profile is covered. The description adds genuinely non-structured behavior: the integration is paused during the run, the push targets the LIVE marketplace, and a repeat within 5 minutes starts no new run (dedup window). It still doesn't say whether cleanup is reversible or what happens to in-flight items.

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?

A single dense sentence that front-loads the destructive scope and action, followed by the usage trigger and confirm requirement. No filler, though the mid-sentence side-effect clauses (pause, 5-minute window) are tightly packed and easy to skim past.

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, open-world, non-idempotent tool with no output schema, the definition covers the essentials an agent needs: scope, live target, pause side effect, throttle behavior, and the confirmation gate. The gap is project_id and any statement about recovery/rollback.

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 coverage is 67% and already documents confirm (including the confirm_required return) and marketplace_id. The description reinforces the confirm gate but says nothing about project_id, the one undocumented parameter, so it adds only marginal meaning beyond the schema.

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 specific verb pair (clean + resubmit) and resource (all marketplace items), plus the scope qualifier 'MARKETPLACE-wide' and target 'LIVE marketplace'. This implicitly distinguishes it from the narrower siblings (clean_marketplace_items, clean_resubmit_marketplace_items, submit_all_marketplace_items), though it never names which sibling to use for a subset.

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?

'Use this when the user asks to rebuild all listings' gives a clear trigger condition, and the confirm:true requirement spells out the prerequisite. It does not explicitly exclude the non-'all' cleanup variants, so the agent must infer that partial rebuilds belong to a sibling.

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