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

Annotations indicate non-destructive, non-idempotent operation. The description adds context by specifying the state change and return structure (success=true, next_action=null). No contradiction 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 extremely concise: two sentences and a returns line. It is front-loaded with the action and result, with no superfluous text.

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 simplicity (auditing bills) and the presence of an output schema, the description is mostly complete. However, it could mention batch processing (multiple bill_ids) and any error conditions.

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 description does not describe the parameters. The input schema provides minimal descriptions in Chinese, but with schema description coverage at 0%, the tool description fails to add any meaning beyond the schema.

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 verb (audit) and resource (bills), with a status transition (待审核 → 已审核). It distinguishes from sibling audit tools like kingdee_audit_production_orders and kingdee_unaudit_bills.

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 implies usage for auditing bills but does not explicitly state when to use this tool versus alternatives like kingdee_submit_bills or kingdee_create_and_audit. No when-not-to-use or prerequisites are mentioned.

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

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

Annotations indicate non-readonly, non-destructive, non-idempotent. Description adds return format but no behavioral details like required state or side effects. Adequate but minimal.

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?

Extremely concise, one line for action and one for return. Front-loaded with action. Could add context without much verbosity.

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?

Minimally complete for a simple audit tool. Lacks explanation of prerequisites, error handling, or meaning of success. Output schema exists but not shown.

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 provides descriptions for form_id and bill_ids. The tool description adds no further meaning. Schema descriptions are sufficient but could be more detailed.

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 verb '审核' (audit) and the resource '生产订单（PRD_MO）'. It distinguishes from siblings like kingdee_submit_production_orders and kingdee_audit_bills by specifying the exact resource.

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?

No guidance on when to use this tool versus alternatives like kingdee_audit_bills or kingdee_submit_production_orders. No prerequisites or context provided.

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

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

Goes well beyond the annotations: names the actual endpoint used (standalone CancelAssign, no opNumber), the fallback path (ExecuteOperation + top-level opNumber when operation is overridden), and the payload shape ({"Ids":"1,2,3"}). Annotations already cover safety profile (destructiveHint=false, idempotentHint=false), and nothing in the text contradicts them, though batch partial-failure behavior is unstated.

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?

Purpose and parameters are front-loaded, but a large share of the text is provenance meta-commentary ('范探源 2026-08-07 三重证据查证', '反编译', 'QA 严过关…真机验证 B→D 成功') that does not help an agent decide or invoke. The 'old docs said Cancel, don't cite it' note addresses a document the agent does not have.

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?

Output schema exists, so return values need not be described, and the tool's core invocation contract (form scope, id/number targeting, endpoint, override) is covered. Missing pieces are permission requirements, multi-bill partial-success semantics, and any note on irreversibility — relevant for a state-rollback mutation.

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?

Outer schema coverage is effectively 0% (a single opaque 'params' wrapper), so the description must compensate — and it does: bill_ids as FID list with priority, bill_nos as FBillNo fallback, the at-least-one rule, and when operation must be supplied explicitly. It adds real semantics beyond the nested schema, though it does not elaborate on form_id beyond examples already in the schema.

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 states a specific verb and resource ('撤销单据或基础资料'), scopes the operation to draft/in-approval state rollback, and pins the concrete action (CancelAssign) and generic FormId scope. It is distinguishable from most siblings conceptually, though the description never names void/close/delete explicitly as different operations.

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 a state precondition ('草稿/审批中状态回退') and a parameter rule (bill_ids or bill_nos, at least one), plus an override path for 二开 forms. But with siblings kingdee_void_bills, kingdee_close_bill, kingdee_delete_bills, kingdee_forbid_bills all being state-changing actions on the same FormId, the description never says when to pick cancel versus those alternatives.

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

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

Goes well beyond the annotations by disclosing the endpoint (ExecuteOperation), that opNumber goes at the top level while data holds only business params, the resolution precedence for the operation code, and the explicit Chinese error returned when metadata matching fails. It omits whether repeated close calls are idempotent or what permissions are needed, but the resolution-failure behavior is genuinely useful for a mutation tool.

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 first line is well front-loaded, but the body carries provenance noise ('范探源 2026-08-07 三重证据查证 + QA 严过关真机实测') and a defensive rationale for why it is a generic tool, neither of which helps an agent invoke it. Roughly a third of the text could be cut without information loss.

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?

For a mutation tool the description covers action resolution, parameter precedence, error behavior, and target form applicability. An output schema exists, so return values need not be explained further; the remaining gap is idempotency and preconditions (must be audited and not already closed) which are only obliquely implied.

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?

Although the flattened schema coverage signal reads 0% (the real parameters are nested under params/$ref), the description adds real semantic content: form-specific opNumber examples per form_id, the 'explicit operation > metadata Chinese-name matching' precedence, and the bill_ids-over-bill_nos priority rule. This meaningfully compensates for the nested schema.

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?

States a specific verb and resource in the first clause — '整单关闭单据（已审核单据业务关闭）' — and scopes it to audited bills across named form types (销售订单、采购申请单、发货通知单). It never explicitly names kingdee_unclose_bill as the reverse operation, so sibling differentiation is implied by the 反关闭 mention rather than stated.

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?

Gives the admissibility condition ('已审核单据', 'bill_ids 或 bill_nos 至少一个') and notes the tool is generic across form types, but gives no explicit when-not guidance and does not route the agent to kingdee_unclose_bill, kingdee_cancel_bills, or kingdee_void_bills. Usage is inferable rather than prescribed.

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

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

