sx_build_bill_payload

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

Without annotations, the description carries the full behavioral burden. It explicitly discloses that the tool performs no network calls ('不调用任何接口') and is safe in read-only environments ('只读环境下也可放心使用'). It also mentions validation and serialization, implying no side effects. This is strong disclosure given the absence of annotations.

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?

The purpose is front-loaded in the first sentence, and the example is compact yet comprehensive. The description is efficient, using only the space needed to convey the parameter structure. No extraneous content.

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 description explains what the tool does, what it returns (dataJsonStr), and when it's appropriate to use (manual verification). It covers safety and non-sending behavior. With a single parameter richly exemplified and no output schema required, the description is complete for an agent to correctly invoke the tool.

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?

The input schema has 0% description coverage, so the description must compensate. It does so with a detailed JSON example of the 'bill' parameter, illustrating structure, field types (text, bd, entry), and nesting. This gives the agent concrete guidance on how to construct the input, fully compensating for the schema's lack of detail.

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?

The description clearly states the tool's purpose: '只组装不发送' (only assemble, don't send) and '把单据 dict 校验并序列化成官方 dataJsonStr' (validate and serialize the bill dict into the official dataJsonStr). It explicitly distinguishes itself from sending tools like sx_submit and sx_push, making its unique function immediately apparent.

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?

The description implies usage for pre-submission verification by stating '供人工核对' (for manual verification) and '不调用任何接口' (doesn't call any interface). It clearly communicates that this is not for sending, but it doesn't explicitly name alternative tools for the actual submission step. Still, the context is clear enough for an agent to infer when to use it.

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