batch_mutate

[SUPPORT] 133bfff6 — run a batch of TRANSACTIONAL mutation entries in ONE call, mixing entry kinds selected per-entry via 'kind': 'sprint_item_pointer' (attach a pointer — same shape as add_sprint_item_pointer: sprint_item_id, source_type, targets, optional label), 'sprint_item_update' (patch an EXISTING sprint item — same shape as update_sprint_item: item_id + at least one patchable field; sprint-item CREATION is not supported here, use execute_batch(operation='sprint_items', ...) or add_sprint_item for that), and (PROFILE-7) 'profile_layer' (upsert one scope_type+scope_id profile layer — same shape as set_profile_layer: scope_type, scope_id, optional fields/reset_fields/provenance/expected_revision; a stale expected_revision surfaces error_code='CONFLICT' with expected_revision/actual_revision in the outcome payload). Reuses the exact same validated apply/compensate logic execute_batch and the single-item tools already use — no separate/duplicated mutation path. mode is REQUIRED: 'all_or_nothing' validates every entry BEFORE mutating anything — any validation failure writes NOTHING (status 'rejected'); a mutation failure partway through rolls back every entry this call already wrote via a compensating delete/revert (status 'failed', per-entry status 'rolled_back'). 'best_effort' processes each entry independently (status 'ok' | 'partial' | 'failed'). idempotency_key is REQUIRED (pass null or "" to explicitly opt out) — a retried call with the identical (project_id, idempotency_key) tuple returns the FIRST call's stored result verbatim (idempotent_replay:true) instead of re-executing. PROJECT ISOLATION: an entry MAY carry its own 'project_id' field, but it MUST match this call's own project_id or the entry is rejected outright — a mutation entry can never target a different project. Returns {status, mode, project_id, idempotency_key, idempotent_replay, created_count, error_count, results:[{index, correlation_key, status, id, outcome, error_code, error_message, retryable}], request_id, committed_count, failures:[...failed results...], rollback_status: 'none'|'rolled_back'|'rejected'} — results is ALWAYS in input order. 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 Destructive tool in the Meridian MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.

batch_mutate accepts 7 parameters: mode, entries, project_id, session_id, max_entries, project_name, idempotency_key. Required: mode, entries, 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 batch_mutate: 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.

batch_mutate is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.

Yes. Add a rate_limit block to the batch_mutate 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 batch_mutate. 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.

batch_mutate 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.