The description discloses key behavioral traits: it stops on first failure without auto-retry, returns halted_at and recovery_hint, and logs a single entry (op='create_and_audit'). It also mentions that any step failure gives a recovery hint. Annotations already mark destructiveHint=false and readOnlyHint=false, and the description adds context on failure handling and logging compression, but does not address idempotency (idempotentHint=false) or clarify if the tool always creates vs. updates.

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. The first sentence immediately communicates the core functionality. It uses bullet points for failure behavior and clearly separates the return format. Every sentence adds value without redundancy.

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 (three-step workflow), the description fully covers the workflow, failure modes, recovery hints, logging behavior, and return format. The input schema provides parameter details, and the description explains the return JSON structure. No gaps remain for an AI to successfully invoke the tool.

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 description does not add any parameter semantics beyond what the input schema already provides. The schema itself includes descriptions for form_id, model, need_update_fields, and is_delete_entry. Since schema description coverage from the description text is 0%, but the schema already sufficiently describes 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 tool performs three sequential steps (Save, Submit, Audit) in one call, preventing the AI from missing intermediate steps. It distinguishes itself from the manual chain of sibling tools kingdee_save_bill, kingdee_submit_bills, kingdee_audit_bills by offering a combined, error-reduced path.

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 defines when to use this tool ('明确要一条龙创建并使单据生效，没有中间审批/校验需求') and when not to, providing an alternative manual chain. This gives clear guidance for correct selection.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=false, so the safety profile is covered; the description adds real value on top by disclosing the four-step pipeline, the non-obvious constraint that WebAPI push drops business fields for these bill types, the is_delete_entry=false trick that preserves _LK linkage, and the fail-fast contract (halt + halted_at + recovery_hint). It does not spell out permission requirements or that repeated calls create duplicate bills despite idempotentHint=false.

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?

Front-loaded with the one-line summary, then background, then a numbered workflow, then the return contract — each block earns its place and the failure behavior is not buried. No filler or repetition of the schema.

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?

For a complex 4-step mutation an agent has what it needs: preconditions (source bill type per kind), the pipeline stages, partial-failure semantics, and a return contract that overlaps the existing output schema rather than replacing it. The remaining gap is the wrapper 'params' envelope and any auth/rule prerequisites (enable_default_rule / rule_id implications).

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 description enumerates several business fields it will write (amount / material / qty / so_no) and ties them to the save step, which is useful orientation. However the top-level schema exposes a single undocumented 'params' wrapper (0% coverage), and the description never explains that all inputs are nested under 'params' or how kind selects which optional fields apply — the agent must read the nested $defs to learn the receipt-vs-payment field split.

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 first line names the exact resources (TRNV_Receipt / TRNV_PaymentSlip) and the exact composite operation (push → save → submit → audit), which is far more specific than a generic 'create bill'. The background section explains why this exists versus plain push, but it never names the sibling alternatives (kingdee_push_bill, kingdee_push_and_audit, kingdee_create_and_audit) it overlaps with, so the differentiation is inferred rather than stated.

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 clear context for when this is the right tool: 二开收/付款单 destined for 账套初始化 / 在途收付款数据, where a bare push would leave 金额/物料/SONo empty. The auto_audit=False case is explicitly framed as the '导入后人工核对' scenario. Missing are explicit exclusions or a pointer to the generic push/create-and-audit tools for non-二开 bill types.

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

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

The description discloses the critical behavioral trait: only draft status can be deleted; other statuses require prior unaudit. This adds value beyond the destructiveHint annotation by explaining the state dependency. The return format is also described, but permissions or error handling are not covered.

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 with 4 lines, front-loading the key usage condition. The return description is slightly redundant but does not waste words.

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 state dependency and output schema existence, the description covers the main behavior and return format but omits details on partial success, error handling, or prerequisites beyond status. It is adequate but not thorough.

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 description does not mention the required parameters (form_id and bill_ids), and schema coverage is 0%. The schema itself has descriptions, but the tool description adds no parameter semantics, leaving the agent to rely solely on the schema.

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 tool deletes bills, specifying the resource (bills) and action (delete). It distinguishes from sibling tools like audit or submit by adding the condition that only draft documents can be deleted directly, while submitted/approved ones need unaudit first.

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 states when this tool can be used (only for draft documents) and implies the alternative (unaudit) for non-draft documents. However, it does not name the specific sibling tool (kingdee_unaudit_bills), leaving the agent to infer the prerequisite.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns a table structure string but does not disclose any additional behavioral traits such as potential performance impacts or authentication requirements. With annotations covering safety, the description adds minimal value.

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 with a clear summary, usage scenarios, and useful common prefixes. It is concise for the amount of information conveyed. Slightly verbose due to the prefix list, but that is valuable context.

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 tool has one parameter, annotations cover safety, and the description provides usage guidance and additional context on table naming conventions. The return type is mentioned but without an output schema, it's slightly incomplete. Overall adequate for a simple read-only tool.

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 provides a description for the single parameter 'table_name', including an example. The tool description does not add further semantic detail about the parameter. With schema description coverage at 0% (likely meaning the tool description doesn't cover parameters), the baseline of 3 applies.

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 tool's purpose: viewing a table's complete structure including column names, types, nullability, and defaults. It explicitly distinguishes this from sibling tools like kingdee_discover_tables (which lists tables) and kingdee_get_fields (which gets fields differently), though not by name.

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 specific usage scenarios: when you know the table name, before writing SQL or data modeling, and to confirm field types. It also gives common table prefixes for context. However, it does not explicitly mention when not to use this tool or alternatives among siblings.

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

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

Annotations declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds valuable context: only reads system catalog, no business data, and specifies return structure (table name, column name, data type, nullable). No contradiction.

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?

Extremely concise: one-line summary followed by bullet-point use cases. No redundancy, front-loaded with key information. Every sentence adds value.

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?

For a simple search tool, the description covers purpose, usage, behavior, and return format. With annotations providing safety guarantees, it is fully 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 schema provides detailed descriptions for both parameters (pattern and limit). The description adds no new parameter info but reinforces their purpose through use cases. Given schema coverage, a 4 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 it searches SQL Server column names by keyword, explicitly limiting to system catalog only. It distinguishes from sibling `kingdee_discover_tables` which likely searches tables.

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?

Provides concrete use cases (finding a field, confirming column names, verifying mappings) that illustrate when to use. Could explicitly mention alternative tools for table search, but the guidelines are practical and clear.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds context about being a helper tool for Kingdee/K3, providing mapping examples and return type. No contradictions (description states discovery, not mutation). Could disclose case sensitivity or limitation, but overall good.

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?

Description is well-structured with purpose, examples, scenarios, and return type. Front-loaded with main action. Could be slightly shorter by merging redundant parts, but clarity benefits from examples.

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 complexity of form_id-to-table mapping, the description is thorough: explains mapping logic, provides common examples, and lists use cases. Output schema exists, so return values need no further explanation. No significant gaps.

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 descriptions already cover both parameters. Description adds value by providing valid form_id examples and clarifying default behavior (empty returns all). Reinforces schema info. For limit, no extra detail, but schema is sufficient.

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?

Description clearly states the tool's purpose: discovering database tables corresponding to a form_id or prefix. It provides specific examples and distinguishes from siblings by focusing on form_id-to-table mapping, unlike other discovery tools like kingdee_discover_tables or kingdee_discover_columns.

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?

Explicitly lists applicable scenarios (knowing which table corresponds to a form_id, exploring related tables, understanding mapping). Does not mention alternatives or when not to use, but given the context and sibling names, it's clear that this tool is for mapping discovery. A mention of siblings would improve it.

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

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

Annotations already indicate read-only, non-destructive, idempotent. The description adds that it queries only system catalog (not business data) and specifies the return format (table names, types, creation time). This adds value beyond 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 very concise: a single sentence for the action, a bullet list for use cases, a line for scope, and a return type indication. No wasted words, and the most important info is front-loaded.

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?

For a simple discovery tool, the description covers purpose, usage scenarios, scope, and return format. It also references a complementary sibling tool. Combined with annotations and schema descriptions, it provides sufficient context for an AI agent.

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 descriptions for both parameters (pattern and limit). The tool description implicitly references pattern via 'keywords' but does not mention limit or provide additional parameter context. Since schema coverage is high, baseline 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 tool's purpose: searching SQL Server table names containing keywords, scoped to system catalog only. It specifically distinguishes from sibling tools by mentioning complementary use with kingdee_discover_columns.

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 use cases are provided (e.g., finding tables related to 'purchase', quick name location) and guidance to combine with kingdee_discover_columns. Scope and limitations (only system catalog, no business data) are clearly stated.

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

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

Beyond the annotations, the description discloses the return format (Base64 file_part), confirms no local file is written, explains the chunk continuation loop, and warns not to concatenate Base64 strings directly but to decode each chunk and concatenate bytes in order. This is substantial operational context that annotations alone do not provide.

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 purpose and non-local-file behavior are front-loaded, followed by concise procedural notes for pagination and byte assembly. Every sentence is actionable and directly relevant to correct invocation.

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 tool has an output schema, so return structure need not be exhaustively described. The description still supplies the essential chunking loop, return value meaning, and byte-concatenation rule, leaving no material gap for an agent to call and assemble the result correctly.

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 description adds critical meaning to file_id by distinguishing the upload-returned FileId from the attachment internal code, and it explains start_index usage across first and subsequent calls. Even though the reported schema coverage is 0%, the description compensates fully for both parameters.

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 and resource: download one attachment chunk via WebAPI V6.0, returning Base64 file_part without writing a server-local file. This is clearly distinguishable from sibling tools such as kingdee_upload_attachment, and the chunked-download purpose is unambiguous.

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 explicit invocation guidance: start with start_index=0, continue using the returned start_index while is_last=false, and stop when next_action=null. It also warns that file_id must be the upload-returned FileId rather than attachment_ids. It does not explicitly name when to choose a different sibling tool, but the download context is otherwise clear.

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

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

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false), yet the description still adds real value: ExecuteOperation endpoint, opNumber=Enable at the top level while data carries only business params, and the return key naming (fid/ids, not id). It does not address behavior when the record is already enabled, which matters given idempotentHint=false.

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 bullet layout is front-loaded and scannable, but the line 'action 依据：范探源 2026-08-07 三重证据查证 + QA 严过关真机实测' is internal provenance noise that does not help an agent invoke the tool and consumes a full bullet.

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?

