edit_table

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

Discloses the critical destructive semantics beyond the annotation: 'The rows given become the table's entire contents: records left out are removed from the model.' This is consistent with destructiveHint=true and far more informative. It also names the lock prerequisite and the return value (CSiBridge's import log).

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?

Front-loads the destructive warning and workflow before the Args block, and each sentence earns its place. Slightly long, but the Args section is justified given 0% schema coverage rather than being 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?

Complete for a destructive mutation tool: destructive scope, prerequisites, workflow, staging behavior, and return value are all covered. The output schema handles the import-log shape, so nothing essential is missing.

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 carries the full burden and does: table_key provenance (from list_tables), fields ordering, rows accepting either positional lists or field-keyed objects (schema types rows items as untyped {}), table_version lookup fallback, and the subtle staged-edit meaning of apply=false.

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?

States a specific verb and resource ('Replace the contents of an editable database table') and immediately contrasts with the read path by naming get_table(for_editing=True) as the prerequisite. An agent can distinguish this from get_table and list_tables without opening any schema.

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?

Gives an explicit read-modify-write workflow: read with get_table(for_editing=True), change, send every row back, and use the returned table_version. It also states the precondition ('The model must be unlocked for most tables') and explains the staged-vs-applied alternative via `apply`.

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