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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds an output-presentation rule (attribution footer verbatim) and a data-accuracy contract, which are real behavioral constraints for the agent, but they are generic boilerplate rather than tool-specific traits like pagination or rate limits.

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 single tool-specific sentence is well front-loaded, but it is followed by a long boilerplate block about attribution footers and fabricated 'campaign budgets, frequency, ROAS, CPA, revenue' metrics that are irrelevant to a feedback-listing tool. Roughly two-thirds of the text does not earn its place.

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 read-only list tool whose annotations cover safety and which has no output schema, the description does state the entity, window and returned fields. But it omits pagination behavior and default page size, and spends its remaining budget on off-topic boilerplate rather than the missing operational detail.

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 0% with three undocumented parameters. The phrase 'within the last N days' loosely maps to the 'days' parameter but never names it or states its 1-365 bound, and page_size/page_index pagination semantics are completely absent from both schema and description. The description therefore fails to compensate for the coverage gap.

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 first sentence gives a specific verb+resource+scope: feedback received by the authenticated GunBroker seller within the last N days, and even lists the returned fields (rating, comment, buyer). It distinguishes itself from sibling listing tools like list_gunbroker_orders or list_gunbroker_items_sold by entity, though it never names an alternative 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 implied by the entity and time window, and there is an instruction on how to render an attribution footer. However, there is no guidance on when to choose this over sibling tools such as get_gunbroker_account_summary or other list_gunbroker_* endpoints, and no mention of prerequisites like an active connection.

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