update_cell

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses overwrite-before-save behavior, auto-save, precise result-carryover semantics by statement content, and when results are cleared. This is far more transparent than a generic 'update' statement.

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?

Four dense sentences, each earning its place: action, side-effect behavior, intended use, and read-source warning. The most important fact is front-loaded, and the warning is placed at the end without padding.

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?

For a mutation with no annotations and no output schema, the description covers purpose, destructive consequences, result carryover, and a data-loss-prevention read pattern. It only omits return/error behavior, which is not necessary for selecting or invoking the tool correctly.

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 has 0% description coverage and the description does not explicitly define buffer_id or cell_id, though their names are self-explanatory. It adds important semantics for value as the full replacement content—especially the warning about non-truncated reads—so it partially compensates for the missing schema descriptions but not completely.

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?

Opens with 'Replace a cell's value', a specific verb and resource, and immediately conveys the tool's purpose. The follow-up 'Use to fix a broken SQL cell' clarifies when this mutation is relevant, making it easy to distinguish from siblings like get_cell, run_cell, or add_cell.

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?

Provides clear usage context: use it to fix a broken SQL cell, and when editing a long cell, read the full value with get_cell using get_full_content: true rather than a truncated preview. It does not explicitly state when not to use it or name sibling alternatives, so it stops short of a 5.

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