list_my_work_items
The cards that are YOURS, across every board in the workspace, ordered the way a developer actually picks: escalated first (the top band of each card's OWN scheme — a P1 is never equated with a Critical), then by the board's own left-to-right flow so the earliest active stage comes first, then lo...
This record as markdown: /tools/adrata-starfield-mcp/list-my-work-items.md
What list_my_work_items does on Starfield
AI agents call list_my_work_items to retrieve information from Starfield without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
limit | number | — | Cap each list. Defaults to 50; a queue that needs a second page is not a queue. |
boardId | string | — | Narrow to one board. Omit for every board. |
includeUnassigned | boolean | — | Also return the cards nobody owns and nobody is handling — the pool that is genuinely free. Use it when your own queue is empty, instead of pulling whole boards |
Parameters from the server's own tool schema.
Why list_my_work_items is rated Low
Even though list_my_work_items only reads data, uncontrolled read access leaks sensitive information and racks up API costs: an agent caught in a retry loop can make thousands of calls a minute without anyone noticing.
Risk signalsBulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
The rule that runs list_my_work_items 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 list_my_work_items, this is the rule to start with:
list_my_work_items is read-only, so it stays allowed. 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 list_my_work_items call is checked against it from then on.
Questions about list_my_work_items
The cards that are YOURS, across every board in the workspace, ordered the way a developer actually picks: escalated first (the top band of each card's OWN scheme — a P1 is never equated with a Critical), then by the board's own left-to-right flow so the earliest active stage comes first, then longest-waiting. Cards in a terminal column (Production, Deep backlog) sink to the bottom, because nothing should be picked up from them. "Yours" is TWO things: cards you OWN (you are the assignee, carrying it end to end) and cards whose CURRENT PASS you hold (you took it at a stage — the QA case). Both appear here, and each card carries assignee and handler so you can tell which of the two put it in front of you. A QA person owns none of the cards they are testing, so a queue keyed only on the assignee would tell them they had no work while four cards sat on their bench. "You" is resolved from the authenticated token. There is deliberately NO parameter naming a user, and the endpoint refuses one rather than ignoring it — otherwise one agent could read another developer's queue through the very tool meant to keep them off each other's cards. To see somebody else's work, read their board with get_work_board. Start here for "what should I work on". With includeUnassigned it also returns the cards nobody owns AND nobody is handling, which are the ones free to take (move_work_item with claim:true). It is categorised as a Read tool in the Starfield MCP Server, which means it retrieves data without modifying state.
list_my_work_items accepts 3 parameters: limit, boardId, includeUnassigned. 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 list_my_work_items: 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.
list_my_work_items is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the list_my_work_items 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 list_my_work_items. 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.
list_my_work_items 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