kingdee-k3cloud-mcp

Server Quality Checklist

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

Latest release: v1.3.2
Disambiguation3/5
Multiple query tools (query_bill, query_bill_json, query_bill_all, query_bill_to_file, query_bill_range) overlap in purpose; an agent must read descriptions to choose correctly. The non-query tools are distinctly scoped, but the query cluster creates ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (query_bill, save_bill, delete_bill, audit_bill), making them predictable and easy to navigate.
Tool Count5/5
15 tools is within the ideal range for an ERP-focused server, covering all major operations without unnecessary bloat or trivial additions.
Completeness5/5
The set covers the full bill lifecycle (save, submit, audit, unaudit, delete), query/selection variants, metadata exploration, and file export, leaving no critical gaps for the stated domain.
Average 4/5 across 15 of 15 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on May 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It merely says 'submit' without mentioning preconditions, whether it's a write operation, potential irreversibility, required permissions, or what state the document transitions to. The lack of behavioral context is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a one-line purpose followed by a clear Args list. It avoids fluff. However, it is quite terse and could benefit from a usage sentence, though that is more a completeness issue than a conciseness one.
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 is a mutation operation with no annotations and an output schema, the description should explain the submission lifecycle, required prior states, and effects. It does not. For an ERP tool, this is insufficient for an agent to make an informed invocation, despite the output schema covering return values.
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 0% description coverage, but the description adds meaningful context: form_id is given with concrete examples, numbers is explained with format and examples, and ids is clarified, including the important constraint that numbers and ids are mutually exclusive. This goes well beyond the bare schema.
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 states a specific verb ('提交' = submit) and resource ('金蝶云星空单据' = Kingdee Cloud documents). This clearly distinguishes it from sibling tools like audit, save, or delete. However, it doesn't explicitly differentiate 'submit' from 'submit for approval' or describe the exact workflow state change, leaving some ambiguity for non-domain users.
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?
There is no guidance on when to use this tool versus alternatives such as audit_bill or save_bill. The description only states what it does, not when to choose it. No exclusion criteria or alternative scenarios are mentioned.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It fails to mention that this is a mutating operation that changes document approval status, nor does it address permissions, reversibility, or side effects. The only behavioral note is the mutual exclusivity of numbers and ids, which is more of a parameter constraint than a behavioral trait.
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, consisting of a single purpose sentence followed by an Args list. It is front-loaded with the main action and avoids wasted words. However, it is very terse and could include a brief usage note without sacrificing clarity.
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?
The description covers purpose and parameters but omits usage guidelines, behavioral impact, and system context. For a mutation tool with no annotations, this leaves significant gaps. The presence of an output schema lessens the need for return-value details but does not compensate for missing safety and usage information.
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, and it does. It explains each parameter: form_id with concrete examples, numbers with comma-separated format, and ids with format and the explicit mutually exclusive relationship to numbers. This adds meaningful semantics beyond the raw 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 uses the specific verb '审核' (audit/approve) with the resource '单据' (documents), clearly indicating the action. It distinguishes from sibling tools like unaudit_bill and query_bill by focusing on the approval operation. Parameter examples like BD_MATERIAL and SAL_SaleOrder further clarify the scope.
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 is provided on when to use this tool versus alternatives such as submit_bill or unaudit_bill. The description simply states the action and parameter details, leaving the agent reliant on sibling names to infer the appropriate context.
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?
With no annotations, the description must disclose effects, permissions, and reversibility, but it only lists parameters. It mentions operation types (禁用/反禁用) but does not explain what happens to the document, whether it requires authorization, or whether the operation can be undone.
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 compact: a one-line summary followed by a structured Args list. Each parameter line conveys necessary details with no redundant text.
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?
The tool is an action-oriented operation with no annotations and only minimal context; the description lacks usage conditions, side effects, and error behavior. While the output schema exists and parameters are covered, the agent is not equipped to understand when this operation is appropriate or what consequences it carries.
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?
Despite 0% schema description coverage, the description comprehensively documents all four parameters with examples (form_id like BD_MATERIAL), common op_number values, and the split/selection rule for numbers vs ids. This adds essential meaning beyond the 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 opens with a clear action: '执行金蝶云星空单据操作（禁用、反禁用等）', specifying the resource (Kingdee Cloud Star documents) and concrete operation types. This distinguishes it from sibling tools like audit_bill/delete_bill, as execute_operation is a generic dispatch for operations such as Forbid/Enable, not covered by those specialized names.
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 is provided on when to choose execute_operation over sibling tools; there are no alternatives mentioned or exclusions. The description only explains parameter values, leaving the agent to infer applicability from examples like Forbid/Enable.
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?
With no annotations, the description carries the full burden. It only lists parameters and examples, but does not disclose side effects, prerequisites, error behavior, or whether the operation is irreversible. 'Push' implies creating a downstream document, but no details are provided.
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 a well-structured docstring with a short purpose line and an Args list. Each parameter is one line, making it easy to scan. Slightly verbose but not excessive; it earns its place.
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 all 9 parameters effectively, and an output schema exists so return values are not needed. However, it lacks usage context and behavioral side effects (e.g., what happens on error, whether it creates a new document or updates). Given the tool's complexity, more context is needed for full completeness.
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 schema has no parameter descriptions (coverage 0%), but the description thoroughly explains every parameter, including examples (form_id: SAL_SaleOrder), relationships (numbers and ids are mutually exclusive), and JSON formatting for custom_params. This fully compensates for the schema 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?
The description clearly states the tool pushes Kingdee Cloud Star documents (e.g., sales order to delivery notice), with a specific verb and resource. This distinguishes it from sibling tools like query_bill or save_bill.
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. The description only explains parameters like '不填则用默认规则' (use default rule if not filled) but does not mention when to prefer this over related operations such as save_bill or execute_operation.
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?
With no annotations provided, the description must disclose behavioral traits. It merely states the action (unaudit) without explaining side effects (e.g., that this is a state-changing operation, requires certain permissions, may fail if already un-audited, or is irreversible). It does not describe the outcome or return value. The parameter constraint about numbers/ids is helpful but does not cover the tool's behavioral impact.
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 single sentence stating the purpose, followed by a formatted Args section. No unnecessary detail or fluff. The parameter documentation is organized with clear examples and constraints, making it easy to scan and understand.
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?
Although an output schema exists (so return value explanation is not required), the description lacks critical context for a mutation tool. It does not differentiate from sibling tools, does not explain when to use it, and does not disclose side effects or prerequisites. For a tool that alters document state, this is a significant gap. The description covers parameters well but omits the broader operational context users need.
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 schema has 0% description coverage, so the description's Args section carries the full burden. It clearly explains each parameter: form_id provides examples (BD_MATERIAL, SAL_SaleOrder), numbers is described as document numbers with comma-separated examples, and ids as internal IDs. It also explicitly states that numbers and ids are mutually exclusive (二选一), which is crucial operational semantics beyond the schema's property 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's function: '反审核金蝶云星空单据' (unaudit Kingdee Cloud Starry Sky documents). It uses a specific verb ('unaudit') and resource (Kingdee Cloud documents), distinguishing it from sibling tools like audit_bill, delete_bill, and submit_bill. The purpose is immediately understandable.
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 explicit guidance on when to use this tool versus alternatives. It does not mention that audit_bill is the inverse operation, nor does it explain scenarios where unaudit_bill is preferred over delete_bill or push_bill. The only usage hint is the parameter constraint that numbers and ids are mutually exclusive (二选一), which is parameter-level rather than tool-level guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'delete' but does not disclose that the operation is likely irreversible, whether it is a soft or hard delete, or whether audited bills can be deleted. This lack of warning is a significant gap for a destructive tool.
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 front-loaded: one primary purpose sentence followed by a compact parameter list. Every sentence earns its place, including the mutual-exclusion note. No wasted words.
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?
For a destructive tool with no annotations and no schema descriptions, the description is incomplete. It omits return values, error behavior, and critical constraints (e.g., cannot delete audited documents). The output schema may define the return shape, but the description does not cover operational context needed for safe use.
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 valuable meaning beyond the bare schema: it provides examples for form_id (e.g., BD_MATERIAL, SAL_SaleOrder), clarifies comma-separated formats for numbers and ids, and explicitly states that numbers and ids are mutually exclusive. This compensates well for the 0% schema 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 '删除金蝶云星空单据' (Delete Kingdee Cloud Galaxy document), which identifies the verb 'delete' and the resource type 'bill/document'. This unambiguously distinguishes it from sibling tools like audit_bill or save_bill, making the purpose specific and clear.
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 say when to use this tool versus alternatives. The purpose implies it is for deleting bills, but no guidance is given on prerequisites (e.g., bill must be unapproved) or exclusions. Usage is implied rather than stated, so it meets the minimum viable level.
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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does mention the auto-wrap behavior for Model keys, which is a positive detail, but it does not disclose permissions, side effects of overwriting data, or error handling. For a mutation tool, this is insufficient.
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 compact: a clear one-sentence purpose followed by a two-item Args list. Each line adds value, from the purpose to the examples and the auto-wrap note. It is front-loaded and free of unnecessary filler.
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 both parameters with examples and explains the create/update nature. With an output schema present, not detailing return values is acceptable. However, it lacks mention of prerequisites (e.g., existing form IDs) or failure modes, leaving minor context gaps.
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 input schema has no parameter descriptions (0% coverage). The description compensates thoroughly by explaining both form_id and model_data, providing a concrete JSON example, and noting the automatic wrapping of data without a Model key. This goes far beyond the bare schema type declarations.
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 '保存金蝶云星空单据（新增或更新）' (save Kingdee Cloud documents, create or update), which specifies the verb and resource. It includes concrete examples of form IDs (BD_MATERIAL, SAL_SaleOrder), distinguishing this from sibling tools like query_bill and submit_bill.
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 creating or updating documents but provides no explicit guidance on when to use alternatives like submit_bill or audit_bill. It lacks exclusion conditions or scenarios where this tool should not be used, relying instead on the tool name and basic 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the record lookup mechanisms (number vs bill_id) and the output scope (all fields), which is helpful. However, it does not mention aspects like potential errors, permission requirements, or read-only behavior explicitly, leaving some gaps for a simple view tool.
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-organized: a one-line summary, a second line stating the capability, and a neat Args section with bullet-like entries. Every sentence adds value, and the front-loaded purpose ensures quick understanding.
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, an output schema exists (so return format is covered), and all three parameters are thoroughly explained. The only minor gap is that the description says 'number and bill_id are mutually exclusive' but does not explicitly state that at least one is required, which could cause slight ambiguity in invocation.
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 schema provides only basic type info with 0% description coverage, but the description fully compensates by explaining form_id (with examples like BD_MATERIAL, SAL_SaleOrder), number (with example), bill_id, and the mutual exclusivity requirement ("number 和 bill_id 二选一"). This is exemplary parameter documentation.
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 views full details of a single record ("查看单条记录的完整详情") and returns all fields ("所有字段信息"), making its purpose specific and unambiguous. However, it does not explicitly differentiate itself from sibling tools like query_bill or query_bill_json, which may also retrieve single records, so it misses the highest score.
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 retrieving a single record's complete details via number or internal ID, but it does not state when to prefer this tool over alternatives such as query_bill, query_bill_all, or query_bill_range. There is no explicit 'use when' or 'use instead' guidance, so it only achieves an implied usage score.
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?
Absent annotations, the description reveals essential behavior: top_count maps to TopRowCount and also acts as page size; limit is only honored when top_count=0; start_row supports pagination via next_start_row. It also states the return type. It does not mention authentication or side effects, but 'query' implies a read-only operation.
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?
Structured as an Args docstring, it front-loads function purpose and uses compact bullet-like entries for each parameter with examples. It is slightly long but every sentence contributes to clarification.
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?
Covers all 7 parameters with semantics and interaction rules, and specifies return format. Since an output schema exists, return values are handled there. The only significant absence is sibling-tool usage guidance, which is already penalized in usage_guidelines.
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?
Schema provides only property names with zero descriptions. The description compensates by explaining form_id common values, field_keys comma-separated format, filter_string and order_string examples, top_count semantics including Kingdee TopRowCount/Limit interaction, start_row pagination, and limit condition.
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 states '查询金蝶云星空单据数据（返回二维数组）' clearly identifying the operation (query), resource (Kingdee Cloud Star documents), and return format (2D array). It differentiates from siblings like query_bill_json (JSON output) and count_bill (count).
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?
Despite thorough parameter explanations, the description never mentions when to prefer query_bill over other sibling tools such as query_bill_json, view_bill, or query_bill_all. There is no alternative guidance or 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?
With no annotations, the description carries the full burden. It discloses streaming behavior (does not accumulate in memory), return format with path/row_count/bytes, partial write on error, truncation at max_rows, and local file output. This is rich behavioral disclosure beyond the schema, though it doesn't mention overwrite 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 structured with an intro, return format, and Args section. While somewhat long, every sentence adds value—purpose, behavior, return format, and parameter semantics. It is front-loaded with purpose and avoids 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 7 parameters, no schema descriptions, and no annotations, the description covers all parameters, return format, error handling, and use case. It lacks only minor details like CSV header specifications, but is otherwise complete.
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 schema has 0% description coverage, so the description fully compensates by explaining each parameter with examples, allowed values, defaults, and truncation behavior. This adds substantial 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 tool auto-paginates and streams query results to a local file, explicitly noting it is for large data exports (over 10k rows). This distinguishes it from sibling tools like query_bill which likely return in-memory results.
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 the tool is suitable for large data volumes (>10k rows) and suggests using the Read tool for spot-checking or pandas/polars for processing. However, it does not explicitly name an alternative query tool for smaller datasets, so it lacks explicit exclusions but provides clear context.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly indicates this is a read-only metadata query ('查询元数据') and explains what information it retrieves (field names, types). It does not go into permissions or side effects, but the query nature is evident and the purpose is well specified.
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 first sentence stating the purpose, a second sentence giving the use case, and a brief Args section. Every sentence earns its place, and the structure is front-loaded with the key 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 simplicity (one parameter, no annotations) and the existence of an output schema, the description is quite complete. It explains what the tool does, why it is useful, and defines the parameter. It lacks mention of limitations or alternatives, but these are not critical for this straightforward metadata query.
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 has one required parameter 'form_id' with no description, but the tool description compensates by explaining that it is the form ID and providing examples such as SAL_SaleOrder, PUR_PurchaseOrder, BD_MATERIAL. This adds significant 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 that the tool queries metadata (field structure information) for Kingdee Cloud Star forms. It specifies the verb '查询' (query) and the resource '元数据' (metadata), distinguishing it from sibling tools that operate on bill data directly.
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 the context of use: to obtain field information for constructing query and save parameters. This makes the tool's use case clear, though it does not explicitly mention alternatives or when not to use it. It is more than implied usage, but lacks explicit exclusions.
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?
无注解，因此描述承担了行为披露责任。说明了返回 JSON 格式、is_exact 字段含义、以及估算与实际行数的关系，还提示了分片查询建议，行为透明性较好。
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?
描述结构清晰，包含用途、返回格式、参数说明，每部分都有实质信息，没有冗余。长度适中，关键信息前置。
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?
在输出 schema 之外补充了返回字段语义（is_exact 含义、estimated_rows 下限），并给出了使用场景和参数示例，对于仅2个参数的轻量计数工具已足够完整。
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?
Schema 本身无属性描述（0% 覆盖），但 Args 部分对 form_id 和 filter_string 都给出了格式说明和具体示例（如表单ID和日期过滤条件），充分补偿了 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?
描述以'估算'这一具体动词开头，明确资源是'某查询条件下的数据行数'，并强调'不返回数据内容'，与 query_bill 等返回数据的兄弟工具形成清晰区分。
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?
说明'用于大数据量查询前的探测'，给出了明确的使用场景；当 is_exact=false 时建议按月/周分片查询，提供了后续操作指导。虽然没有显式点名替代工具，但已隐含与查询类工具的分工。
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?
With no annotations, the description carries full responsibility. It thoroughly explains pagination via start_row and next_start_row, the dual role of top_count (TopRowCount and page size), and the conditional behavior of limit. This exceeds typical transparency for a query tool.
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 well-structured: a one-sentence purpose, a one-sentence distinction, then a clear Args list. Each sentence earns its place, and the parameter details are dense but readable. No filler or 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?
For a 7-parameter tool with no annotations and no schema descriptions, this description is unusually complete. It covers return format, pagination, parameter semantics, and sibling differentiation. The presence of an output schema means the return structure doesn't need further explanation, so the description is sufficient.
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?
Schema coverage is 0%, but the description compensates fully. Every parameter is explained with concrete examples: form_id lists common values, field_keys shows a sample, top_count explains its Kingdee mapping and edge cases, and limit's conditional behavior is clarified. This goes far beyond what the bare schema properties provide.
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 Kingdee Cloud document data and returns JSON format with field names as keys. It explicitly differentiates from the sibling query_bill by highlighting the output format difference, making the purpose specific and distinct.
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 contrasts with query_bill, explaining when the JSON format is preferable. However, it does not list all alternative tools or provide explicit exclusions for when not to use this tool, so it stops short of full usage guidance.
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?
No annotations are provided, so the description fully discloses behavior: it explains chunking, pagination, output modes, the 1MB MCP limit, and error handling (including partial write errors and returned error object). This is comprehensive for a query tool and adds significant value beyond what structured annotations would 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?
The description is structured logically: opening one-liner on purpose, then a concise explanation of slicing/pagination, followed by output formats with clear formatting, and finally a list of args with useful examples. Every sentence earns its place, and the layout makes it easy to skim for key details.
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 (9 parameters, no annotations, but with an output schema), the description covers all necessary aspects: when to use, how it works, input semantics, output formats for both inline and file modes, and error handling. It includes the 1MB constraint and chunking options, making it self-contained and sufficient for an agent to invoke correctly.
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?
Schema description coverage is 0%, but the description compensates by explaining every parameter with colloquial but precise details (e.g., form_id examples 'SAL_SaleOrder', date_field typically 'FDate or FCreateDate', chunk values month/week/day). It also clarifies defaults and the interplay between output_path and return behavior, making all 9 parameters meaningful.
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 states it queries bills over a date range using auto-slicing and pagination, explicitly calling out suitability for cross-month/year queries. This clearly distinguishes it from siblings like query_bill (single-bill queries) and query_bill_all/query_bill_to_file by its unique slicing and chunking behavior.
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 context for when to use the tool ('适合跨月/跨年查询') and distinguishes inline vs. file output based on data span ('output_path 为空时内联返回...适合小跨度；非空时流式落盘，适合大跨度'). While it doesn't explicitly name alternative tools or say when NOT to use it, the guidance is clear enough for basic selection.
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?
No annotations are provided, so the description carries the full burden. It discloses auto-pagination until completion or max_rows cutoff, early termination behavior, the exhausted/next_start_row/hint return flags, and the safety limit. This goes beyond simple read/write hints, offering rich 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: core behavior first, then usage guidance, return format, and parameter definitions. Every sentence earns its place, and the use of sections (返回格式, Args) keeps it scannable without unnecessary 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?
Although an output schema is indicated, the description provides an explicit return format inline, which is valuable. It covers all six parameters, provides usage constraints and alternatives, and explains the 1 MB limit. For a tool with no annotations and a low-coverage schema, this description is complete enough for an agent to invoke correctly.
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 input schema has 0% description coverage, so the description fully compensates by explaining every parameter: form_id (with examples like SAL_SaleOrder), field_keys (comma-separated format), filter_string (example filter), order_string, max_rows (safety default), and page_size (default and recommendation). This adds significant meaning beyond the 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 uses a specific verb '自动翻页查询' (auto-paginate query) with a clear resource 'bill' and scope 'all', distinguishing it from siblings like query_bill (single page) and query_bill_range (date sharding). It clearly explains the pagination behavior and the max_rows safety limit.
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?
Explicitly states the tool is suitable for scenarios estimating ≤ several thousand rows, and for >5000 rows recommends query_bill_to_file or query_bill_range, citing the 1 MB MCP return limit. This gives clear when-to-use and when-not-to-use guidance with named alternatives.
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:

[![kingdee-k3cloud-mcp MCP server](https://glama.ai/mcp/servers/adamzhang1987/kingdee-k3cloud-mcp/badges/card.svg)](https://glama.ai/mcp/servers/adamzhang1987/kingdee-k3cloud-mcp)

Score Badge

Copy to your README.md:

[![kingdee-k3cloud-mcp MCP server](https://glama.ai/mcp/servers/adamzhang1987/kingdee-k3cloud-mcp/badges/score.svg)](https://glama.ai/mcp/servers/adamzhang1987/kingdee-k3cloud-mcp)

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/adamzhang1987/kingdee-k3cloud-mcp'

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