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

The description adds genuine behavior the annotations don't cover: it relies on existing Amazon Ads authorization, is asynchronous, and produces a tokenized download. However, it never resolves whether this single tool performs all three phases or whether reportId/documentToken are expected to come from elsewhere, leaving the agent unsure what a call returns.

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 compact sentences with no filler, but the front-loaded content is authorization plumbing rather than the tool's purpose. The most decision-relevant information (what report this produces, what the call actually does) is absent while process detail leads.

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 six undocumented parameters, no output schema, and an async/tokenized flow, the description should explain scope, the date range and granularity semantics, and what a call returns. It covers only the multi-step mechanism, so an agent cannot confidently construct or interpret a call.

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 0% across six parameters (startDate, endDate, timeUnit, detailLevel, connectionId, advertiserAccountId), so the description needed to compensate and does not. Worse, it references 'reportId' and 'documentToken', which are not parameters in the schema, actively diverting attention from the undocumented fields.

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 never states the resource being reported on; the subject ('Amazon Ads SP Audience Report') comes only from the title. It describes how the tool operates (authorization, async report flow) rather than what it produces, so an agent must infer that it generates a Sponsored Products audience report.

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 three-step sequence ('Create once, poll by reportId, then download using a documentToken') implies a workflow but gives no condition for choosing this tool over siblings such as nexscope_amazon_ads_reporting or the sp_insights_report_status/_download pair. No prerequisites or exclusions are stated.

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