wps_et_set_formula

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

With no annotations provided, the description carries full behavioral burden. It explains what happens after writing (ET computes formula), how to interpret results (numeric success, #-prefix errors), and gives Excel-standard semantic clarification for functions like VLOOKUP. A slight deduction because it doesn't mention whether the write is destructive to existing cell content or if multiple writes are idempotent.

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 (two sentences) and front-loads the primary action, then immediately provides critical follow-up instructions. Every sentence adds unique value: first sentence states action and engine, second gives verification protocol and error patterns, with parenthetical adding semantic nuance. Zero waste.

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?

Given no output schema, the description compensates well by explaining what to expect after execution (numeric value vs #-prefix errors). It doesn't explain pagination or batch behavior, but this is a simple single-cell formula write with two required params. Could mention whether the formula must reference existing ranges, but overall complete for typical spreadsheet formula usage.

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 100% (both cell and formula have descriptions). The input schema already documents cell as a string like 'D2' and formula as a string starting with '='. The description adds mild value by giving formula examples (=VLOOKUP(...), =SUMIF(...), =SUMPRODUCT(...)) but doesn't significantly expand beyond schema—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 clearly states the tool writes a formula to a cell (specific verb '向单元格写入公式'), explicitly requires the formula to start with '=', and notes that ET engine performs actual computation. It also distinguishes from nearby Excel functions like wps_et_write_range or wps_et_read_range by focusing on formula writing.

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 explicitly tells users they must call read_range after writing to verify results—this is a mandatory follow-up step. It also lists error patterns (#NAME?, #REF!, #VALUE!) that indicate formula errors, providing clear diagnostic guidance. While it doesn't name explicit sibling tools, the 'must read back' advice is protocol-level usage guidance.

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