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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real value: it discloses the per-product deal shape (offer, optional code, claimUrl), warns that 'exclusive' is the maker's unverified claim and must be disclosed to the user, and states that deals never affect rank. Those trust and integrity caveats are not derivable from annotations or schema.

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?

Four short sentences, front-loaded with purpose then usage trigger, then output shape and caveats. The first sentence is somewhat promotional ('that makers offer people who find their product here') and could be trimmed, but overall there is little waste.

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?

With an output schema present the description needn't explain return values, yet it usefully previews the deal fields and flags the unverified 'exclusive' claim. Combined with rich annotations and fully documented params, an agent has what it needs to call and interpret this tool correctly.

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 100%, so tag, limit, and query are fully documented in the schema itself with enum values and range/default notes. The description adds nothing about how to construct a query or choose a tag. Baseline 3 is appropriate when the schema does all the work.

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 defines the resource clearly (deals: discounts, extended trials, promo codes) and the trigger sentence ('Use when the user hunts for a deal, discount, coupon or promo code on an AI tool, app or MCP server') establishes the retrieval action. The opening phrase 'Launch deals on FastDrop' is slightly ambiguous about whether the tool launches or looks up deals, which costs it the top mark. It still distinguishes itself from siblings like search_products and find_tools by scoping to deals specifically.

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 user-intent triggers (hunting for a deal, discount, coupon, promo code) and the domain (AI tool, app, MCP server). It does not name or exclude alternative sibling tools such as search_products, so an agent must infer routing. Clear context, but no explicit when-not or alternatives.

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