execute_batch

[SUPPORT] 627187b8 — run a HOMOGENEOUS batch of management writes (all entries the SAME operation) with real atomic-or-independent semantics. Every entry in entries is validated and reported individually — no guessing whether a partial write happened. operation selects the entry shape: • sprint_items — create new sprint items. Each entry needs a non-empty 'title' plus any add_sprint_item kwarg (version, group, human_id, depends_on, priority, touches_resources, ...). Every entry's own 'action' (if present) must be 'create'. • item_updates — patch existing sprint items. Each entry needs a non-empty 'item_id' plus at least one patch_sprint_item field to change (title, status, notes, priority, ...). Every entry's own 'action' (if present) must be 'update'. • pointers — attach generic pointers (see add_sprint_item_pointer). Each entry needs 'sprint_item_id', 'source_type', 'targets' (+ optional 'label'). • notes — file sprint notes (see add_sprint_note). Each entry needs 'title' and 'body' (+ optional 'session_id' — falls back to this call's own top-level session_id when omitted — and 'note_kind'). Any entry MAY carry a 'correlation_key' (any non-empty string) echoed back on its result for reconciliation; every result also carries its 0-based input 'index' regardless. mode is REQUIRED and controls failure semantics: 'all_or_nothing' validates every entry BEFORE mutating anything — if any entry fails validation, NOTHING is written (status 'rejected'); if a mutation fails partway through, every entry this call already wrote is rolled back via a compensating delete/revert (status 'failed'). 'best_effort' processes each entry independently — one entry's failure never blocks the others (status 'ok' | 'partial' | 'failed' depending on how many succeeded). idempotency_key is REQUIRED (pass null or "" to explicitly opt out of idempotency protection for this call) — a retried call with the identical (project_id, operation, idempotency_key) tuple returns the FIRST call's stored result verbatim (idempotent_replay:true) instead of re-executing, making retries safe even for all_or_nothing batches that already wrote and rolled back once. Returns {status, mode, entry_kind, operation, project_id, idempotency_key, idempotent_replay, created_count, error_count, results:[{index, correlation_key, status, id, outcome, error_code, error_message, retryable}]} — results is ALWAYS in input order regardless of processing order. Each result status is 'ok' (mutated), 'error' (validation or mutation failure — see error_code/error_message/retryable), 'rolled_back' (succeeded, then undone by a later all_or_nothing failure), or 'not_attempted' (never reached because an earlier entry aborted the batch). max_entries caps this call (default 100); exceeding it is rejected before anything is attempted. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata are sent to and stored in Meridian's service; self-hosted deployments keep them in the configured local SQLite/Postgres database. This data is visible in the dashboard/API and later project context or handoffs. Delete individual tasks, notes, or decisions where supported, or delete the project/account using the documented controls. Do not include secrets. It is categorised as a Execute tool in the Meridian MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.

execute_batch accepts 8 parameters: mode, entries, operation, project_id, session_id, max_entries, project_name, idempotency_key. Required: mode, entries, operation, idempotency_key. The full parameter table on this page comes from the server's own tool schema.

Register the Meridian MCP server in PolicyLayer and add a rule for execute_batch: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Meridian. Nothing to install.

execute_batch is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.

Yes. Add a rate_limit block to the execute_batch rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for execute_batch. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

execute_batch is provided by the Meridian MCP server (@meridianmcp/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.