For a parameterized generic action tool this covers what an agent needs: domain restriction, action code, endpoint/placement convention, parameter precedence, override mechanism, and which return fields to read. The presence of an output schema means return values need not be fully specified.

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 reported at 0%, so the description has to carry the load, and it does: bill_ids as an FID list (preferred), bill_nos as FNumber for master data, mutual exclusivity rule, and the operation override for custom actions. The form_id parameter's constraint is conveyed only by example (BD_* forms), and the outer params wrapper is never explained.

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?

States a concrete verb+resource (反禁用基础资料, action=Enable) and bounds the scope to master data (BD_Customer / BD_Supplier / BD_Material / BD_Stock), explicitly rejecting single-form specialization. An agent can tell it apart from the many per-document action tools, though it never names its direct counterpart kingdee_forbid_bills.

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?

Gives a clear exclusion (仅适用于基础资料, not ordinary bills) and a precondition (bill_ids or bill_nos, at least one, with bill_ids preferred), plus an escape hatch: pass operation explicitly for customized master data. It stops short of naming the inverse tool (kingdee_forbid_bills) or stating the required source state (must currently be forbidden).

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

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.

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that: the output is a pre-verified static skeleton, placeholders use the <...> convention, and unsupported form_ids yield a prompt rather than an error. It does not describe caching or freshness of the template, which is the only notable gap.

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?

Purpose and return content are front-loaded, followed by the usage tactic and the supported-value list. Four short lines with almost no waste; the only slight redundancy is repeating the placeholder concept after already describing the sample model.

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 an output schema present, return shape needs no full explanation, and the description still characterizes it well. For a single required parameter with rich annotations, the definition covers purpose, allowed values, and next-step validation; only template staleness/versioning is unaddressed.

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% — form_id has no description or enum — so the description must carry the full burden, and it does: it enumerates the three supported values (SAL_Quotation / SAL_SaleOrder / PUR_PurchaseOrder) and explains the fallback behavior for any other value.

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?

States a specific verb and resource (获取单据的「已验证 model 骨架」模板) and spells out exactly what the return contains: correct field names, required fields, required entry-line fields, and a model sample with placeholders. It also names the concrete form_ids it serves, so an agent can distinguish it from sibling field/query tools without opening the schema.

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 establishes a clear workflow: use placeholders like <客户编码>, substitute business data, skip field exploration, and validate with kingdee_validate_bill before saving. It also notes that unsupported forms return a hint. It stops short of explicitly contrasting itself with kingdee_get_fields or kingdee_list_forms, so the when-not context is implied rather than stated.

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

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.

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral context: it returns a JSON list with specific fields (form_id, name, description, recommended fields, database table name) and explains behavior for empty keyword (returns all common forms). No contradictions 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 concise with four sentences, front-loading the purpose. Every sentence adds value: main purpose, usage instruction, examples, and return format. No wasted words.

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 simplicity (one parameter, readOnly), the description covers all needed context: when to use, input examples, return fields, and annotations cover safety. With output schema existing, the description is fully adequate.

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 describes the 'keyword' parameter, so coverage is high. The description adds concrete examples (e.g., '员工' returns BD_Empinfo) that illustrate the mapping, enhancing semantic understanding beyond the schema's description.

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 searches for available form types in Kingdee system, which is distinct from sibling tools that query records or other entities. The examples and instruction to use this tool when form_id is unknown differentiate it from others.

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 to call this tool when form_id is unknown, providing a clear usage context. It also gives examples of inputs and outputs. However, it does not explicitly state when not to use it or mention alternatives, though the context is strong.

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

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

