delete_line

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

With no annotations provided, the description carries the full burden. It discloses a critical behavioral trait: 'Nothing is saved until save/validate.' This is valuable because it tells the agent the operation is not persistent until a subsequent save action. It also explains the 'editing' special value behavior. It doesn't mention side effects like whether the row is immediately removed from the UI or if there's a confirmation dialog, but the save disclosure is significant.

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?

Two sentences with no waste. The first sentence states the action and target, the second explains the key parameter and the save behavior. Every word earns its place, and the most important behavioral note (nothing is saved) is front-loaded in the second sentence.

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 has an output schema, so return values are covered elsewhere. The description covers the main action, the line parameter semantics, and the save behavior. However, it doesn't explain the 'scope' parameter, which is optional but could affect behavior. For a UI automation tool with siblings like add_line and click_button, the description is mostly complete but leaves the scope parameter undocumented.

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 explains the 'line' parameter in detail: '0-based row index, or "editing" for the row currently in edition.' This adds meaning beyond the schema's bare anyOf integer/string. However, it doesn't explain 'field' or 'scope' parameters, leaving some gaps. The 'field' parameter is somewhat self-explanatory from the description's example, but 'scope' is not addressed.

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 verb ('Remove a row') and the resource ('one2many/many2many list field'), and gives a concrete example ('order_line'). It distinguishes itself from add_line, its sibling, by describing the deletion action. However, it doesn't explicitly name the sibling alternative, so it's clear but not fully differentiated.

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 when to use it: when you need to remove a row from a list field, and it mentions the 'editing' special value for the row currently in edition. It doesn't explicitly state when not to use it or mention alternatives like set_field or orm_call, but the context is reasonably clear for a UI automation tool.

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