batch_update_party
Update 1–50 parties in parallel with a single request. Use for mass owner reassignment, bulk metadata corrections, and other homogeneous multi-record writes. Returns per-item results and a summary.
Instructions
Update 1–50 parties in parallel. Same input shape as update_party but wrapped in an items array. Use this — not N sequential update_party calls — for any homogeneous multi-record write (mass owner reassignment, bulk metadata corrections, etc.). Capsule has no batch-write API, so the connector fans out parallel HTTP requests with a default concurrency cap of 5 (configurable via CAPSULE_MCP_BATCH_CONCURRENCY). Returns { results: [{ok, ...} per item], summary: {total, succeeded, failed} }. Partial failures are possible — Capsule has no rollback, so successful items stay applied even if other items 4xx. Read the per-item result array to know which ones need follow-up.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Array of 1–50 update_party inputs. Each item is the same shape as a single update_party call — id is required, every other field is optional. Capped at 50 so a single tool call can't burn an outsized share of Capsule's hourly per-token rate budget (~4000 req/h). |