> ## Documentation Index
> Fetch the complete documentation index at: https://developer.lofty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Bulk writes

> Array-shaped write arguments, capped at 10 enumerated records per call, with a per-record result.

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:

```json theme={null}
{ "results": [
    { "id": "100001", "ok": true },
    { "id": "100002", "ok": false, "error": "lead not found" }
] }
```

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.

<Warning>
  **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.
</Warning>

[`manage_sales_agent`](/mcp/tools/manage-sales-agent)'s `add_to_pool` and `create_plan_tasks` are the two exceptions — both have a real batch endpoint underneath, so they accept a large array outright. They still confirm past 10 (the [threshold tier](/mcp/guides/confirmation-tiers)), just without a hard rejection.