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

Annotations only give readOnlyHint=false and openWorldHint=true, so the description should carry most of the burden. It does disclose scope modifiers that affect results (historical month window, multi-dimensional sorting) and what dimensions come back, but it says nothing about rate limits, result caps (the 2000-record ceiling exists only in the schema), or why a 'Query' tool is flagged non-read-only. Note the mild tension: 'Query' implies a pure read while readOnlyHint=false signals possible side effects; I treat this as a metadata inconsistency rather than a deliberate contradiction, but the description does not resolve it.

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 purpose clause is correctly front-loaded in the first sentence, but the trigger sentence degenerates into keyword stuffing ('Nexscope traffic keyword, Amazon traffic keywords, reverse ASIN keywords') where several listed phrases are near-duplicates. The substance fits in half the length.

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 an 11-parameter, no-output-schema tool the description usefully enumerates the returned dimensions so the agent knows what a call yields. It omits, however, any treatment of pagination behavior, the 2000-record ceiling, or the meaning of the filter enums referenced in the schema, leaving gaps an agent will hit on real use.

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 description coverage is 100% across 11 parameters, so the schema already carries the syntax baseline. The description loosely maps its vocabulary onto parameters ('traffic source type', 'conversion type', 'organic rank, ad rank' for sorting, 'historical month'), which helps an agent connect intent to fields, but it adds no format or constraint detail beyond what the schema states.

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 verb+resource: 'Query traffic keyword lists for an Amazon ASIN', and enumerates what the payload contains (traffic source type, conversion type, organic rank, ad rank). It is clear what the tool does, but it never distinguishes itself from close siblings such as nexscope_amazon_asin_keywords, nexscope_amazon_asin_traffic_summary, or nexscope_data_ss_traffic_keyword, so an agent facing those alternatives gets no disambiguation.

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 trigger sentence is a genuine usage guide: it lists the user phrasings ('ASIN reverse traffic keywords', 'keyword traffic structure', 'reverse ASIN keywords') and explicitly removes the vendor-name precondition ('even if Nexscope is not explicitly mentioned'). However, there is no when-NOT-to-use clause and no named alternative for the aggregate-vs-list or keyword-vs-ASIN cases, which are the two realistic mis-routing risks here.

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