create_journal_entry

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

With no annotations, the description carries the burden of disclosure. It provides useful behavioral details: the entry is a draft, move_type is 'entry', and balancing is enforced only on post ('Odoo enforces this on post'). This goes beyond basic create semantics, though it omits return values and error handling.

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 concise, with the main purpose front-loaded in the first sentence. The subsequent lines explanation is dense but necessary for parameter understanding, and there is no redundant content. Slightly less concise due to the structured layout, but overall efficient.

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 adequately explains the tool's function and the critical balancing rule, but lacks information about return values, error conditions, or how to obtain valid IDs (journal_id, account_id). For a create operation with no output schema, this leaves some gaps in actionable understanding.

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 compensate. It thoroughly explains the 'lines' parameter structure, but leaves 'journal_id', 'date', 'ref', and 'company_id' undocumented. Thus only one parameter is given meaningful semantics, while the others rely solely on type names.

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 explicitly states 'Create a DRAFT manual journal entry (move_type='entry')' which clearly identifies the action (create), the resource (journal entry), and the state (draft). This differentiates it from siblings like post_journal_entry or create_invoice, making the purpose 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?

The description implies usage context by emphasizing 'DRAFT' and 'manual', suggesting this tool is for creating draft entries rather than posting or reversing. It does not explicitly name alternatives, but the draft designation provides enough context for when to use it over siblings.

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