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

Beyond the readOnlyHint/destructiveHint/openWorldHint annotations, the description discloses rich behavioral traits: the exact ledger adjustment codes read (M/5, F/N, E/6, H/K/7/U, D), the reimbursement report types consulted, the returned status values (recent_wait_auto | claim_now | deadline_passed), the 60-day claim deadline, and the throttling/retry semantics. It also clarifies that the claim cannot be opened via API, preventing a false expectation of a write action.

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 dense and front-loaded with the core question and READ-ONLY marker, and each subsequent section (inputs read, outputs returned, usage triggers, operational caveats, exclusions) earns its place for a tool of this complexity. It is slightly run-on and includes some parenthetical code lists that could be tightened, but there is no redundant filler.

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?

Given the absence of an output schema, the description fully specifies the returned per-SKU fields (units lost/found/damaged/disposed, already-reimbursed units and amount, amazon_open_units with event date, deadline, status, estimated value). It also covers operational edge cases (async delay, throttling, claim channel) and explicitly scopes out adjacent concerns (customer-return refunds, inbound discrepancies), making it complete enough to invoke correctly without further discovery.

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 100%, so the baseline is 3. The description adds the rationale for choosing one outpost per seller (the ledger covers the whole region), but provides no additional syntax, formatting, or constraint detail for sku, days, limit, or only_open beyond what the input schema already documents.

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 names a specific verb and resource (reads the inventory ledger and reimbursements report, returns per-SKU lost/damaged/reimbursed balance) and distinguishes itself from siblings by explicitly referencing fba_inbound_discrepancies as out of scope. It also names the category of tools it replaces (ZoneWizard, Igolai, Getida), giving an agent an immediate mental model.

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?

It gives explicit use-case triggers in English and Italian ('unità perse / danneggiate / non rimborsate', etc.), states the outpost-selection rule, points to where the actual claim is opened (Seller Central, no public API), and names what is not covered. The async-report guidance ('first call may take 60-90s; REPORT_THROTTLED = retry in 60s') directly tells the agent how to behave when the tool is invoked.

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