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

With no annotations provided, the description carries the full burden and it delivers: it explains the pagination contract (complete flag, next_cursor, cursor, concatenating data), the byte-budgeted chunks, the fact that history is the only reconstructable record, and the attribution requirement. It also hints at access gating ('INFLUENCE/license plan'), which is important behavioral context.

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 description is long but every sentence earns its place: scope, dataset variants, business rationale, pagination protocol, and attribution. The critical differentiator ('WHOLE dataset, not a 100-row page') is front-loaded, and the pagination instructions are precise and actionable without excess verbiage.

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 complex bulk-export tool with no output schema and no annotations, this description is remarkably complete. It covers what each dataset contains, how pagination works, when to use it, and attribution/citation expectations. The only minor omissions are internal response field types and exact byte-budget sizes, but the description already gives enough to invoke and assemble the result correctly.

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 coverage is 75% because the dataset parameter lacks a textual description. The description richly compensates by explaining each dataset enum value in detail, including the structure of history's parallel arrays. Cursor, context, and co_brand are already described in the schema, but the description adds operational guidance for cursor and clarifies co_brand's attribution-stamping role.

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 uses a specific verb ('export') with a clear resource ('dataset') and enumerates the three exact dataset choices (ratings, providers, history) with detailed contents. It immediately distinguishes itself from 'a 100-row page', which separates it from paginated sibling tools like find_ratings and get_rating_history.

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 explicitly says the tool is 'for media outlets and analysts licensing the data to publish rankings and trends' and contrasts it with page-level output ('not a 100-row page'). It implies when to use this tool over paginated alternatives but does not name a specific sibling or state clear exclusion conditions, so it falls just short of full guidance.

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