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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely non-derivable disclosure: the email must match the one used at purchase, and it never returns addresses or payment details — a meaningful privacy boundary. It stops short of describing error behavior for failed verification.

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?

Two sentences, front-loaded with the scope-and-credential requirement, followed by return contents and the privacy exclusion. The parenthetical external-URL analogy is slightly expendable but harmless and short.

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?

No output schema exists, and the description compensates by naming what comes back (status, dates, items, tracking number) and what does not (addresses, payment details). For a two-param read-only lookup with full annotation coverage, this is nearly sufficient; only failure/not-found behavior is unaddressed.

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%, so the description carries the burden, and it does explain that 'email' means the address the order was placed with, not an arbitrary contact. 'order_number' is left as the obvious order identifier, but the pairing semantics (both must match) are stated.

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+resource (order status lookup) and the exact key it requires: order number plus the email used at checkout. This clearly separates it from the sibling list_my_orders, which enumerates orders rather than resolving one. An agent can pick between them without opening either schema.

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?

Usage is implied by the required credential pair and the reference to 'the same check as deer.supply/track', so an agent knows this is the single-order lookup. However, there is no explicit routing advice such as when to prefer list_my_orders or get_help, and no statement of what to do when the email does not match.

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