Listing Bureau - Amazon Organic Ranking

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

While annotations declare readOnlyHint=true, the description adds valuable context about data sources accessed ('Fetches current rates and wallet balance'), computed outputs ('total cost, daily averages, and wallet sustainability'), and operational constraints ('SFB is US-region only', 'lower execution rate outside US') that annotations do not cover.

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 sentences with zero waste. Front-loaded with purpose ('Estimate campaign cost'), followed by behavior, input patterns, and constraints. Each sentence delivers distinct, non-redundant information without verbosity.

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?

Given the complex parameter interdependencies (7 params, alternative input modes, regional constraints) and absence of an output schema, the description comprehensively covers what is calculated and returned ('total cost, daily averages, and wallet sustainability'). It adequately addresses the tool's complexity without requiring additional structured fields.

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?

With 100% schema coverage, the baseline is 3. The description elevates this by explaining semantic relationships: the mutual exclusivity of uniform volumes versus schedule arrays, the dependency of retail_price on SFB usage, and the validation logic between region and SFB eligibility. These interdependencies are not evident from the schema alone.

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 opens with a specific action ('Estimate campaign cost') and scope ('before committing'), clearly distinguishing this from sibling tools like lb_wallet_get_balance (simple retrieval) or lb_projects_create (mutation). It defines the computational nature of the tool versus raw data access.

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?

Provides explicit guidance on mutually exclusive input patterns ('either uniform daily volumes... or a per-day schedule array') and conditional requirements ('Include retail_price for accurate SFB costs', 'Pass region to validate SFB eligibility'). Lacks explicit sibling comparisons ('use X instead'), but clearly defines when specific parameters are required.

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