list_manual_compound_entry_files

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

Annotations already declare this as a safe, read-only, idempotent operation, so the description does not need to repeat that. It adds minimal context by identifying the resource as 'files of manual compound entry', but it does not disclose any additional behavioral traits like pagination behavior, response format, or whether file metadata vs. content is returned. The description is consistent with annotations.

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 a single concise sentence with no filler or redundancy. It efficiently conveys the core purpose without wasting words, though it could be slightly clearer with proper grammar ('files of the manual compound entry'). This is appropriately sized for a simple list operation.

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?

Given the simple nature of the operation, the presence of robust annotations and a fully described schema, the description is minimally sufficient. However, it lacks details about the response structure (no output schema) and does not clarify the difference between manual compound entries and regular manual entries, which is relevant given sibling tools. These gaps prevent higher completeness.

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 input schema provides 100% coverage for all three parameters (limit, offset, manual_entry_id) with clear descriptions. The tool description itself adds nothing about parameter meanings or usage, only indirectly implying that manual_entry_id is the target identifier. Since the schema fully documents the parameters, a baseline score of 3 is appropriate.

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 clearly states the action ('Fetch') and the resource ('files of manual compound entry'), which distinguishes it from related tools like 'get_manual_compound_entry_file' and 'list_manual_entry_files'. However, it does not explicitly differentiate itself from all sibling tools, and the phrase 'manual compound entry' is not defined, leaving some ambiguity about the exact entity type.

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?

The description provides no guidance on when to use this tool versus alternatives, such as 'get_manual_compound_entry_file' for fetching a single file or 'list_manual_entry_files' for regular manual entries. There is no mention of prerequisites, exclusions, or context for choosing this list operation over others.

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