create_material_out

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

The description discloses important behavioral traits beyond the annotation hints: this is job-work memorandum tracking with no real accounting posting, stock is sent out, and it is not a sale. It also documents a known live error ('Voucher date is missing') and the exact remediation using set_period. The only weakness is the cryptic, undefined 'EXTRAPOLATED caveat' reference, which reduces some transparency.

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 front-loaded: purpose first, relationship to sibling second, and error-handling guidance last. Every major point is covered without filler. It loses a point because 'Same EXTRAPOLATED caveat' is opaque and would mean nothing to an agent without access to the sibling tool's full documentation.

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 is strong on purpose, side effects, and known failure recovery, which is a lot of context for a create-type tool with no output schema. However, it is not fully standalone: the 'EXTRAPOLATED caveat' is never explained, and the description does not mention what successful execution returns or confirms. These are meaningful gaps for an agent deciding whether the call succeeded.

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 schema already has 100% description coverage for all parameters, including date format, partyLedger, items, and voucherNumber behavior. The tool description reinforces the godown requirement and the date field error, but it does not add new field-level semantics beyond what the schema provides. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Create a Material Out voucher'. It then defines the exact business purpose — recording stock sent to a job worker for processing — and explicitly distinguishes this from a sale ('not a sale') and from its inbound counterpart ('Mirror of create_material_in'). An agent can confidently tell this tool apart from creation_voucher, create_material_in, and sales-related tools.

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 gives clear context for when to use the tool: when stock is sent out to a job worker for processing, as a memorandum rather than a real accounting transaction. It also names create_material_in as a mirror and notes a recovery path via set_period. However, it does not explicitly enumerate all the alternatives it should not be used for (e.g., sales invoice, delivery note, rejection out), so the guidance is strong but not exhaustive.

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