linear-strict

Overview Schema Source Related Servers Discussions Admin

set_fields

Destructive

Update Linear ticket fields—title, priority, assignee, labels, cycle, project, milestone, parent, due date, estimate, links, relations—resolving names to IDs and applying all changes atomically.

Instructions

Change a ticket's fields other than its content: title, priority, assignee or delegate, labels, cycle, project, milestone, parent, due date, estimate, relations to other tickets, and linked GitHub pull requests. The description changes only through set_state and the workflow state only through set_status. Names are resolved to ids first and the whole call is refused if any is unknown or ambiguous, so nothing is half-applied. Taking a ticket from its current assignee needs take_over; another agent's ticket is refused, and so is one delegated to someone else unless it is assigned to the human this identity acts for (LINEAR_PRINCIPAL_ID): then take_over moves the delegation and a comment records it.

Input Schema

TableJSON Schema

Name	Required	Description
`cycle`	No	Cycle number, "current", "next", or null to remove it from its cycle
`issue`	Yes	Issue identifier (e.g. ENG-123) or UUID
`title`	No
`blocks`	No	Issue identifiers this ticket blocks
`parent`	No	Parent issue identifier, or null
`project`	No	Project name or id, or null
`assignee`	No	Name, display name, email or id, "me", or null to unassign
`delegate`	No	Agent (app) user to delegate to, "me", or null to clear
`due_date`	No	YYYY-MM-DD, or null
`estimate`	No
`link_prs`	No	GitHub pull request URLs to link to this ticket, such as the promotion PR that carried the work to main. Linear's GitHub integration then records where each merged, which the Done gate reads.
`priority`	No	0 none, 1 urgent, 2 high, 3 medium, 4 low
`milestone`	No	Milestone name in the ticket's project (or the project set in this call), or null
`take_over`	No	Required to change a person's assignment to someone else, or to move a delegation off another agent on a ticket assigned to the human you act for
`add_labels`	No	Label names on the team or workspace. Labels are not created here.
`blocked_by`	No	Issue identifiers that block this ticket
`related_to`	No	Issue identifiers to mark as related
`remove_labels`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.0Oct 3, 2026

changedInput schema / properties / take_over / description

Previous value: -"Required to change a person's assignment to someone else"New value: +"Required to change a person's assignment to someone else, or to move a delegation off another agent on a ticket assigned to the human you act for"

Changed1 schema field changedv0.1.1Oct 1, 2026

addedInput schema / properties / link_prs

Added value: +{
+  "description": "GitHub pull request URLs to link to this ticket, such as the promotion PR that carried the work to main. Linear's GitHub integration then records where each merged, which the Done gate reads.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedv0.1.0Sep 27, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations only declaring destructive=true, non-idempotent, and not read-only, the description adds critical behavioral context: names are resolved to IDs first, the entire call is refused if any name is unknown or ambiguous, and nothing is half-applied. It also discloses permission rules around reassignment, take_over, and delegations, which an agent could not infer from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four dense sentences, all of which earn their place: purpose, alternatives, atomic validation behavior, and permission rules for assignment changes. It is front-loaded with the primary action and does not repeat annotation or schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 18 parameters, destructive annotations, an output schema, and 83% schema description coverage, the description supplies the missing high-level context: alternatives, atomic refusal behavior, and reassignment/delegation constraints. It does not need to explain return values because an output schema exists, and it covers the complexity inherent in this mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so most parameters are already documented in the schema. The description lists the mutable field categories but does not add format, syntax, or edge-case meaning beyond what the schema provides for individual parameters. Baseline 3 is appropriate when structured fields carry the parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Change a ticket's fields other than its content.' It then enumerates the field categories and explicitly distinguishes the tool from set_state and set_status, which handle description and workflow state respectively. An agent can identify this as a field-mutation tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description names explicit alternatives and constraints: description changes go through set_state, workflow state through set_status, taking over an assignment needs take_over, and other agents' tickets are refused. It gives clear when-not conditions and routing guidance for an agent's own identity and for the human principal case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.