invoke_read_tool_batch

Dispatch a bounded, ordered batch of read-only tool calls in one round trip.

Nornir-inspired bounded fan-out: each entry in calls is dispatched sequentially (no concurrency in this version -- deterministic ordering and rate-limit safety over throughput) through the identical read-only gate/response-bounding path invoke_read_tool itself uses. One call's failure never aborts the rest: every call gets its own ordered result entry plus rolled-up aggregate counts, never a raised exception and never a success-shaped failure. A write/destructive/unknown tool named in any entry is rejected for that entry alone and never reaches the backend (same gate as invoke_read_tool).

Args: calls: bounded (max 25) ordered list of call objects, each with required "name" (exact backend tool name from find_tool), optional "arguments" (object, default {}), optional "id" (caller-supplied correlation string, max 100 chars, unique within the batch -- defaults to the call's list index as a string), and optional "cursor" (an opaque next_cursor from a previous truncated single-call or batch-item read of this exact tool+arguments, resumed exactly like invoke_read_tool's own cursor argument). "arguments" is bounded to 20,000 serialized bytes and 8 levels of nesting per call -- an oversized/malformed call entry is rejected with status "invalid_call" before any dispatch is attempted for that entry, and never included in a validation-error message (so a secret placed in "arguments" is never echoed back). Duplicate ids reject the whole batch before any dispatch: correlating results by id is the point of supplying one, and silently returning two entries with the same id would make that impossible.

Rate limiting is charged per backend call, not per batch, so a 25-call batch draws 25 tokens from the same bucket a single invoke_read_tool call draws one from.

Returns "ok" (True only when every call in the batch succeeded -- never True while any failure exists), "results" (ordered list, one entry per call, each with "index", "id", "tool", "server", "status" -- one of "ok", "error", "blocked", "unknown_tool", "invalid_cursor", "invalid_call" -- and either "result" (on "ok") or "error" (bounded to 500 characters, otherwise)), "counts" ("total"/"succeeded"/ "failed"), "failed_ids" and "failed_indexes" (both ordered, one entry per failed call), and "truncated" (True when the response had to be shrunk to fit the configured byte budget -- CENTRALMCP_ROUTER_BATCH_RESPONSE_MAX_BYTES, default 300000). Each item additionally gets its own share of that budget while dispatching, so no single call can consume the whole batch's budget. The returned response is strictly within budget.