The description provides extensive behavioral details beyond annotations: it explains the full flow (push draft, then submit+audit), failure handling (stop on error, single log entry), and the effect of auto_submit_audit. No contradiction 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 concise (5 lines in Chinese) with front-loaded purpose. Every sentence adds value, and the structure flows logically from purpose to behavior to parameter option and return type.

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 (multi-step, 7 parameters), the description covers purpose, behavior, failure handling, parameter options, and return structure. It is complete for an agent to correctly select and invoke the tool.

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?

While the schema already describes each sub-parameter, the description adds context for auto_submit_audit (equivalent to pure push) and the return structure. However, it does not enhance understanding of other parameters beyond the schema; baseline 3 is appropriate given high schema coverage.

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 defines the tool as a one-stop flow of Push plus optional Submit and Audit, distinguishing it from siblings like kingdee_push_bill (pure push) and kingdee_audit_bills (audit only). It specifies the verb 'push_and_audit' and the resource 'target bills', with scope details.

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 explains when to use this tool vs alternatives by noting that setting auto_submit_audit=False makes it equivalent to kingdee_push_bill, and it mentions failure behavior (stop on any step). However, it does not explicitly list when not to use it or provide comprehensive alternatives.

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

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

The description discloses that the tool creates target documents (write operation, consistent with readOnlyHint=false) and is not destructive (consistent with destructiveHint=false). It explains conversion rule behavior, failure handling (draft_on_fail), and response structure. It adds context beyond annotations, though idempotency is not mentioned.

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 with sections for common scenarios, conversion rules, limitations, and response. It is front-loaded with the main action. However, it is lengthy and could be slightly more concise without losing essential information.

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 presence of an output schema and input schema with descriptions, the description covers conversion rules, limitations, and response fields. It lacks explicit mention of idempotency or error types, but overall provides sufficient context for an agent to use the tool correctly.

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?

While the description does not have a dedicated parameter section, it adds value by illustrating parameter usage with examples (e.g., form_id values) and explaining nuanced behaviors like when to set rule_id explicitly or enable_default_rule=true. The input schema already provides descriptions, so the description's contribution is moderate but useful.

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 that the tool pushes source documents to target documents with specific examples. It identifies the action (下推) and the resource (单据). However, it does not explicitly differentiate from sibling push tools like kingdee_push_production_pick, which are more specialized.

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 detailed guidance on when to use default rule, enable_default_rule, or explicit rule_id. It also lists conditions under which push fails (e.g., linked quantity exceeds order quantity) and required document states (已审核, not closed). It does not compare to alternative tools but provides clear when-not scenarios.

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

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior. The description adds the return format (JSON with success/target_bill_nos/next_action). However, it does not elaborate on error handling, side effects, or the draft_on_fail parameter's effect beyond the schema.

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 very concise (one sentence plus return note) and front-loads the purpose. It contains no unnecessary words, but it omits important details, making it slightly under-specified.

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 has three parameters and no output schema, the description is incomplete. It lacks usage guidelines, parameter explanations, and behavioral details beyond the basic purpose. The return format is mentioned but not fully explained.

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 description does not explain any parameters. The input schema has three properties (bill_nos, rule_id, draft_on_fail) with some descriptions in Chinese, but context indicates schema_description_coverage is 0%, meaning the tool description should compensate. It fails to add meaning, e.g., it does not clarify that 'bill_nos' refers to production order numbers.

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 tool's function: '从生产订单下推生成生产领料单' (push from production orders to generate production pick materials). It specifies the verb (generate/push) and resource (production pick material list), and the tool is distinct from siblings like 'kingdee_push_production_stock_in' or 'kingdee_push_stock_transfer'.

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 vs. alternatives (e.g., other push tools). It does not mention prerequisites, scenarios, or when not to use it.

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

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

