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

Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable behavioral context beyond them: the offers are 'real prices' (not estimates or placeholders), and payment is restricted to a human on the claim page. This meaningfully informs the agent that the tool is safe to call but cannot complete transactions, which is critical behavioral information.

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 tightly packed sentences cover the product tiers, their benefits, and the key human-payment constraint without any filler. The most decision-relevant details are front-loaded and every clause earns 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?

With no parameters, an output schema present, and annotations covering safety and idempotency, the description carries exactly the remaining contextual load. It explains what the offers are, what they include, and the critical human-only payment constraint, so an agent has enough to know when and how to use the tool.

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 tool has zero parameters, so there is no parameter-level semantic burden. The description still enriches the output expectations by naming the offer categories and what each provides, which helps the agent interpret results even though no input schema exists.

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?

Description states a specific verb and resource: get listing offers from SaaSCity, and names the actual offer tiers (free queue, Quick Pass, Premium). It also clarifies what each tier buys (queue position, dofollow link, launch post), making the tool's purpose unambiguous and distinct from sibling tools like get_listing or check_badge.

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?

The description clearly implies the tool is informational and tells the agent that payment cannot be completed through the API ('Only a human can pay, on the claim page'). This gives practical context for when to use it versus attempting a purchase or expecting a mutable action, though it does not explicitly name sibling alternatives or exclusion conditions.

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