kingdee_query_receipts

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely useful behavior: the default filter silently returns only audited bills (FDocumentStatus='C'), field names vary per 账套, and the response is JSON with count/has_more/data. It does not disclose pagination mechanics (limit ≤100, start_row) or default ordering. Minor inconsistency: the annotation title says 收款单 while the description says 应收单.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and default scope are front-loaded, then bulleted filter recipes and a field dictionary – each block earns its place. There is some duplication: the 账套 field-name warning appears in both the body and inside the schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only filtered query with an output schema present, the description covers purpose, default scope, filter syntax, field semantics, response envelope (count/has_more/data), and the required metadata pre-check. An agent has everything it needs to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although structured coverage is low, the description richly documents filter_string syntax with copy-pasteable examples and explains the field keys (FALLAMOUNTFOR, FNOTAXAMOUNTFOR, FWRITTENOFFSTATUS A/B/C, FOPENSTATUS A/B/C, FISINIT). The limit and start_row pagination parameters are still undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (查询) plus resource (应收单 / AR_Receivable) and pins the underlying form, immediately distinguishing it from generic siblings like kingdee_query_bills. It also explains what the record contains and which financial metrics it feeds, so an agent knows exactly what data shape to expect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives concrete when-to-use recipes (audited-only default, customer, month range, unwritten-off, open, initial-period) and preconditions ('先调用 kingdee_get_fields(\'AR_Receivable\') 确认该账套可用字段'). It stops short of naming which sibling query tool to use when the user wants receivables vs. receipts vs. generic bills.

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