Problem
Linear's manual sort order (the drag-and-drop position within a Backlog or board view) is stored internally as a sortOrder: Float! field on the Issue type and is the primary way teams rank their backlog. However, the official MCP server does not expose this field in any of its issue tools — neither for reading nor for writing.
Agile teams express their priorities through backlog ordering — the top issue is the most important one. An agent working from the backlog should be able to read that ordering, just like a human developer would. Today it cannot.
This means:
- An AI agent cannot determine which issue sits at the top of the backlog via MCP — the manual order is invisible.
- An agent cannot reorder issues programmatically to reflect prioritization decisions.
- The canonical "pick the highest-priority task and start working" loop — the core of agentic coding workflows — cannot be driven by manual backlog position through MCP.
The read side is the more critical gap: agents need to know the intended work order set by the human. The write side (reordering) is a secondary but valuable addition for agents that act as planning assistants.
Current workarounds and their limits
Teams currently work around this by:
- Relying solely on the
priority enum field (Urgent/High/Medium/Low), which only provides 4 discrete levels and cannot encode relative order within a tier.
- Maintaining a separate
PROGRESS.md or TASKS.md file as a human-curated task list that the agent reads instead of Linear.
- Using Cycles as a bounded work queue, which requires manually moving issues into a cycle before every agent session.
- Calling the GraphQL API directly (bypassing MCP) and handling fractional indexing logic manually.
All of these workarounds add friction and undermine Linear as the single source of truth for agentic workflows.
Proposed changes
1. Expose sortOrder in list_issues and get_issue responses
Return the sortOrder float alongside existing fields so agents can determine relative position:
{
"id": "abc-123",
"title": "Implement login flow",
"priority": 2,
"sortOrder": -1234.5,
"state": { "name": "Backlog" }
}This alone would allow agents to sort a fetched list by sortOrder ascending to determine the intended work sequence — matching what a human sees in the Linear UI when sorted manually.
2. Add a move_issue tool (or extend update_issue) for reordering
Expose a simple positional API so agents don't have to calculate fractional index values themselves:
move_issue(
issueId: "abc-123",
position: "before" | "after",
relativeToIssueId: "xyz-456"
)
The MCP server handles the fractional indexing internally (midpoint calculation between adjacent sortOrder values) and calls issueUpdate with the correct float. The agent works with intent, not floats.
Why this matters for agentic workflows
Linear has positioned itself as a platform for AI agents (see Linear for Agents, Linear Agent, and the Agent Interaction Guidelines). The typical agent loop is:
- Fetch the next task from the backlog
- Read the issue spec
- Implement and open a PR
- Update issue status
- Repeat
Step 1 requires knowing the human-defined work order. Today, any agent using the MCP server cannot reliably determine this without a parallel out-of-band mechanism — which defeats the purpose of having Linear as the source of truth.
Prior art / related
- The
sortOrder field already exists in the GraphQL schema (replacing the deprecated boardOrder) and is readable via direct API queries.
issueUpdate accepts sortOrder as a writable field — the infrastructure is already there.- Issue FEA-9913 (Reminders API) describes a similar pattern: a capability that exists internally but is not yet surfaced to API/MCP consumers.
Scope
- Minimal viable: include
sortOrder as a returned field in list_issues and get_issue
- Full: add a
move_issue tool with before/after semantics
Happy to elaborate or test any proposed implementation.
Problem
Linear's manual sort order (the drag-and-drop position within a Backlog or board view) is stored internally as a
sortOrder: Float!field on theIssuetype and is the primary way teams rank their backlog. However, the official MCP server does not expose this field in any of its issue tools — neither for reading nor for writing.Agile teams express their priorities through backlog ordering — the top issue is the most important one. An agent working from the backlog should be able to read that ordering, just like a human developer would. Today it cannot.
This means:
The read side is the more critical gap: agents need to know the intended work order set by the human. The write side (reordering) is a secondary but valuable addition for agents that act as planning assistants.
Current workarounds and their limits
Teams currently work around this by:
priorityenum field (Urgent/High/Medium/Low), which only provides 4 discrete levels and cannot encode relative order within a tier.PROGRESS.mdorTASKS.mdfile as a human-curated task list that the agent reads instead of Linear.All of these workarounds add friction and undermine Linear as the single source of truth for agentic workflows.
Proposed changes
1. Expose
sortOrderinlist_issuesandget_issueresponsesReturn the
sortOrderfloat alongside existing fields so agents can determine relative position:{ "id": "abc-123", "title": "Implement login flow", "priority": 2, "sortOrder": -1234.5, "state": { "name": "Backlog" } }This alone would allow agents to sort a fetched list by
sortOrderascending to determine the intended work sequence — matching what a human sees in the Linear UI when sorted manually.2. Add a
move_issuetool (or extendupdate_issue) for reorderingExpose a simple positional API so agents don't have to calculate fractional index values themselves:
The MCP server handles the fractional indexing internally (midpoint calculation between adjacent
sortOrdervalues) and callsissueUpdatewith the correct float. The agent works with intent, not floats.Why this matters for agentic workflows
Linear has positioned itself as a platform for AI agents (see Linear for Agents, Linear Agent, and the Agent Interaction Guidelines). The typical agent loop is:
Step 1 requires knowing the human-defined work order. Today, any agent using the MCP server cannot reliably determine this without a parallel out-of-band mechanism — which defeats the purpose of having Linear as the source of truth.
Prior art / related
sortOrderfield already exists in the GraphQL schema (replacing the deprecatedboardOrder) and is readable via direct API queries.issueUpdateacceptssortOrderas a writable field — the infrastructure is already there.Scope
sortOrderas a returned field inlist_issuesandget_issuemove_issuetool with before/after semanticsHappy to elaborate or test any proposed implementation.