kingdee_get_fields

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral context: '会调用金蝶 QueryBusinessInfo 接口拉取真实字段定义（带缓存）' (calls Kingdee API with caching). It also explains the output structure and field format, which is beyond annotations. No contradictions.

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 well-structured: purpose, usage guideline, API call info, returned fields list, field format explanation. It is somewhat long but every sentence adds value. The important info is front-loaded. Could be slightly more concise, but still effective.

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 tool's complexity (returning multiple structured elements including fields, entries, required fields, save_template), the description fully covers what the agent needs to know. It explains the output format and field naming conventions. An output schema exists but is not shown; the description compensates well. For a read-only, idempotent tool with good annotations, this is complete.

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 contains clear descriptions for each parameter (form_id, entry_key, verbose). The description adds value by explaining the return content and field format notation (FXxx, FXxx.FName, FXxx.FNumber), which helps with usage. However, it doesn't add significant meaning beyond the schema for the parameters themselves.

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 '获取指定表单的完整字段信息和业务规则' (get complete field info and business rules for a specified form). It uses specific verbs ('获取', '调用') and distinguishes from siblings (which are about querying or mutating records, not metadata). The title and description align perfectly.

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 explicitly says '不知道查询哪些字段时，或需要了解表单的业务限制时，先调用此工具' (when unsure which fields to query or need to understand business rules, call this tool first). This provides clear context for use. While it doesn't list when not to use, the guidance is sufficient.

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