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

Annotations carry the safety profile (destructiveHint=true, readOnlyHint=false, openWorldHint=true, non-idempotent), and the description adds no behavioral context beyond the metric returned. It also doesn't reconcile the tension that a description of a data-reporting endpoint sits alongside destructiveHint=true, leaving the agent with no guidance on cost, rate limits, or data freshness.

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?

One front-loaded sentence with no filler and no repetition of the title. It is efficient, though the brevity is partly why other dimensions suffer.

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?

An output schema exists, so return formatting need not be explained, but the description leaves out the date-range and grouping semantics that define this tool's behavior and does not distinguish it from the near-identical timeseries_summary and bulk new/lost siblings. For a nested-array request body behind a live endpoint, the definition is not complete enough to call confidently.

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?

The schema's top-level body parameter is undocumented (coverage 0%), and the description only gestures at 'the target field.' For a timeseries endpoint the most consequential parameters are date_from, date_to, and group_range, which determine what 'new' and 'lost' mean and how results are bucketed — none of these are surfaced in the description, so it does not compensate for the schema gap.

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 names a specific resource and metric set: number of new and lost backlinks and referring domains for a target domain. That is far more than a restatement of the title, but it offers no differentiation from close siblings such as post_dataforseo_backlinks_timeseries_summary_live or post_dataforseo_backlinks_bulk_new_lost_backlinks_live, which an agent must distinguish on its own.

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?

There is no statement of when to use this tool versus the many sibling backlink endpoints, no prerequisites, and no exclusions. The word 'timeseries' in the name suggests time-bucketed data, but the description never tells the agent to prefer this over the plain summary or the bulk new/lost variants.

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