data_network_dldata_list

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

No annotations are provided, so the description carries the full behavioral disclosure burden, but it only states 'List network downlink data records.' It does not disclose pagination behavior (limit defaults to 100, offset 0), the tfield-required-with-time-filter constraint, or the read-only nature explicitly. The schema hints at these, but the description itself adds no behavioral context. There is no contradiction with annotations since none exist.

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?

A single sentence with zero filler: verb plus resource plus scope qualifiers, front-loaded and easy to parse. It is genuinely concise rather than under-specified like a pure tautology, though it is brief enough that it could have comfortably carried a bit more useful context.

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 tool with no output schema and no annotations, the description is too thin. It doesn't explain what the returned records look like, how time filtering (tfield/tstart/tend) is meant to be combined, or the pagination model. The 100% schema coverage prevents a score of 1, but an agent gets almost no operational context from the description itself.

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%, with all 11 parameters individually documented (addr, sort, tend, unit, limit, device, offset, tfield, tstart, network, profile). The description adds nothing about parameters, but at full coverage the baseline of 3 applies — the schema already does the heavy lifting.

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 ('List') and a clearly scoped resource ('network downlink data records'). The qualifiers 'network' and 'downlink' implicitly distinguish it from siblings like data_network_uldata_list (uplink) and data_application_dldata_list (application-level data). It is clear, though terse — it doesn't elaborate on what a 'downlink data record' contains.

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?

No guidance is given about when to use this tool versus alternatives such as data_network_dldata_count, data_network_uldata_list, or data_application_dldata_list. Nothing explains that this is the network-scoped downlink listing, while the uldata/count variants serve different needs. The agent must infer routing from the tool name alone.

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