kingdee_forbid_bills

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, so this is a recognized state-changing call. The description adds real value on mechanics (ExecuteOperation endpoint, opNumber must sit at the top level, data carries only business params) but says nothing about prerequisites — whether the record must be unaudited or unreferenced, what happens to transactions using the disabled master data, or permission requirements.

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?

Bullet structure and the front-loaded opNumber warning are good, but the provenance passage ('范探源 2026-08-07 三重证据查证 + QA 严过关真机实测') is justification for a human reviewer, not information an agent needs to select or invoke the tool. That line should be cut.

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?

An output schema exists, so the 'Returns' paragraph is largely redundant, and the parameter details are covered. What remains missing for a state-mutating master-data tool is the operational envelope: batch size limits on bill_ids, failure/partial-success behavior, and preconditions on record state.

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 reported at 0% for the wrapper, and while the nested ExecuteActionInput does document its properties, the description still compensates: it states bill_ids is preferred, that master data uses FNumber for bill_nos, that at least one identifier is required, and that operation can be overridden for custom 二开 forms. That last point is meaning the schema only hints at.

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 opening line names a specific verb+resource (禁用基础资料) and pins the exact operation code (opNumber=Forbid), then bounds scope to master data (BD_Customer / BD_Supplier / BD_Material / BD_Stock). That is enough to separate it from kingdee_enable_bills and from bill-level siblings like kingdee_void_bills, though no sibling is named explicitly.

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?

Explicit positive scope (only master data, with FormId examples) and explicit exclusions at the constant level (Disable deprecated, UnForbid does not exist, so don't use it). The '仅适用于基础资料' clause implicitly rules out 单据, but the description never names the reverse tool (kingdee_enable_bills) or says when an agent should prefer a bill-level action instead.

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