Listing Bureau - Amazon Organic Ranking

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

Annotations declare readOnlyHint=true, and description confirms with 'Get' operation. Description adds valuable behavioral context by disclosing exactly what data fields are retrieved (plan label, fee, discount, wallet usage) beyond the annotation, though it omits caching or rate limit details.

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?

Single sentence, front-loaded with action verb. Parenthetical enumeration of return fields is information-dense with zero waste. Every word 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?

For a simple parameter-less read operation, description adequately compensates for missing output schema by enumering return values (plan, fee, discount, wallet usage). Minor gap: doesn't mention if this returns current subscription only or historical data.

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?

Zero parameters present, meeting baseline score of 4 per rubric. Schema is empty object with 100% coverage (vacuously true), requiring no additional parameter semantics from description.

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?

Specific verb 'Get' + clear resource 'Listing Bureau subscription info' + explicit scope differentiation via parenthetical list of returned fields (plan label, fee, discount, wallet usage), clearly distinguishing from sibling lb_account_get (general account) and lb_wallet_get_balance (wallet only).

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 implied usage context through specificity of returned data (subscription financial details vs general account info), but lacks explicit when-to-use guidance or named alternatives contrasting with lb_account_get or lb_account_get_service_rates.

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