kingdee_download_attachment

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

Beyond the annotations, the description discloses the return format (Base64 file_part), confirms no local file is written, explains the chunk continuation loop, and warns not to concatenate Base64 strings directly but to decode each chunk and concatenate bytes in order. This is substantial operational context that annotations alone do not provide.

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 purpose and non-local-file behavior are front-loaded, followed by concise procedural notes for pagination and byte assembly. Every sentence is actionable and directly relevant to correct invocation.

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?

The tool has an output schema, so return structure need not be exhaustively described. The description still supplies the essential chunking loop, return value meaning, and byte-concatenation rule, leaving no material gap for an agent to call 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?

The description adds critical meaning to file_id by distinguishing the upload-returned FileId from the attachment internal code, and it explains start_index usage across first and subsequent calls. Even though the reported schema coverage is 0%, the description compensates fully for both parameters.

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 states a specific verb and resource: download one attachment chunk via WebAPI V6.0, returning Base64 file_part without writing a server-local file. This is clearly distinguishable from sibling tools such as kingdee_upload_attachment, and the chunked-download purpose is unambiguous.

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?

It gives explicit invocation guidance: start with start_index=0, continue using the returned start_index while is_last=false, and stop when next_action=null. It also warns that file_id must be the upload-returned FileId rather than attachment_ids. It does not explicitly name when to choose a different sibling tool, but the download context is otherwise clear.

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