transfer_sprint_item_claim

[MAINTENANCE] W1-I — hand a LIVE in_progress claim on a sprint item off to a different actor/session directly, without a reset-to-pending-then-reclaim cycle. The item's status never leaves in_progress, so there is no window where a third session could see it as pending and race to claim it out from under the intended recipient — only actor/claimed_at (and, best-effort, the underlying file/symbol resource locks) move to the new owner. Only the session recorded as the item's current actor may transfer its own claim away — a mismatch is refused (NOT_CLAIM_OWNER) unless force=true is explicitly passed. When to_session_id is given and the item declares touches_resources, each declared file:/symbol: lock is released under session_id and re-acquired under to_session_id via the same claim_file/claim_symbol machinery claim_sprint_item itself uses (a symbol: resource's real AST-range claim is released but not auto-reclaimed — that needs the file's current content, which this call doesn't have; the receiving session should claim_file(symbol=..., content=...) itself for those — while a whole-file lock the claim took for it moves like a file: lock). When to_session_id is the session already holding the locks, only the actor changes and no lock moves. Returns a structured {blocked: true, error: ...} dict (NOT_IN_PROGRESS / NOT_CLAIM_OWNER / SAME_ACTOR / RACE_LOST) rather than raising when it can't proceed; on success returns {item_id, prior_actor, prior_claimed_at, new_actor, transferred_resources, released_only_resources, item}, plus kept_for_sibling_items for locks left with the current session because another of its in_progress items still needs them (never moved out from under it). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets. It is categorised as a Financial tool in the Meridian MCP Server, which means it involves financial transactions. Block by default and require explicit approval.

transfer_sprint_item_claim accepts 8 parameters: force, reason, item_id, to_actor, project_id, session_id, project_name, to_session_id. Required: item_id, to_actor, session_id. 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 transfer_sprint_item_claim: 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.

transfer_sprint_item_claim is a Financial 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 transfer_sprint_item_claim 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 transfer_sprint_item_claim. 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.

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