ecount_create_sale

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

With no annotations, the description carries the full burden. It adds valuable behavioral context: rate limit (10초/1회), response structure (success, failed, slipNos, details), and grouping behavior for UPLOAD_SER_NO. It does not mention auth/session requirements or inventory side effects, but the 'actual sales (shipping)' phrasing implies such impacts. It is more transparent than typical.

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 description is compact and well-structured: it starts with the purpose, then the usage condition, then key requirements, and finally rate limit and response format in brackets. Every sentence adds value, with no redundancy or filler.

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 covers the essential context: what it does, when to use it, required fields, grouping behavior, rate limit, and response format. It does not mention array size limits (1-300) or default UPLOAD_SER_NO, but those are in the schema. Given the rich schema and the description's inclusion of response details, it is sufficiently complete for a create 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?

Schema coverage is 100% with descriptions for every field, so the baseline is 3. The description adds meaning by emphasizing that PROD_CD is required, listing key inputs (quantity, unit price, amount), and explaining the UPLOAD_SER_NO grouping mechanism—information that goes beyond the schema's per-field descriptions and clarifies how multiple items form a single slip.

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 it registers actual sales (shipping) slips in ECOUNT, using the specific verb '등록합니다' and resource '판매(출고) 전표'. It distinguishes from sibling tools like ecount_create_sale_order by specifying the condition '주문이 출고되어 매출이 발생했을 때' (when an order is shipped and revenue occurs). This is specific and unambiguous.

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?

It explicitly states when to use: when an order has shipped and sales have occurred. This provides clear contextual guidance. However, it does not explicitly name alternative tools or state when not to use this tool, though the sibling names like ecount_create_sale_order imply the distinction.

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