kingdee_query_transfer_apply

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description does not add significant behavioral detail beyond confirming it is a query returning a JSON list. The description mentions return type ('str: JSON 格式的调拨申请单列表') but does not discuss pagination behavior (though schema defines limit/start_row) or other nuances.

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 concise and well-structured: first sentence states purpose, then business context, then bullet-pointed filter examples, then recommended field keys, then return type. Every sentence adds value, and the use of examples is efficient.

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 description covers the tool's purpose, business context, usage patterns, and return format. With an output schema present, it is not required to detail return values. However, it implicitly assumes the form_id parameter should be 'STK_TransferApply' but does not explicitly tell the agent to set that value, which is a minor omission given the parameter is 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?

The input schema already describes all parameters with individual descriptions, so schema coverage is high. The description adds value by providing concrete examples for filter_string and field_keys, showing common usage patterns (e.g., '已审核: FDocumentStatus='C'') that go beyond the schema's generic descriptions.

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 it queries a list of transfer applications (调拨申请单), identifies the specific form (STK_TransferApply), and explains the business context (starting point for transfer, can be pushed to direct or step transfer). This distinguishes it from sibling tools with similar names like kingdee_query_transfer_direct or kingdee_query_stock_transfer_apply.

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 practical usage guidance with multiple example filter strings and recommended field keys, showing how to filter by document status, date range, warehouses, and close status. However, it does not explicitly contrast with alternative query tools or state when to use this tool over others.

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