ads_dump

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

The description discloses behavioral traits far beyond the readOnly/destructive annotations: POINTER/REFERENCE/INTERFACE values are addresses and never expanded, arrays >4096 elements or values >64 KiB are shown as {not_expanded, bytes, elements, head_hex}, large symbols are read in 256 KiB pieces, and the bounding semantics of max_leaves/max_total_mb are defined precisely (nothing estimated, row written only when it still fits). It also explains the complete=false contract with skipped_roots and failed_roots and the not_on_target reporting, so an agent knows exactly what partial or missing results look like.

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 and dense, but it is front-loaded with the core purpose and every subsequent sentence adds a concrete, non-redundant behavioral fact (expansion limits, chunk size, bounding rules, partial-result contract). Given the tool's genuine complexity, the length is mostly justified, though a few clauses (e.g. the byte-accounting aside) could be tightened.

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 whole-PLC dump with five parameters, zero schema coverage and an output schema already present, the description supplies everything an agent needs: what is read, how it is bounded, what is excluded and what a truncated or failed run looks like. Return values are additionally previewed despite the output schema, which is more than required.

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 0%, so the description carries the full burden, and it does so for four of five parameters: pattern syntax and root-limiting behavior is shown with examples, include_system default effect is stated, and both max_leaves (CSV+JSON leaves together) and max_total_mb (MiB, on-disk CSV+JSON only, PLC bytes excluded) are defined in a way the schema cannot convey. out_dir is the one gap — never explained even implicitly as the destination for the two files.

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?

States a specific verb and resource with explicit scope: reads EVERY variable on the PLC (all top-level symbols, fully expanded) in one pass and emits both a flat CSV and a nested JSON tree. This is clearly distinguishable from siblings like ads_read, ads_read_many, ads_list_symbols and ads_export, all of which imply narrower or differently-shaped output.

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?

Usage context is implied through scope statements (one-pass whole-PLC dump, pattern to limit roots, ordering behavior with/without a project) but it never explicitly says when to pick this over ads_export, ads_read_many or ads_list_symbols, nor does it name an exclusion condition for those alternatives. An agent can infer the 'dump everything' case but must decide unassisted whether a narrower sibling is more appropriate.

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