kdy_get_reimb_detail

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

No annotations are provided, so the description carries the full burden. The description explicitly labels the operation as '只读' (read-only), which is critical behavioral information. It also mentions the API endpoint. However, it does not disclose return format, potential errors, or that the operation is safe (though read-only implies it). Overall, it provides essential transparency for a simple 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.

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

Three short sentences contain only essential information: purpose, API endpoint, and parameter guidance. No fluff, and the key semantic distinction (which parameter to use) is front-loaded. Perfectly concise for a simple lookup tool.

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

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

The tool is simple with two optional string parameters and no output schema. The description provides the API path and parameter semantics, which covers the core usage. However, it omits any indication of what the response contains (e.g., full reimbursement record details) or whether the input must be exactly one of the two parameters (though it says '择一传入'). Given the tool's simplicity, this is still fairly complete.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does so clearly: reimb_id is the internal document code, number is the document number, and it explicitly notes that either one should be passed ('择一传入'). This adds meaning far beyond the schema's bare property definitions, making parameter usage clear.

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

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

Description clearly states the action (查询报销单详情) and resource (reimb_detail), and adds '只读' to distinguish it as a read-only operation. The API endpoint is explicitly provided, making the purpose unambiguous and distinct from sibling tools like kdy_list_expense or kdy_fill_reimbursement.

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

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

Provides guidance on parameter usage: states that reimb_id is the internal code and number is the document number, and advises that either one should be passed based on sandbox testing. However, it doesn't explicitly mention when to use this tool versus the similar list tools (e.g., kdy_list_expense), though the 'detail' nature implies singular retrieval.

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