Annotations indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), but the description adds minimal behavioral insight beyond the return format (JSON with success, target_bill_nos, next_action). It does not disclose idempotency, partial failure behavior, or authorization requirements, relying heavily on 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 extremely concise: one sentence for the core purpose and one sentence for the return value. It is front-loaded with the primary action, contains no extra words, and is well-structured for quick parsing.

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 (multiple parameters, push workflow) and the absence of an explicit output schema, the description is too sparse. It omits prerequisites (e.g., valid material requisition state), error handling, and relationships to other tools, leaving significant gaps in the agent's understanding of proper usage.

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 description does not mention any parameters, and schema description coverage is 0%. Although the input schema itself describes parameters (bill_nos, rule_id, draft_on_fail), the description must compensate for low coverage but fails to add any semantic context about how or why to use them.

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 tool's purpose: pushing from production material requisition to generate a production stock-in order. It uses a specific verb-resource combination ('从生产领料单下推生成生产入库单') and distinguishes itself from sibling tools like kingdee_push_bill and kingdee_push_production_pick by focusing on the specific stock-in document 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 kingdee_push_bill or kingdee_push_stock_transfer. It lacks explicit context about prerequisites, typical scenarios, or exclusion criteria, leaving the agent to infer usage solely from the tool's name and purpose.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, and the description discloses the behavior: it creates a direct transfer order from a transfer application. It explains the conversion rules (default vs explicit rule) and the response fields, providing full transparency beyond 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 well-structured with bullet points for parameters and conversion rules. It is slightly lengthy but efficiently explains required details. The main action is front-loaded.

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 has 5 parameters, annotations, and no output schema (but a textual return description), the description covers all necessary aspects: purpose, parameters, conversion logic, and return format. It is complete for the tool's complexity.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter: fixed form IDs, source_bill_nos as a list, rule_id options, enable_default_rule, and draft_on_fail. This adds substantial meaning beyond the generic schema 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 specifies the action ('下推' push down) and the specific resources ('调拨申请单' to '直接调拨单' with fixed form IDs). It distinguishes from sibling tools like kingdee_push_bill by targeting stock transfer specifically.

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 explains parameters and conversion rules but does not explicitly state when to use this tool vs alternatives (e.g., kingdee_push_bill or kingdee_push_production_pick). The context of stock transfer is implied but not contrasted with other push operations.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by stating the return format (JSON list of approval flows) and warning that data may be stored across multiple forms, which indicates potential complexity in data retrieval.

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 moderately concise, with a clear opening statement followed by bullet points and a note. It front-loads the core purpose and efficiently conveys usage guidance. Some redundancy exists (e.g., repeating 'approval' in multiple bullet points), but overall it remains actionable without excessive verbosity.

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 presence of a detailed input schema and an output schema (as per context signals), the description covers the essential aspects: purpose, usage scenarios, a caution about data source, and return format. It does not detail error handling or exhaustive examples, but it is adequate for understanding what the tool does and when to use it.

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 comprehensive descriptions for all parameters (e.g., form_id, bill_id, status, dates, pagination). The tool description does not add additional parameter semantics beyond what the schema already provides. With full schema coverage, baseline score 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 specifies the tool's function: querying approval flow records in Kingdee Cloud Star. It outlines the complete approval trajectory including nodes, personnel, times, results, and opinions. The recommended scenarios (approval tracing, process optimization, compliance checks) further clarify the purpose and distinguish it from sibling query tools.

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 explicit usage scenarios (approval tracing, process optimization, compliance checks) and includes a note advising to use kingdee_get_fields if no results, offering a fallback. While it lacks direct 'when not to use' instructions, the context and sibling tool names (e.g., kingdee_query_bills) imply the tool is specifically for approval flows.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the kind of data queried and providing operational hints (filter examples, field keys). 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 concise and front-loaded with purpose. It includes extra helpful info (recommended field keys) without being verbose. Minor lack of structure (e.g., no sections) but still 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?

Given the existence of an output schema and rich annotations, the description covers purpose, usage, and important hints. It does not explain return values (handled by output schema) or sorting/pagination (in input schema). Fairly complete for a query tool.

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 provides descriptions for all parameters. The description adds specific examples for filter_string and field_keys relevant to asset cards, but does not cover all parameters. Schema coverage from description is partial; baseline 3 is appropriate since schema handles the rest.

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 tool queries asset cards (FA_FAGet or sub-documents) and explains what an asset card contains (original value, depreciation, net value, status). It provides specific filter and field key examples, distinguishing it from sibling tools like kingdee_query_asset_depreciation or kingdee_query_asset_transfer.

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 gives examples for filter_string and field_keys but does not explicitly state when to use this tool vs alternatives or any exclusions. Usage is implied through examples, but without explicit guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context about the nature of depreciation records but not additional behavioral traits like pagination, rate limits, or specific authorization needs.

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?

Three sentences covering purpose, explanation, and examples. Concise but the second sentence could be merged with the first for even tighter structure.

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 presence of an output schema and rich annotations, the description provides sufficient context for a query tool. It covers core usage with examples, though additional details on ordering or pagination could be beneficial.

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?

Though the input schema already describes parameters well (high coverage), the description adds value with concrete filter_string examples and recommended field_keys specific to this tool, helping the agent craft effective queries.

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?

Description clearly states it queries asset depreciation records (FA_DepreciationBill) and explains what they represent. The tool name and sibling context (e.g., query_asset_card, query_asset_scrape) make it distinct, though explicit differentiation is missing.

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?

Provides useful filter_string and field_keys examples, indicating when to use the tool, but lacks explicit guidance on when not to use it or how it compares to sibling query tools for other asset types.

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

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

The description discloses that the tool is read-only and query-based, aligning with annotations (readOnlyHint=true). It adds domain-specific context about asset scrap types and provides practical filter and field examples, which goes beyond the annotation's binary flags.

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: a clear opening sentence, a brief domain explanation, and bullet-like examples. Every sentence adds value, and the most important information is front-loaded.

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 output schema exists, the description need not cover return values. It includes domain-specific knowledge and query examples. However, it lacks explicit guidance on when to use this tool over siblings, which slightly reduces 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 already includes descriptions for all parameters, so the baseline is 3. The description adds value by providing concrete examples of filter_string values and recommended field_keys, which aids the agent in constructing effective queries.

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 asset scrap orders ('查询资产报废单') with the specific form ID FA_Scrape, and explains the domain context (disposal of fixed assets, including normal and early scrapping). This is a specific verb+resource that distinguishes it from other asset-related query tools.

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 common filter_string examples and recommended field_keys, which gives usage context for query construction. However, it does not explicitly differentiate when to use this tool versus sibling tools like kingdee_query_fixed_asset or kingdee_query_asset_card.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no new behavioral traits beyond the context of querying asset transfers. It does not disclose pagination behavior or other operational details not covered by 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?

Extremely concise: two short paragraphs with bulleted examples. Every sentence earns its place, and the key information is front-loaded. No wasted words.

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 presence of an output schema and standard query pattern, the description is largely complete. It covers purpose, key parameters with examples, and entity meaning. Minor gap: no mention of pagination limits or default ordering, which are in the schema but not highlighted.

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?

Although schema description coverage is 0% per signal, the description provides concrete examples for filter_string and field_keys, adding value beyond the generic schema descriptions. This helps agents craft effective queries, though it does not cover all parameters like order_string or pagination.

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?

Clearly states '查询资产调拨单' (query asset transfer orders) and identifies the resource as 'FA_Transfer'. Explains the nature of asset transfers, distinguishing it from sibling tools that query other asset-related records like asset cards or fixed assets.

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?

