amazon_search_orders

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

No annotations are supplied, so the description carries the full behavioral burden, and it delivers little. It flags '(Beta)' status, which is genuinely useful, but says nothing about result limits, ranking/matching behavior, what happens on zero matches, or the shape of returned orders. The text is cut off before any of that could be covered.

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 purpose is front-loaded in a single sentence with no padding, which is the right shape. But the sentence is truncated mid-clause, so the front loading delivers an unfinished thought rather than a complete one. Length is appropriate; completeness of the sentence is not.

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 zero-parameter, no-output-schema tool, the description still must explain what comes back and how the search term is provided, and it does neither. It also ends mid-sentence, leaving the agent to guess the intended behavior. The '(Beta)' marker and the Amazon-native search framing are the only substantive content.

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?

The schema declares zero properties, so the baseline is 4, but the description actively implies an input ('a product name or word') that no declared parameter accepts. This ambiguity about how the search term is supplied is a real invocation risk. With no parameters to document, the description neither compensates for nor clarifies 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?

The description names a specific verb and resource: search the person's own Amazon order history using Amazon's own search, keyed by a product name or word. That is materially different from amazon_list_orders, so an agent can infer the distinction without opening a schema. However, the sentence is truncated ('..., ne...'), so the scope statement is incomplete and no sibling is ever named 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?

Usage is only implied: the tool is for finding orders by product name or word, as opposed to browsing. There is no explicit when-to-use/when-not-to-use statement and no mention of amazon_list_orders or amazon_get_order as alternatives, which is the natural routing decision for an agent here. The '(Beta)' prefix hints at reliability caveats but gives no operational guidance.

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