Skip to main content
Glama
WaHaiLong

Kingdee MCP Server

by WaHaiLong

kingdee_refresh_metadata

Read-only

Force a fresh metadata pull for a specified Kingdee form, bypassing cache after structure changes so validation and saving use current field definitions.

Instructions

强制重新从金蝶拉取指定表单的元数据(忽略内存/磁盘缓存),用于表单结构变更后刷新。

返回是否成功及字段数量。刷新后 kingdee_validate_bill / kingdee_save_bill 将使用最新字段定义。

Input Schema

NameRequiredDescriptionDefault
form_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.4

TDQS

A4.1/5.0
Behavior4/5

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

Adds meaningful behavior beyond the annotations: it explicitly bypasses both memory and disk caches, reports success plus field count, and affects subsequent validate/save calls. Annotations already cover the safety profile (readOnly, non-destructive), and nothing here contradicts them — cache refresh is a non-business-data 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?

Three short sentences, front-loaded with the force-refresh/bypass-cache action, then the return and downstream consequences. No filler, though the downstream note could be tightened.

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 so return-shape explanation isn't needed, and the description still mentions success/field count and the effect on related bill tools. The only gap is how to source form_id, which slightly weakens completeness for a metadata-refresh 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 single form_id parameter has 0% schema description coverage, and the description only refers to '指定表单' without explaining the ID format or where to obtain it (e.g., kingdee_list_forms). Baseline for a one-parameter tool with high coverage would be higher; here the gap keeps it at minimum viable.

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?

States a specific verb+resource: force re-fetch form metadata from Kingdee while bypassing memory/disk cache. It also distinguishes this maintenance operation from the query tools by noting the downstream effect on kingdee_validate_bill / kingdee_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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear trigger — 'used to refresh after form structure changes' — which tells the agent when this tool is appropriate. It stops short of naming the alternative (e.g., kingdee_get_fields or kingdee_list_forms) for normal metadata reads, so the routing is implied rather than explicit.

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

Deploy Server

Other Tools