Provides practical examples of filter_string and recommended field_keys, aiding usage. However, it does not explicitly state when to use this tool versus alternatives like kingdee_query_asset_card or kingdee_query_fixed_asset, nor does it mention when not to use it.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not required to repeat these. It adds context by explaining the data fields and return format, but does not disclose any additional behavioral traits (e.g., rate limits, authentication needs), which is acceptable given the 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 well-structured: first states the main purpose, then details what the log records, followed by recommended scenarios, and finally return field descriptions. It is concise without being terse, though slightly longer than necessary.

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 (many parameters) and the presence of annotations indicating read-only, the description covers the core purpose, usage scenarios, and return fields. It explains the intent and data structure, making it sufficient for an agent to understand when and how to use it.

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 detailed descriptions for all parameters (100% coverage), so the description does not need to add parameter details. The description lists return fields, which is helpful but not directly related to parameters. Baseline score 3 applies as schema coverage is high.

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 name 'kingdee_query_audit_log' and title '查询审计日志' directly state the action and resource. The description specifies that it queries audit logs from Kingdee Cloud Star (BOS_AuditLog), clearly distinguishing it from sibling tools like approval flow or pending approvals by focusing on audit trail data.

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 explicit recommended scenarios: compliance audit, problem investigation, and responsibility tracing. However, it does not explicitly state when not to use this tool or mention alternatives, which would improve clarity for an AI agent.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond that: base-data forms lack an FID column and the tool silently strips FID from fields and sorting, returning a 'notice' field when this degradation occurs (#28). This is exactly the kind of automatic-behavior disclosure an agent needs; only rate limits/field-validation behavior is missing.

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?

Front-loaded with purpose and supported operations, then examples, then the FID caveat, then returns. Each paragraph carries distinct information; only the example list is slightly long relative to its value.

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 partly redundant but still usefully names the has_more/notice fields. Combined with the FID degradation note and form_id examples, an agent has enough to call this correctly; the main remaining gap is routing guidance against the many one-entity query siblings.

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 top-level 'params' wrapper has no description (0% coverage on the counted parameter), but the nested QueryInput properties are fully documented in the schema itself. The description contributes the form_id example values and the FID-removal caveat that affects the field_keys and order_string defaults, but says nothing extra about filter_string syntax or ordering format beyond the schema's example.

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?

States a specific verb and resource — query any Kingdee bill list — with the supported operations (filter, sort, pagination) named up front, and the form_id examples make the scope concrete. It implicitly differentiates itself from the many entity-specific siblings (e.g. kingdee_query_purchase_orders) by claiming '任意单据' (any bill), but never names those alternatives 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?

The form_id examples (PUR_PurchaseOrder, SAL_SaleOrder, STK_InStock, plus base-data forms like BD_Currency) implicitly tell the agent what this tool is good for. However, there is no explicit statement about when to prefer this generic tool over the dozens of specialized query siblings, nor any prerequisites or exclusion criteria.

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

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

Annotations (readOnlyHint=true, destructiveHint=false) indicate safe read. The description adds behavioral context: it retrieves historical change records with details on who, what, when, and value changes. 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?

Description is well-structured with clear sections for purpose, scenarios, and return fields. It is slightly verbose but effectively front-loads key information. Minor redundancy could be trimmed.

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 (11 parameters, output schema exists), the description covers purpose, use cases, and return fields comprehensively. It is complete for an agent to understand usage.

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 has detailed descriptions for all 11 parameters (100% coverage). The description adds no additional parameter-specific meaning, so baseline 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 specifies the tool queries bill change logs for Kingdee Cloud Star, targeting BOS_ModifyLog. It clearly states the resource and action, distinguishing it from sibling tools like kingdee_query_bills which query current bill data.

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?

Provides recommended scenarios (data governance, problem investigation, compliance) and lists return fields. While it doesn't explicitly contrast with siblings, the use case is clear and well-contextualized.

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

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

Annotations indicate readOnly, non-destructive, idempotent. Description adds context (entity type, typical filters) but does not elaborate on behavior beyond annotations, which already set expectations of safe read operations.

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 very concise, with no wasted words. It front-loads the core purpose and uses a structured code block for examples, making it easy to parse.

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 annotations and output schema existence, the description is largely complete for a simple query tool. It could mention pagination or result format more explicitly, but it adequately covers the main purpose.

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?

Input schema already provides descriptions for all parameters. The description adds value by suggesting common filter_string values and recommended field_keys, going beyond schema to guide effective use.

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 tool queries cost adjustment orders (STK_CostAdjust). The name and description are specific and align, distinguishing it from sibling query tools for other entities.

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 examples of filter_string and recommended field_keys, aiding effective usage. However, it lacks explicit guidance on when to use this tool versus alternatives like kingdee_query_bills or other cost-related queries.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns a JSON list, which is minimal. No additional behavioral traits like pagination behavior (though schema covers start_row/limit) or API limits are mentioned. No contradiction 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 very concise: one line for purpose, then bullet-like examples for filter_string, a line for recommended field_keys, and a line for return type. Every sentence adds value with no redundancy. Front-loaded with purpose.

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 complexity (6 sub-parameters, many siblings), the description covers purpose, usage examples, and return format well. It could mention the expected form_id value (CB_CostCalBill) explicitly, but the name implies it. The presence of an output schema (inferred from return type) reduces need for further detail.

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?

Despite schema description coverage reported as 0%, the schema actually has descriptions on each property. The tool description adds domain-specific examples for filter_string (FYear, FPeriod, FMaterialId.FNumber) and recommends field_keys, which go beyond the generic schema descriptions and provide practical guidance.

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 tool queries a list of cost calculation sheets (CB_CostCalBill), which is a specific entity. The title from annotations matches the description. Among many query siblings, this one is uniquely identified by its focus on cost calculation.

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?

Provides concrete filter_string examples (year, period, material) and recommends field_keys. However, it does not explicitly state when to use this tool versus other cost-related queries like kingdee_query_material_cost or kingdee_query_cost_adjustments, nor does it mention not to use it for other cost forms.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by showing the response is JSON-formatted and providing filter examples. It does not contradict annotations and enhances understanding of expected behavior.

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 brief and well-structured with bullet points for key usage hints. Every sentence adds value, and it is front-loaded with the purpose. No unnecessary words or repetition.

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 (context signal), so the description does not need to detail return values. However, it only states 'JSON format' without specifying common fields or structure. For a query tool, more detail on expected output fields would improve 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 description adds meaning for filter_string and field_keys with concrete examples, but does not cover other parameters like form_id, order_string, start_row, limit. Schema description coverage is 0%, so the description partially compensates but leaves gaps.

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 cost center basic data with a specific form ID (CB_CostCenter). The tool name and title are descriptive. Among many sibling query tools, this one is distinctly for cost centers, making purpose clear and unambiguous.

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 example filter strings and recommended field_keys, which gives practical usage guidance. However, it does not explicitly specify when to use this tool versus alternatives (e.g., other cost-related queries) or any conditions where it should not be used.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns a JSON list, but no behavioral traits beyond that, such as pagination behavior or whether it works without form_id being set.

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 very concise with a clear main line, examples, and return type note. No redundant sentences; every part earns its place.

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 existence of an output schema, the description adequately covers purpose and provides practical examples. However, it does not specify what form_id should be used for cost items, which is a required parameter and likely has a fixed value.

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 has rich descriptions for all parameters, but the description adds domain-specific examples for filter_string and field_keys, which are valuable 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 cost item basic data (CB_CostItem), aligning with the name and distinguishing from many sibling query tools by specifying the resource 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?

Provides concrete examples of filter_string and field_keys, but lacks explicit guidance on when to use this tool vs other query tools, nor any context about prerequisites or limitations.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the bar is lower. The description adds that it returns a JSON list of cost trends, but does not disclose other behavioral traits like rate limits, authentication needs, or edge cases. No contradiction 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 front-loaded with the main purpose, followed by concise examples and a note on return format. Every sentence adds value with no wasted words.

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 read-only nature, annotations, and existence of an output schema, the description is largely complete. It could mention prerequisites like needing material IDs, but overall provides sufficient context.

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 compensate. It provides specific examples of filter_string (material and date range) and recommended field_keys, adding meaningful context beyond the generic schema 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 the tool queries the cost price trend analysis table (STK_CostTrend) and analyzes material cost price trends. It distinguishes from siblings by specifying the exact table and purpose.

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 gives examples of filter_string and field_keys, implying usage context, but does not explicitly state when to use this tool over other cost-related query tools (e.g., kingdee_query_material_cost) or provide exclusion criteria.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context: backup data may be in system config tables or background forms, requires system admin permissions, and that no results may indicate missing fields (prompting use of kingdee_get_fields). 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?

Description is short and front-loaded with purpose, followed by bulleted scenarios and a caution. Every sentence adds value; no fluff.

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 presence of output schema and well-described input schema parameters, the tool description covers purpose, usage scenarios, access prerequisites, and fallback guidance. It is complete for a query tool.

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 from description is 0%: the description does not mention any of the input parameters (backup_type, status, operators, dates, filter, pagination), despite the schema having good parameter descriptions. The description relies entirely on schema for parameter meaning, requiring the agent to read schema separately.

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?

Description clearly states the tool queries data backup records of Kingdee Cloud Star ('查询金蝶云星空的数据备份记录'), specifies it records backup and restore operations, and is distinct from sibling query tools (e.g., kingdee_query_audit_log).

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?

Provides explicit recommended scenarios (disaster recovery verification, compliance, recovery drills) and advice on using kingdee_get_fields if results are empty. Lacks explicit when-not-to-use or comparison with other query tools, but context is clear.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable environment-specific behavior: the FCustomerID vs FCustId field-key pitfall and the explicit no-write scope, though it does not discuss pagination or rate limits.

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?

Purpose and scope are front-loaded, with useful headings and bullets. The field-key warning is slightly verbose in repeating the failure mode and verification context, but each section remains actionable.

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 an output schema and safety annotations already present, the description supplies the key invocation details: FormId, query-only boundary, filter syntax, recommended field keys, and the critical environment-specific key caveat. Pagination and ordering defaults are adequately left to the schema.

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 schema already documents each parameter, giving a baseline of 3. The description goes beyond it with concrete filter_string examples for status, customer, and date ranges, plus a validated field_keys list; limit, start_row, and order_string remain schema-only.

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?

States a specific verb '查询' and resource '发货通知单', pins FormId SAL_DELIVERYNOTICE, and describes the customer/status/date filtering scope. The write-scope warning also distinguishes it from mutation siblings such as kingdee_save_bill and kingdee_submit_bills.

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?

Explicitly says the tool is query-only and that save/submit/audit actions are handled by named generic alternatives. It also directs agents to verify field keys via kingdee_get_fields, giving clear when-not and alternative guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns a JSON list but does not elaborate on other behaviors like authorization or pagination limits. No contradiction 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 extremely concise: one sentence plus a return type note. Every word serves a purpose, and it is front-loaded with the core function. No unnecessary text.

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 presence of a detailed input schema and output schema (implied by context), the description covers the essential purpose and filtering. It does not mention pagination details or default fields, but the schema compensates. Overall, it is sufficiently complete for a query tool.

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 tool description does not describe any parameters (0% coverage), but the input schema provides detailed descriptions for each property (e.g., form_id, filter_string). The schema already conveys parameter semantics, so the description adds no extra value.

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 that the tool queries expense reimbursement documents ('查询费用报销单') and mentions filtering capabilities. Among siblings, it is distinct as it targets expense reimbursement specifically.

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 indicates the tool is for querying expense reimbursement documents with filtering, but does not provide explicit guidance on when to use it versus alternatives or when not to use it. It is adequate but lacks exclusionary context.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds no further behavioral details beyond returning JSON. No contradiction.

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: one line for purpose, followed by essential examples and return type. No unnecessary words.

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 (6 parameters in nested schema) and presence of output schema, the description covers key usage patterns and return format. Lacks explanation of form_id usage but schema covers that.

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 descriptions are comprehensive. The description adds domain-specific examples for filter_string and field_keys, enhancing practical understanding beyond the generic schema.

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 tool queries finished product cost from stock-in (完工入库产品成本) and provides the internal query ID. It distinguishes itself from sibling query tools by specifying the resource 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?

Provides concrete filter examples and recommended field keys, implying usage context for production orders and periods. However, it does not explicitly compare to sibling tools or state when to use this vs alternatives like kingdee_query_material_cost.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the formId and filter examples but does not disclose additional behavioral traits like pagination behavior or authentication needs. It is consistent but not especially rich.

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, starting with purpose, then context, then examples. Every sentence adds value. It is concise yet informative, with no redundant information.

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 presence of an output schema and comprehensive annotations, the description covers filtering capabilities and provides usage examples. It is complete for a query tool, though it could mention pagination parameters which are only in the schema.

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 description adds concrete examples for filter_string and recommends a set of field_keys, which goes beyond the schema descriptions. Despite schema description coverage being 0% in the tool description, the examples provide practical guidance for parameter usage.

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 specifies the tool queries fixed asset card master data, naming the API and formId. It defines fixed assets. However, it does not explicitly differentiate from sibling tools like kingdee_query_asset_card, though the domain specificity provides implicit distinction.

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 states it supports filtering by asset number, name, status, and department, and provides example filter_strings. However, it gives no guidance on when not to use this tool or alternatives, leaving the agent to infer from context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the agent knows it's a safe read. The description adds that it queries a specific table and returns a JSON list, plus provides examples of useful field keys. No contradictions. It goes beyond annotations by detailing the data content.

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 (4 lines) and front-loaded with the main purpose, followed by examples. It avoids unnecessary fluff. Could be slightly more structured with bullet points, but overall 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 (multiple parameters), annotations (read-only), and existence of an output schema, the description covers the main purpose, provides concrete usage examples, and specifies the return format. It does not explain pagination or field meanings in detail, but is adequate for a query tool.

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%, meaning parameter descriptions are generic. The description compensates by giving specific examples for filter_string (material/warehouse) and field_keys, which add meaning beyond the generic schema. However, it does not describe parameters like order_string, start_row, or limit, leaving them to 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 the 'STK_InstantCostCompare' table and compares instant cost with accounting cost. The verb '查询' (query) and resource are specific. Among siblings, this tool is distinct as it targets a specific cost comparison table, differentiating it from other cost-related query tools.

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 concrete examples of filter_string and field_keys, showing how to filter by material and warehouse. However, it does not explicitly state when to use this tool over other cost-related siblings like query_cost_calculation or query_material_cost, nor does it provide when-not-to-use guidance.

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

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

Annotations indicate readOnlyHint=true and no destruction, which the description supports. It additionally describes return format (JSON string with fields) and default filtering, adding value 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 concise: two paragraphs with purpose, filter examples, and return format. Every sentence is informative and front-loaded.

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?

For a simple query tool with output schema, the description covers essential aspects: what it queries, how to filter, and output format. It could mention pagination behavior, but the parameters are self-explanatory.

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 description provides practical examples for filter_string and lists default fields, adding meaning beyond the schema's descriptions. It compensates for undocumented parameters like start_row and limit by showing default values in schema.

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 tool's purpose: querying immediate inventory quantities from the STK_Inventory table. It provides specific filter examples and distinguishes from other query tools by naming the source table and focusing on inventory.

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 offers usage context through filter examples and default behavior, but does not explicitly guide when to use this tool versus sibling query tools like kingdee_query_materials or kingdee_query_stock_bills.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: it warns the form is not enabled in some account sets (returning 「未知表单」 from kingdee_get_fields), explains the tool therefore may not work against a live system, and gives a concrete recovery path for 「字段不存在」 errors. That is exactly the kind of failure-mode disclosure annotations cannot carry.

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?

Front-loads the purpose and FormId, then the environment caveat, then the recommended field keys — a sensible ordering. It is on the long side with a multi-line warning block, but every section carries operational information an agent needs; nothing is pure filler.

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 return values need no explanation, and the description covers the essentials for a query tool: what entity, which FormId, which fields to request, and what to do when the form is unavailable. The only remaining gap is that it doesn't clarify how the recommended field_keys interact with the default in the schema.

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 schema documents each leaf parameter (limit, start_row, field_keys, order_string, filter_string), but the description adds the tool-specific value the schema cannot — form_id should be ER_HistoricalLoanBalance — and supplies a curated field_keys list (FID, FBillNo, FApplicantId.FName, FLoanAmount, FRepaidAmount, FUnRepayAmount, etc.) that maps business concepts to Kingdee field names. It doesn't spell out filter_string syntax beyond the status/applicant/date hint.

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?

States a concrete verb+resource (查询历史借款余额) and pins it to the exact Kingdee module and FormId ER_HistoricalLoanBalance, with the business domain (人人报销) named. That level of specificity makes it unmistakable versus the generic kingdee_query_bills or the neighbouring kingdee_query_expense_reimburse.

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?

Explains the intended scope — employee/department loan balance snapshots — and enumerates the supported filter dimensions (status, applicant, date), which tells the agent when this tool applies. It stops short of naming an alternative for cases where the module is unavailable, only saying to re-check fields with kingdee_get_fields, so the when-not guidance is partial.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's addition of return format (JSON list) is helpful but not essential. It adds database name but lacks details on authorization or rate limits, which is acceptable given the strong annotation profile.

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 brief, uses bullet points for examples, and clearly separates sections. Every sentence adds value without redundancy.

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 presence of an output schema and detailed parameter schema, the description covers the essential query logic, return type, and usage patterns. Nothing critical is missing for a read-only query tool.

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% per context, so the description bears the burden. It adds value by providing concrete filter_string and field_keys examples, but does not explain form_id, order_string, start_row, or limit. This partial coverage justifies a 3.

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 tool queries a specific database (BD_MaterialCost) and returns standard, latest, and average costs. The verb '查询' combined with the specific resource '物料成本库' makes the purpose distinct from sibling query tools.

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 explicit filter string examples and recommended field keys, guiding usage. However, it does not contrast with similar tools like kingdee_query_finished_product_cost or mention when not to use this tool, leaving some ambiguity.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the return format (JSON string) and form ID, but does not contradict annotations. This provides slight additional context beyond structured fields.

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 efficiently structured with the purpose first, followed by examples and return type. It is relatively concise, though the examples could be slightly more compact.

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 essential usage (form ID, examples, return format) and an output schema likely exists. However, it lacks usage context relative to siblings and does not mention pagination or limitations, leaving gaps for an agent.

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?

Despite the input schema having descriptions for parameters, the description adds concrete filter string examples and recommended field keys, which go beyond generic schema descriptions. This significantly aids correct parameter usage.

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 tool queries production material consumption cost and provides the specific form ID CB_MaterialCostQuery. However, it does not explicitly differentiate from siblings like kingdee_query_material_cost or kingdee_query_material_target_cost, which is a minor gap.

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 offers no guidance on when to use this tool versus alternatives. It provides filter examples and recommended fields but does not explain selection criteria among similar cost query tools.

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