Skip to main content
Write tools take array-shaped arguments (ids, updates), capped at 10 records per call. Records are processed in order and each one reports its own outcome:
Nothing is retried automatically — a partial batch has no transaction behind it, so re-running would reapply the writes that already succeeded. Past the cap the call is refused rather than executed in pieces: a set split across repeated calls has no single confirmation covering it, and a failure halfway through leaves the data half-changed.
No tool accepts a filter to decide what to change. The risk boundary isn’t how many records but who chose the set. Enumerated ids are visible in a confirmation dialog; a filter-defined set could match five records or five thousand, and nobody knows which at call time. “Change every Zillow-sourced lead to Nurture” is therefore not expressible in this tool surface — not refused, but unwritable. A filter-driven bulk tool, when it exists, gets its own scope and a confirmation that runs a count first.
manage_sales_agent’s add_to_pool is the one exception — it has a real batch endpoint underneath, so it accepts a large array outright. It still confirms past 10 (the threshold tier), just without a hard rejection.