Kingdee MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
While individual tool descriptions are detailed, the sheer number (81) and overlapping names (e.g., multiple query tools for similar domains like purchase orders vs. purchase order progress) cause confusion. Some tools appear to have nearly identical purposes (e.g., kingdee_query_transfer_apply and kingdee_query_stock_transfer_apply). Agents may struggle to select the correct tool despite good descriptions.
Naming Consistency4/5
All tools follow the kingdee_ prefix with predominantly verb_noun pattern (e.g., query_*, save_*, audit_*). Use of snake_case is consistent. Minor deviations exist like 'kingdee_usage_report' and 'kingdee_usage_stats' which are noun_noun, and 'kingdee_create_and_audit' which uses 'and'. Overall, consistency is high.
Tool Count3/5
81 tools is excessive for a single MCP server. While covering a large ERP domain, the number overwhelms the tool surface. A more modular approach (e.g., separate servers for purchasing, sales, inventory, etc.) would improve clarity and reduce cognitive load for agents. The count is borderline high.
Completeness4/5
The server covers a wide range of Kingdee operations: CRUD for bills (save, submit, audit, unaudit, delete), queries for many document types (purchase, sales, inventory, production, assets), push operations, and audit logs. Minor gaps exist, such as missing update tools for specific entities (e.g., assets only have save, no update) and no delete for non-bill entities. Overall, it is comprehensive for the stated domain.
Average 3.9/5 across 81 of 81 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 7 community issues answered or closed in the last 6 months
- 24 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. Description adds that return is JSON string, but omits details like whether the document must exist or what happens if not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short and front-loaded with purpose. However, it mixes Chinese and English, and the Returns block is redundant. Could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, description doesn't need to detail return structure, but it omits important context like possible statuses, error conditions, and behavior with non-existent documents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% according to context, and the description does not explain parameters (form_id, bill_id) or their values. Parameter purposes are only inferred from brief schema labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries approval flow status and returns status and details. It differentiates from siblings like kingdee_query_approval_flow only by name, not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_query_approval_flow or kingdee_view_bill. Missing context for prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show no safety hints (all false), so description must cover behavior. It only mentions submitting to an approval queue, omitting idempotency, error states, or consequences of re-submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with no fluff, but return type structure could be clearer. Front-loads key action but loses some detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool but description lacks explanation of return fields (e.g., next_action meaning), error handling, or workflow implications. Output schema not provided inline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool description provides no parameter explanations; schema descriptions are in Chinese, making them inaccessible to an English-speaking LLM. High schema coverage (100%) but descriptions are non-English.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (submit) and resource (production orders, PRD_MO) to an approval queue. It distinguishes from general submission tools like kingdee_submit_bills by name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives like kingdee_save_production_order or kingdee_audit_production_orders. Agent must infer from name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond annotations. It states the return type (JSON array) and explains the data's origin, but does not disclose details like pagination, filtering behavior, or authentication needs. Annotations already indicate read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus returns line) and front-loads the purpose. Every sentence is relevant, but it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple filter parameters, output as array), the description is incomplete. It lacks guidance on usage and parameter semantics. The existing annotations and output schema mitigate some gaps, but the description should do more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. Schema coverage for the top-level 'params' object is 0%, and the nested properties have schema descriptions but lack context on usage or syntax. The description should add meaning beyond the schema, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '查询生产计划单' (query production plan), which is a specific verb-resource pair. The annotation title also confirms this. However, it does not differentiate from sibling query tools like kingdee_query_production_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It only describes the data context (MRP, push to orders) but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful context about the data content (工序完成数量/工时/良品率) and return fields, but does not disclose additional behavioral traits such as pagination, rate limits, or performance. This adds some value beyond annotations, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two lines for purpose and context, plus a return format line. Every sentence adds value. However, it could be slightly more structured, e.g., explicitly listing parameters, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown) and return fields listed, the description lacks guidance on constructing the filter_string or other parameters. For a tool with three parameters and 0% schema coverage, the description should compensate but does not. The return fields help but incomplete elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), and the tool description does not mention any parameters or provide usage guidance for filter_string, top, or orderby. The agent must rely solely on the schema, which lacks descriptions. This is a critical gap for a query tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '查询' (query) and the resource '生产汇报单（PRD_MOReport）', distinguishing it from sibling tools like kingdee_query_production_orders and kingdee_query_production_plan. It also explains the report's content and its role as a preliminary step for production warehousing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions the report is a prerequisite for production warehousing, but no when-not-to-use or direct comparisons to siblings. The agent must infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, non-destructive, and idempotent. The description adds that it supports filtering, sorting, pagination, and returns JSON with specified fields. It does not disclose additional behaviors like error handling or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main parts: a summary of capabilities and examples. It is front-loaded with the primary purpose. Minor improvement could be more explicit structure, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations and a clear output schema (returns JSON with form_id/count/has_more/data), the description covers the key aspects. It lacks edge case details but is sufficient for a generic query tool with good structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the context signal claims 0% schema description coverage, the actual input schema provides descriptions for each parameter (e.g., form_id, filter_string). The description does not add substantial meaning beyond these schema descriptions, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries any Kingdee document list with filtering, sorting, and pagination. Examples of form_id are given. However, it does not explicitly differentiate from sibling specific query tools (e.g., kingdee_query_sale_orders), so distinguishing is implied but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the more specific query tools. No when-not-to-use or alternative recommendations are provided. Only examples are given, which weakly imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 and mentions the function name, but does not contradict annotations. It provides adequate but not deep behavioral context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three lines) and front-loaded with the main purpose. It includes the function name and practical examples without unnecessary verbosity. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a read-only query with comprehensive annotations and an output schema, the description covers the purpose, common usage patterns, and return type. It does not detail error handling or pagination, but these are secondary for a simple query; completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides example filter_string and field_keys values, adding some meaning beyond the schema. However, the schema already has comprehensive descriptions for all parameters (though context reports 0% coverage, likely meaning description does not systematically cover parameters). Baseline 3 is appropriate as schema covers parameters and examples add minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries product standard cost (查询产品标准成本) and provides the Kingdee function name. It uses a specific verb and resource, but does not explicitly differentiate from sibling cost query tools, though the name itself is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples of common filter_string and field_keys, implying typical usage, but lacks explicit guidance on when to use this tool versus alternative cost-related queries (e.g., material cost, finished product cost). No when-not-to-use or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds that it analyzes logged usage logs and returns a report, which is consistent and adds mild behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with bullet points listing insights, front-loaded with purpose. No wasted text, structure effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations, clear schema, and implied output schema, description is sufficiently complete. It explains purpose and insights, though could mention data range or pre-computation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because description omits format parameter, but the schema itself provides a clear description of the parameter. Baseline 3 as schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool views MCP usage statistics and lists specific insights (e.g., frequency, success rate, time distribution). However, there is a sibling 'kingdee_usage_stats' with similar name, and description does not differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as 'kingdee_usage_stats'. Description implies analysis of logged data but does not specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so description's addition of downstream implications is helpful but not critical. No mention of rate limits, auth, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sentences, each serving a distinct purpose: resource identification, business context, and return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with annotations and output schema mentioned, the description covers the data's origin, structure, and use. Minor lack of pagination or error details but not critical given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema properties have descriptions, the context signals indicate 0% coverage, meaning the description must compensate. However, the description adds no parameter-level guidance beyond what is in the schema, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb '查询' and resource 'MRP运算结果', providing business context of origin and downstream use. However, it does not explicitly differentiate from similar query tools like kingdee_query_production_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage context (MRP results from various demand sources) but no explicit when-to-use or when-not-to-use guidance, nor alternatives among many sibling query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds value by specifying the return format (JSON string) and providing filter examples, but it omits details on pagination, limits, and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one purpose line, bulleted examples, and return type. It is well-structured and front-loaded with key information, though it could be more organized by explicitly mapping parameters to examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, filter examples, and recommended fields. However, it fails to resolve the ambiguity of the form_id parameter (whether fixed or user-supplied) and does not detail the return JSON structure, leaving gaps for a comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the top-level 'params' parameter, but the schema itself includes descriptions for nested properties. The description adds example values for filter_string and field_keys, partially compensating, yet it does not explain parameters like form_id, order_string, start_row, or limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries production order (PRD_MO) list, with specific verb '查询' and resource '生产订单'. It provides common filter strings and recommended fields, distinguishing it from generic query tools like kingdee_query_bills by specifying the form type PRD_MO.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers practical filter and field key examples, aiding effective use, but lacks explicit guidance on when to use this tool versus siblings (e.g., kingdee_query_bills) and does not clarify whether the form_id parameter should be set to PRD_MO or is hardcoded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds no extra behavioral details beyond what annotations provide. Adequate but does not leverage the opportunity to add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no superfluous text. Every sentence earns its place. Very concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and description notes return type (JSON string). With good annotations covering safety and idempotency, the description is adequate for a simple query tool. Minor missing details about pagination or error handling prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 does not mention any parameters or their meaning. Although the input schema itself has parameter descriptions, the tool description fails to add context beyond that, which is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '查询待审批的单据列表' (query list of pending approval documents) and specifies the scope as documents currently in approval status. This distinguishes from sibling query tools like kingdee_query_bills which likely query general bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites, when not to use, or recommended contexts. Given many sibling query tools, this omission hinders correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds minimal behavioral context beyond querying; no details on authentication, rate limits, or pagination behavior beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise with clear sections (purpose, filter examples, field_keys). Every sentence is meaningful; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, description adequately covers business context and basic usage. Could mention pagination limits (max 100) but schema handles defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage in description text, the description adds significant value with concrete filter examples and recommended field_keys, greatly aiding parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries stock transfer applications (STK_TransferApply) and explains the business purpose. It distinguishes from generic query tools but does not explicitly differentiate from sibling 'kingdee_query_transfer_apply'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides useful filter examples and recommended field_keys, implying typical use cases. However, it does not explicitly state when to use this tool over siblings 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, consistent with creation/modification. Description adds a creation example and return value description. However, it does not mention idempotency or that modifications require FID (though schema mentions it). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear purpose and a helpful example. The JSON example adds length but is justified. Could be slightly more streamlined without the example, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (one nested parameter) and 0% schema coverage, the description should provide more parameter context. The return value is well-described. However, missing explanations for form_id and other fields reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 a JSON example for the 'model' parameter but fails to explain 'form_id', 'need_update_fields', and 'is_delete_entry'. Schema includes descriptions but the tool description does not elaborate, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '新建或修改生产订单（PRD_MO）', which is a specific verb (create/modify) and resource (production order). It distinguishes from siblings like kingdee_save_bill and kingdee_save_asset by focusing on production orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like kingdee_save_bill for other order types. The purpose is implied but not articulated, and prerequisites (e.g., existence of material FNumber) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent. Description adds required form_id value and alternative bill_no parameter. No contradictions, but doesn't elaborate on behavior beyond safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and to the point, listing required parameters and return type. Could be better structured but front-loads key info without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple view tool with output schema. Missing explanation of 'mode' parameter and more detailed return structure, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: specifies that form_id must be 'PRD_MO' and that bill_id can be either FID or bill_no. Schema already describes parameters, but description clarifies usage constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes viewing complete details of a production order with specific verb and resource. Distinguishes from sibling query tools by emphasizing full details, though not explicitly differentiating from other view tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States required parameters and return type, implying use when needing full details of a specific order. Lacks explicit when-to-use or alternatives, but context with siblings helps differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds minimal value beyond stating it returns a JSON list and explaining filter_string syntax. No additional behavioral traits (e.g., permissions, side effects) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and includes helpful code-like examples. It is reasonably concise, though the list of filter_string examples and field_keys could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and schema, the description is adequate for a basic query tool. It specifies the form ID and return format, but does not mention pagination defaults (e.g., limit=20) or that filter_string and field_keys are optional, though the schema covers these.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, so baseline is 3. The tool description adds examples for filter_string and recommended field_keys, but does not explain other parameters like order_string, start_row, or limit beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries production pick materials (PRD_PickMtrl) list, providing examples of filter_string and recommended field_keys. It is distinct from sibling query tools like kingdee_query_bills or kingdee_query_production_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete examples of filter_string for common scenarios (approved, specific order, specific warehouse) and recommends field_keys, but does not explicitly state when to use this tool versus alternatives 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating the return format is JSON with specific fields (e.g., encoding, name). Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is clear. The description does not contradict annotations and provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 lines) and includes essential information: purpose, partner_type values, and return format. It is well-structured and front-loaded with the main action. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown) and annotations cover safety and idempotency, the description is fairly complete. It mentions return fields and includes the two partner types. However, it could mention pagination parameters (start_row, limit) and that filter_string allows filtering, but these are in the schema. Overall, it adequately covers core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters, including partner_type and field_keys. The description only reiterates partner_type values and does not add new information for other parameters. With high schema description coverage, the baseline is 3, and the description does not improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries customer (BD_Customer) or supplier (BD_Supplier) basic data, specifying the two partner types and listing return fields (code, name, short name, contact, phone). This distinguishes it from other query tools among siblings, such as kingdee_query_materials or kingdee_query_bills, making the purpose specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other query tools for different entities (e.g., kingdee_query_materials, kingdee_query_bills). It does not mention prerequisites, context of use, or scenarios where this tool is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint false) and not destructive. The description adds context by specifying the status change (draft → pending review) and that the response includes a next_action field, providing useful behavioral cues beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, but the return type is described in a code-like format which could be cleaner. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action and output format, but it omits potential failure modes (e.g., invalid IDs, already submitted bills) and required permissions. For a simple submit tool, this is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not mention any parameters; they are only described in the schema (in Chinese). With 0% schema description coverage, the description fails to add meaning beyond what's in the schema, leaving the agent to rely solely on schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits bills, transitioning them from draft to pending review. It distinguishes itself from siblings like kingdee_audit_bills by specifying the submission step and suggesting a follow-up action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by suggesting calling kingdee_audit_bills after successful submission, but it does not explicitly state when to use this tool over alternatives (e.g., kingdee_create_and_audit) 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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 string and lists output fields, but does not disclose additional behavioral details like pagination limits or rate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, recommended scenarios, and a detailed list of return fields. It is concise without unnecessary text. A slight improvement could be to integrate parameter guidance, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (many parameters, pagination, output fields), the description covers the key aspects: purpose, usage scenarios, and return value format. The input schema covers parameter details, but the description could be more complete by mentioning pagination or filter capabilities. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description does not repeat or elaborate on the input schema parameters. The description focuses on output fields and usage scenarios, not on how to use the input parameters. The schema itself provides detailed parameter descriptions, but the description should compensate for low coverage. It does not, so this dimension scores low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'query' and the resource 'operation logs' (BOS_OperateLog), and explicitly describes the contents. It distinguishes itself from sibling query tools by focusing on operation logs, not specific bill types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit recommended scenarios (security audit, fault diagnosis, compliance). It does not explicitly state when not to use it, but the list of scenarios provides clear guidance. Sibling tools are for specific entities, so this tool's general nature is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description confirms it is a list query, adding minimal behavioral insight beyond annotations. It does not contradict annotations, but offers no additional details about behavior (e.g., rate limits, data freshness).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a concise first paragraph stating the purpose and a second paragraph with examples. It is front-loaded and efficient, though the examples could be more compact. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and provides useful query patterns, but it lacks details about the output structure beyond 'JSON format'. Given that an output schema exists, the description is somewhat complete but could offer more context about the returned fields or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description enriches the schema by providing concrete examples of filter_string values and recommended field_keys. This adds significant practical meaning beyond the schema definitions (e.g., showing how to filter by result or pass/fail quantities).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 incoming material inspection orders (QIS_InspectBill/IQC). It specifies the verb 'query' and the resource 'quality inspections', distinguishing it from other query siblings like kingdee_query_bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful filter_string examples for common statuses (inspected, passed, failed) and recommended field_keys, which helps in constructing queries. However, it does not explicitly state when to prefer this tool over similar query tools (e.g., kingdee_query_bills) 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false (write operation) and destructiveHint=false. The description adds that it creates or modifies, plus the return format (JSON with FID and FBillNo). However, it does not disclose authorization requirements, side effects, or behavior when modifying (e.g., partial updates). The added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, a JSON example, and return info. No redundant words. The key information is front-loaded (purpose), followed by example, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (saving cost adjustment with nested entries), the model example significantly aids understanding. The return format is specified. While the output schema is not detailed, the description covers the essentials. The schema already documents parameters comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for each parameter (e.g., form_id, model, need_update_fields, is_delete_entry). The description adds a concrete model example demonstrating the expected JSON structure, which enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '新建或修改成本调整单（STK_CostAdjust）' which clearly identifies the verb (create or modify) and the resource (cost adjustment order). The model example further clarifies the structure. Differentiates from sibling save tools (e.g., kingdee_save_bill) by focusing specifically on cost adjustments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other save tools like kingdee_save_bill or kingdee_save_asset. There is no mention of prerequisites, typical scenarios, or exclusions. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: return format (JSON), demo-verified fields, conditional field presence, and business close rules. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-structured with bullet points and sections. Some redundancy (e.g., listing all fields might be omitted). Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations providing safety info and output schema implied, the description covers return fields, conditional behavior, and business rules. It is sufficiently complete for an AI agent to understand the tool's output and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only mentions the default for filter_string. Does not explain start_row or limit parameters. The description adds minimal value over the schema for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it queries purchase order line details and execution progress, distinguishing from sibling tool kingdee_query_purchase_orders by specifying line-level fields. The verb 'query' and resource 'purchase order progress' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with a sibling tool, notes default filter for audited documents, and explains field availability depends on supply chain module. Does not state when not to use, but provides adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds that it returns a JSON format list but does not disclose any additional traits or limitations beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and starts with purpose. It uses bullet points for examples, which aids readability. However, it could be slightly more structured, e.g., grouping return info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description adequately explains inputs and output format. It mentions pagination parameters implicitly via examples? Actually no, but the schema covers them. Overall, it covers the essential information for a config query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for filter_string and field_keys, but the tool description adds value by providing concrete examples and recommended field_keys. It also clarifies the return format. For the other parameters (start_row, limit), the description does not add meaning, but they are straightforward.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries system config parameters in Kingdee. It provides specific examples of filter_string and field_keys, and mentions the return is a JSON list. This distinguishes it from sibling query tools which query other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples of filter strings and field keys, implying common usage. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or conditions where the query might fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly stating the return format (JSON list) and providing default field keys and filter examples. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is fairly concise with bullet points for parameters and returns. It front-loads the purpose and table name. Could potentially be slightly shorter, but no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-parameter query with filter, fields, pagination), the description covers the essential usage: table name, filter examples, recommended fields, and return format. An output schema exists, so return value details are covered. No notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 moderate. The description adds usage examples for filter_string and recommends field_keys, adding some semantics beyond the schema. However, it does not explain the form_id parameter or the overall QueryInput structure beyond the given examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool queries the '分步式调出未调入明细表' (step-by-step transfer out but not in detail), specifying the exact table and the business scenario. The verb '查询' (query) and resource are unambiguous, and the tool is distinct from many sibling query tools by its focus on pending transfer details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical filter_string examples (date range, material, warehouse) which help with parameter usage, but does not include guidance on when to use this tool versus alternatives like kingdee_query_stock_bills or kingdee_query_transfer_apply. No explicit exclusions or when-not-to-use criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive. The description adds value by specifying the exact state transition ('已审核 → 待审核') and the condition for success (success=true meaning return to pending audit). It also mentions that bills can be modified and resubmitted, which is helpful context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, using two sentences in Chinese plus a return format line. It is front‑loaded with the main action. Minor redundancy in the return description (mentioned in both Chinese and English) could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state‑change operation, the description covers purpose, state transition, preconditions (audited state implied), and postconditions (modifiable). The presence of an output schema reduces the need to detail return values. However, it lacks error handling or what happens if bills are not in audited state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the two parameters ('form_id' as 单据类型标识, 'bill_ids' as 单据内码FID列表). The tool description does not add any additional semantic information about the parameters, so it meets the baseline for a schema with full description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool un-audits bills, changing status from '已审核' to '待审核'. It distinguishes from sibling 'kingdee_audit_bills' by specifying the reverse operation. Additionally, it explains the benefit (can modify and resubmit) and provides the return format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to reverse an audit, but it does not explicitly state when to use versus alternatives (e.g., delete, submit). No direct contrast with sibling tools like 'kingdee_delete_bills' or 'kingdee_submit_bills'. Some guidance is provided by mentioning post‑un‑audit actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent behavior. Description adds that it returns JSON but does not explain pagination, potential large result sets, or error scenarios beyond what schema hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line purpose, bulleted examples, and return line. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main query intent and filter usage; mentions return format; pagination details are left to schema; missing returned JSON structure but output schema likely covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds concrete example filter strings and recommended field keys, which enrich the schema definitions that already have basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries a permission list in Kingdee system, with specific examples of filter usage, differentiating 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage examples for filter_string but no explicit guidance on when to use this tool vs alternatives, nor any when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds that it returns JSON but does not disclose additional behaviors like pagination limits, rate limiting, or data freshness. It is consistent with annotations, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and uses bullet points for examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, return format, and typical usage patterns. It does not explain pagination behavior or form_id specifically for this tool, but the output schema likely provides structure. Adequate for an agent with domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides concrete examples for filter_string and field_keys, adding practical value beyond the schema descriptions. However, the schema already defines each parameter, so the added semantics are supplementary rather than essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 purchase requisitions (PUR_Requisition), explicitly naming the resource and providing context about its role in procurement. It distinguishes from siblings like kingdee_query_purchase_orders by focusing on requisitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of filter_string usage but does not discuss when to use this tool versus other query tools (e.g., purchase orders, sales orders). It lacks explicit guidance on alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool returns a JSON formatted role list, but does not disclose additional behavioral traits beyond what annotations provide. For a read-only tool with good annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for purpose and examples, plus a note on return type. Every sentence adds value, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 4 parameters, and an output schema exists. The description covers the essential usage patterns (filtering, field selection) and states the return format. It does not explain pagination (start_row, limit) or error behavior, but these are partially covered by the schema. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given schema description coverage is 0% per context (though schema actually has descriptions like '过滤条件'), the description compensates by providing concrete examples for filter_string and recommending field_keys. This adds significant meaning beyond the bare schema, especially for filter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询金蝶系统中的角色列表' (query the role list in Kingdee system). This specifies the verb (query) and resource (role list), 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage examples for filter_string and recommended field_keys, aiding parameter usage. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other query tools for different entities). The purpose is clear from the name, but no direct comparison or usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context about updating stock, which is consistent but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose sentence, brief explanation, then bullet lists of common filters and recommended fields. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (supplements return info), and description covers key usage details including filter patterns and field examples. Slight lack of pagination or sorting guidance, but adequate for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema properties all have descriptions (100% coverage), so baseline is 3. Description adds value by providing concrete filter_string examples and recommending field_keys, which go beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states this tool queries direct transfer orders (STK_TransferDirect) and explains it's for one-step transfers that update both warehouses. The verb '查询' (query) and specific resource distinguish it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example filters and recommended field keys, which imply typical use, but does not explicitly state when to use this tool over sibling query tools like kingdee_query_stock_bills or kingdee_query_transfer_apply. No 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds that the tool returns a JSON-formatted list (effectively a string), and its example filters provide insight into common usage patterns. No behavioral contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with a brief statement of purpose, followed by examples and return type. Every sentence adds value. It could be slightly more organized (e.g., separating purpose and examples), but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (mentioned in context), the description does not need to detail return values. It covers purpose, parameters (via examples), and return format. It could mention pagination or error handling, but for a read-only query tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for each parameter, providing baseline understanding. The description adds value by offering concrete filter_string examples (like 'FDocumentStatus='C'') and recommending specific field_keys, which goes beyond the schema's generic descriptions and clarifies practical usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '查询' (query) and the specific resource '物料目标成本单' (material target cost order), and mentions the form ID 'BD_MatTargetCost'. This distinguishes it from sibling tools like kingdee_query_material_cost, which deal with similar but different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage tips through filter string examples and recommended field keys, which helps the agent know how to use the tool effectively. However, it does not explicitly state when to use this tool versus other query tools (e.g., cost calculation vs. cost items), nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description adds no contradictions. It adds that the return is a JSON-formatted list, which is useful but not critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, examples, and recommended fields. It is somewhat verbose due to the code block but remains clear and informative. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with pagination and filtering, the description covers the core usage with examples. It does not detail the output schema (though one exists) or explain pagination parameters, but the schema provides defaults. Overall, it is reasonably complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the top-level parameter, but nested property descriptions exist in the schema. The description adds value by giving concrete filter_string and field_keys examples. However, it does not explain the required form_id parameter (which should likely be set to 'STK_MiscMovementDetail' based on the table name), potentially causing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the miscellaneous movement detail table (STK_MiscMovementDetail) for viewing inbound/outbound details. It uses a specific verb '查询' (query) and resource, distinguishing it from sibling query tools like kingdee_query_bills or kingdee_query_inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete filter_string examples and recommended field_keys, helping the agent construct queries. However, it does not explicitly state when to use this tool vs. other query tools (e.g., for general bills vs. misc movement), though the table name makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (no safety hints). The description discloses that new assets start as draft and require submit+audit, and that modifying audited assets needs reverse audit. This adds valuable behavioral context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with no waste. First sentence states purpose, second explains initial state, third explains modification. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavioral context but is silent on return value or error handling. An output schema exists but its details are not described. For a save tool, lacking return info reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's sub-parameters have descriptions (e.g., form_id, model), but the tool description does not add extra meaning or explain how to set form_id to 'FA_FAGet'. Schema coverage is present, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '新增或修改固定资产' (add or modify fixed assets) along with the specific form type FA_FAGet. It distinguishes from sibling save tools like kingdee_save_bill which handle different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use: for creating or modifying fixed assets. It explains the lifecycle (draft -> submit+audit, reverse audit for edits) but does not explicitly mention when not to use or compare to alternatives like kingdee_create_and_audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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 specifying the return format as a JSON string with fields like code, name, specification, unit, and material group. This aligns with annotations and provides useful behavioral context beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a brief purpose statement, three filter examples, and a return specification. Every sentence adds value without redundancy. It is front-loaded with the core purpose and uses bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters) and the presence of an output schema (which handles return values), the description covers the essential usage pattern with filter examples. However, it omits details on pagination (start_row, limit) and custom fields (field_keys). The query examples provide a good starting point but not full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema's own descriptions are insufficient. The description partially compensates by illustrating filter_string usage with examples. However, it does not explain the other parameters (field_keys, start_row, limit), which are crucial for customization and pagination. The examples for filter_string are helpful but leave gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries material basic data (BD_Material) with a specific verb '查询' (query) and resource. It distinguishes from sibling query tools like kingdee_query_bills or kingdee_query_inventory by focusing on materials. Examples of filter strings further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides common filter_string examples, guiding usage through specific filters like code prefix and name fuzzy search. It does not explicitly state when not to use this tool or mention alternatives, but the context of sibling tools implies material-specific queries. This is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds only that it returns a JSON string, with no additional behavioral traits like pagination or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with purpose stated first, followed by bulleted examples. No filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential usage with examples and hints, and output schema exists to detail returns. Missing explanation of pagination, but acceptable for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds value for filter_string and field_keys with examples and recommendations, but does not mention start_row or limit. Schema already describes these partially, so overall good complement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries a list of document number rules in Kingdee, with examples of filter strings and recommended fields, distinguishing it from other query tools like kingdee_query_bills or kingdee_query_sale_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage guidance via common filter_string examples and recommended field_keys, but lacks explicit when-to-use or when-not-to-use instructions relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds context about demo environment limitations, business rules for linked quantity, and return format, beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and efficiently organized with bullet points for filters and field keys. It is concise but includes necessary examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, the description covers essential aspects: common filters, recommended fields, demo caveats, and business rules. It is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema descriptions exist, the description adds practical examples for filter_string and field_keys, and explains the business rule, which adds meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries purchase order list (PUR_PurchaseOrder) and provides detailed filter examples and field keys, making the specific resource and action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly differentiate from siblings like kingdee_query_bills or kingdee_query_purchase_order_progress. It implies usage by providing typical filters, but lacks when-to-use or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 role is lighter. It adds context by stating the return format (JSON) and providing filter/field examples, but does not disclose additional behavioral traits beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first a clear statement of purpose, then practical filter and field examples, then the return type. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of the query tool and the presence of an output schema, the description covers essential aspects. It might be slightly improved by mentioning pagination or sorting, but current content is sufficient for typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters, but the tool's description adds value by showing concrete examples for 'filter_string' and 'field_keys', complementing the schema. This helps the agent understand typical usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool queries sale orders (SAL_SaleOrder) list, using specific verb+resource. The mention of the form ID distinguishes 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical examples of common filter strings and recommended field keys, aiding correct usage. However, it does not explicitly compare with alternative query tools or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. Description adds return type (JSON string) but does not elaborate on pagination behavior or result structure beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences plus a bullet list of form_id examples, all front-loaded and efficient with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has many parameters and an output schema, the description covers the core purpose and common form_ids; could mention pagination behavior but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds value by listing common form_id values beyond the schema's generic description; however, other parameters like filter_string and field_keys are not explained further, though schema descriptions are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool queries inbound/outbound documents (出入库单据) and lists common form_id values for specific stock movements, distinguishing from general query tools like kingdee_query_bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit form_id examples for common stock scenarios (e.g., STK_InStock for purchase receipt), but lacks guidance on when not to use this tool or alternatives among many sibling query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it returns a JSON list, but does not elaborate on rate limits, authentication, or other behavioral traits. The disclosure is adequate given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, with a clear front-loaded purpose, followed by business context, practical examples, and a return format note. Every sentence adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations (read-only, idempotent), and the presence of an output schema, the description covers essential usage aspects. It explains the data source, business need, and key filters. Minor omission: pagination is not mentioned, but it is covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema provides basic descriptions for each property, the description adds significant value by offering specific filter_string examples (FDocumentStatus, FSupplierId, FMaterialId) and recommended field_keys, which clarify usage beyond the generic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '查询供应商报价单（SVM_QuoteBill）列表', identifying the specific resource (supplier quotes) and action (query list). It explains the tool is for supplier responses to inquiries and price comparison, distinguishing it from sibling tools like kingdee_query_sale_quotations (customer quotations) and other query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context on when to use: for supplier quote retrieval and price comparison. It gives concrete filter examples for common use cases (e.g., by status, supplier, material) and recommends field_keys. However, it does not explicitly state when not to use or mention sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description does not add significant behavioral detail beyond confirming it is a query returning a JSON list. The description mentions return type ('str: JSON 格式的调拨申请单列表') but does not discuss pagination behavior (though schema defines limit/start_row) or other nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, then business context, then bullet-pointed filter examples, then recommended field keys, then return type. Every sentence adds value, and the use of examples is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, business context, usage patterns, and return format. With an output schema present, it is not required to detail return values. However, it implicitly assumes the form_id parameter should be 'STK_TransferApply' but does not explicitly tell the agent to set that value, which is a minor omission given the parameter is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with individual descriptions, so schema coverage is high. The description adds value by providing concrete examples for filter_string and field_keys, showing common usage patterns (e.g., '已审核: FDocumentStatus='C'') that go beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries a list of transfer applications (调拨申请单), identifies the specific form (STK_TransferApply), and explains the business context (starting point for transfer, can be pushed to direct or step transfer). This distinguishes it from sibling tools with similar names like kingdee_query_transfer_direct or kingdee_query_stock_transfer_apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage guidance with multiple example filter strings and recommended field keys, showing how to filter by document status, date range, warehouses, and close status. However, it does not explicitly contrast with alternative query tools or state when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe read-only operation. The description adds transparency by stating the return format (JSON str) and providing concrete filter examples, which help the agent understand the tool's behavior beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured: a single-line purpose, bullet points for common filters, recommended fields, and return type. Every sentence adds value with no redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters and the existence of an output schema (per context), the description is mostly complete with usage examples and return format. It lacks details on pagination (start_row, limit), but the schema covers that. The description adds enough context for typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema description coverage being 0% (per context), the description compensates with explicit examples for filter_string and recommended field_keys, adding meaning beyond the parameter names and types. However, it does not cover start_row and limit parameters, which are present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '查询' and resource '用户列表', and the tool name itself specifies 'kingdee_query_user', making it obvious that it queries user data. This distinguishes it from sibling query tools for other entities, such as kingdee_query_inventory or kingdee_query_bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 imply usage patterns for querying users, but it does not explicitly state when to use this tool versus alternatives like kingdee_query_role or kingdee_query_permission. No explicit when-not-to-use or comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing state transitions for approve (待审核→已审核) and reject (已审核→反审核). Annotations show destructiveHint=false, which aligns with the reversible nature. No contradictions; the description provides behavioral context not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a summary line, bullet points for actions, and a return note. Every sentence adds value; no redundant or missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, no output schema), the description adequately covers the tool's purpose and usage. It mentions the return JSON with key fields. Could include more detail on error handling or response codes, but sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (form_id, bill_id, action, opinion). The description adds contextual state transition info for action values and clarifies the return structure, slightly enhancing schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool approves or rejects documents, specifies the two actions (approve/reject) with state transitions, and mentions the return structure. It is distinct from sibling query and action tools like kingdee_submit_bills or kingdee_push_and_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for approving or rejecting workflow items but does not explicitly state when to use it versus other action tools like kingdee_submit_bills or kingdee_query_pending_approvals. No alternative guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, idempotent behavior. The description adds minimal behavioral insight beyond return format (JSON) and example filters. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses bullet points for examples, and clearly states the return type. Every sentence serves a purpose, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple query with annotations and output schema, the description sufficiently covers purpose, examples, and return format. No additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for most parameters (high coverage). The description adds value by providing recommended field_keys and filter examples, which help the agent form correct queries beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries production stock-in documents (PRD_Instock) and provides specific filter examples and recommended fields, distinguishing it from generic query tools like kingdee_query_bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete filter_string and field_keys examples, making usage context clear. However, it does not explicitly state when not to use it or compare to sibling query tools, though the specialization is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds that the return is JSON, but does not disclose pagination limits, error handling, or the effect of invalid inputs. Value added is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then explanation, filter examples, field recommendations, and return type. No extraneous information, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 (not shown but indicated), the description covers key aspects: what it does, how to filter, what fields to request, and the return format. It lacks details on pagination defaults or error conditions, which are partially covered by the schema. Overall, 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema by providing specific, context-aware examples for filter_string and field_keys. Schema descriptions are generic, but the tool description gives practical, domain-specific values that help an agent select correct parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the purchase inquiry list (SVM_InquiryBill/RFQ), explaining what RFQ is. It distinguishes from sibling tools like kingdee_query_purchase_orders and kingdee_query_purchase_requisitions by specifying the exact entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete filter_string examples (e.g., '已审核' and '指定供应商') and recommended field_keys, offering practical usage guidance. However, it does not explicitly state when to use this tool versus alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds no behavioral insights beyond stating it returns a JSON list. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence for purpose, brief explanation, and examples. Front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and output schema existence, the description provides sufficient context: purpose, usage examples, and return format. No gaps for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. The description adds value by recommending specific field_keys and providing example filter strings, going beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries sale quotations (SAL_Quotation) and explains their role as price proposals. Specific examples of filters and recommended fields distinguish it from other query tools like kingdee_query_sale_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (querying sale quotations) and gives practical filter examples. However, lacks explicit guidance on when not to use or direct comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 of sequence rules, which is consistent and provides return format context. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: one line for purpose, two example usages, a line for recommended fields, and the return type. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, input schema with parameter descriptions, and an output schema (implied), the description supplements with practical examples and recommended fields. It does not cover error handling or pagination, but those are addressed by schema (start_row, limit). Adequate for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides parameter descriptions in Chinese, but the tool description adds practical examples (e.g., 'FObjectType=\'PUR_PurchaseOrder\'' for filter_string) and recommended field_keys, which enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (编码规则/SequenceRule) and action (查询/query). It provides specific examples of filter_string and field_keys, distinguishing it from other query tools like kingdee_query_bills. The title annotation '查询编码规则' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives common filter_string usage examples and recommends specific field_keys, guiding the agent on effective usage. However, it lacks explicit when-not-to-use or comparison with siblings like kingdee_query_number_rule, but the name and context make it clear this is the dedicated tool for sequence rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds useful behavioral context about the aggregated statistics returned (success/failure counts, time, errors), enhancing transparency beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using bullet points for key statistics. Every sentence is necessary and no redundancy. Front-loads the purpose and clearly explains output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema exists, the description adequately covers the return value format. It lists the statistics included, but does not specify the exact JSON structure. Still sufficient for an agent to understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema fully covers them. The description adds no parameter-specific information, which is appropriate. With 0 parameters, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves usage statistics for the current session, listing specific aggregated metrics. It is distinct from sibling tools which are CRUD or query functions for business entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (when needing session usage stats) but does not explicitly state when not to use or list alternatives. The context makes it clear, but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, etc.). Description adds significant behavioral context: auto-correction of typos, FID handling, and is_delete_entry behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two paragraphs (rules and example) with clear bullet points. Every sentence earns its place. Front-loaded with purpose and rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (create vs. update, auto-correction, 4 parameters) and presence of output schema, the description covers all key aspects and provides a complete usage example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has descriptions for all parameters, but description adds a concrete purchase order model example and clarifies the relationship between FID and is_delete_entry. This supplements the schema well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates or modifies Kingdee documents (e.g., purchase orders, sales orders) with specific verb+resource. It distinguishes from sibling tools like kingdee_audit_bills or kingdee_query_bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear rules: new need no FID, modify must have FID and set is_delete_entry=false. Also mentions auto-correction of field names. Could explicitly mention when not to use (e.g., for asset or production order specific saves) but overall helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent. The description adds valuable context beyond: the data size (up to 100k characters) and how summary mode truncates related fields to Id/Number/Name. This helps the agent understand the output size and behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the main purpose and then explaining modes. Every sentence adds value: the core action, mode details with size comparisons, return type. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read-only view with two modes) and the presence of an output schema (though not shown), the description is complete. It explains when to use each mode, the return type, and size implications. No gaps remain for an agent to effectively invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions already explain form_id, bill_id, and mode. The description reinforces mode's purpose and adds practical context (size reduction, use case). Although schema coverage is high, the description adds value by explaining the summary mode's suitability for creating new bills, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving complete bill details by the internal code FID, including all entry fields. It specifies the resource (bill), action (view details), and key identifier. This distinguishes it from sibling tools like kingdee_query_bills (which lists bills) and kingdee_view_production_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use summary mode (referencing old bills) vs full mode (original JSON), including size implications. It does not explicitly state when not to use this tool or mention alternatives, but the context of siblings and required parameters (form_id, bill_id) implies it is for viewing a specific bill's details. Some explicit guidance on prerequisites would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![KingdeeMCP MCP server](https://glama.ai/mcp/servers/WaHaiLong/KingdeeMCP/badges/card.svg)](https://glama.ai/mcp/servers/WaHaiLong/KingdeeMCP)

Score Badge

Copy to your README.md:

[![KingdeeMCP MCP server](https://glama.ai/mcp/servers/WaHaiLong/KingdeeMCP/badges/score.svg)](https://glama.ai/mcp/servers/WaHaiLong/KingdeeMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/WaHaiLong/KingdeeMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server