ugreen_read_file

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds substantive behavior beyond that: a hard 256 KiB per-call cap, continuation via offset, and encoding selection. What is missing is whether a truncated read is signaled and how the caller learns the file ended.

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?

Four short clauses, front-loaded with the core action and its size bound, then the usage restriction. No filler; the only soft spot is the final sentence, which is vague about what 'the corresponding file' means.

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?

With no output schema and zero schema description coverage across four parameters, the description should say more about the return shape — specifically whether the response indicates truncation or EOF so the agent knows when to stop issuing offset reads. It covers the reading mechanics well but leaves that loop-termination question open.

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 0%, so the description must carry the load, and it partially does: it explains encoding semantics (UTF-8 default, base64 for binary) and the role of offset for continuation. It does not explain the length parameter or its 65536 default, and the 256 KiB figure is stated as a cap rather than tied explicitly to length.

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+resource: a bounded read of a NAS file, with the default UTF-8 and base64-for-binary behavior. This distinguishes it from write_file, delete_file, and file_stat, though it never names a sibling explicitly and leaves the boundary with download_file implicit.

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 one usage condition — only when the user requests that specific file — which is a real constraint on when to call it. However, no alternative is named (e.g., when to prefer download_file or file_stat), and the offset-continuation pattern is described mechanically rather than as a decision rule.

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