move_work_item
Move a card to another column on the same board — and, with claim:true, pick it up in the same action. The server does this in ONE transaction: it closes the card's open dwell, appends the transition to the history, records you as the handler of the pass the card is now on, and updates the card. ...
This record as markdown: /tools/adrata-starfield-mcp/move-work-item.md
What move_work_item does on Starfield
AI agents use move_work_item to create or update resources in Starfield, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Starfield environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
claim | boolean | — | Pick this card up as part of this move: it records YOU as the handler of the pass the card lands on, and makes you the owner only if the card has no owner. "You |
force | boolean | — | Take over a pass SOMEBODY ELSE IS HOLDING. Requires claim:true and a reason saying why — the reason is the only record that person will have of losing the pass |
dryRun | boolean | — | Defaults to true. Set false for a live move. |
itemId | string | Yes | Card id to move. |
reason | string | — | Required for a live move, and it must be worth reading: a branch name, a PR link, or one line saying what changed and how it was verified. Stored on the transit |
approved | boolean | — | Required true for a live move. |
position | number | — | Sort position within the target column. Omit to append to the end. |
toColumnId | string | Yes | Target column id. Must be a column on the SAME board — get it from get_work_board. |
idempotencyKey | string | — | Required for a live move. Reuse the SAME key on retry; the server replays. |
Parameters from the server's own tool schema.
Why move_work_item is rated Medium
An AI agent can call move_work_item faster than any human can review: one bad instruction and it creates or modifies resources in Starfield by the hundred, each call as confident as the last.
Attacks that exploit this kind of access
The rule that runs move_work_item safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Starfield, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For move_work_item, this is the rule to start with:
move_work_item stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Starfield, apply this rule, and every move_work_item call is checked against it from then on.
Questions about move_work_item
Move a card to another column on the same board — and, with claim:true, pick it up in the same action. The server does this in ONE transaction: it closes the card's open dwell, appends the transition to the history, records you as the handler of the pass the card is now on, and updates the card. Dropping a card into the column it is already in is a REORDER and deliberately does not restamp the stage timer. A card carries TWO people and they are not interchangeable. The OWNER (assignee) is whoever carries the card end to end — the engineer who builds it, and the person a QA bounce sends it back to. The HANDLER is whoever took the pass the card is on right now, which at a QA gate is the tester and nowhere else is usually the owner. claim:true always takes the pass; it takes ownership ONLY of a card nobody owns. So a QA pick-up on an engineer's card leaves the engineer owning it, which is what makes the two-gate flow work at all. This is both halves of the developer loop. Claiming is a parameter and not a second tool on purpose: picking a card up is one act, and a separate "assign" call is the one that gets skipped — leaving a card in an active column with no owner, which is the exact finding the board's unassigned glyph exists to shout about. Governed write: previews by default. A live write requires dryRun:false plus approved:true, a reason, and an idempotencyKey (reuse the SAME key on retry — a duplicate move would read as the card having bounced between columns). It is categorised as a Write tool in the Starfield MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
move_work_item accepts 9 parameters: claim, force, dryRun, itemId, reason, approved, position, toColumnId, idempotencyKey. Required: itemId, toColumnId. The full parameter table on this page comes from the server's own tool schema.
Register the Starfield MCP server in PolicyLayer and add a rule for move_work_item: 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 Starfield. Nothing to install.
move_work_item is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the move_work_item 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 move_work_item. 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.
move_work_item is provided by the Starfield MCP server (@adrata/starfield-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Starfield, and thousands of servers like it.
This server
Across the catalogue