linear-strict

Overview Schema Source Related Servers Discussions Admin

create_issue

File a Linear ticket after overlap checks, with validated sections and parent or project placement so work lands in the right queue.

Instructions

Create a ticket. Before filing, ask whether the work is part of a ticket that already exists: widening that ticket, or filing under it with parent, keeps one change in one place. A new ticket needs a home, parent or project_id, and ends up in a project: a sub-ticket goes in its parent's, and a parent with no project is refused until it has one. A team with no open projects is exempt. Without a parent, the server finds the team's open tickets closest to this one and refuses until you've placed the work: under one of them (parent), into one of them (widen it and file nothing), or apart from all of them (new_because and distinct_from). The result lists what you filed on this team that no agent has taken up; filing a ticket is not doing the work, so see each into a queue. Its description is built from named sections (Observed, Cause, Fix, Done when), checked the same way set_state checks them. Include a Done when section if the ticket will be closed through set_status.

Input Schema

TableJSON Schema

Name	Required	Description
`team`	Yes	Team key, e.g. ENG
`title`	Yes
`parent`	No	The ticket this work is part of, identifier or UUID. A sub-ticket skips the check for close open tickets.
`sections`	No	Description sections to change. Impact is the one plain-language line at the top saying who notices this work (mode replace). Observed lines must be "YYYY-MM-DD · <source: command, SHA or query> · <what it showed>". Done when lines must be checklist items ("- [ ] <check that proves it>"). Open questions changes only through comment kinds ask and answer.
`project_id`	No	The project this ticket belongs to; list_projects gives the ids.
`new_because`	No	Why this work is separate from every close open ticket the server named, in one sentence of at most 300 characters. Posted on the new ticket.
`distinct_from`	No	Each close open ticket the server named, by identifier, that this one is separate from.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.2.0Oct 3, 2026

addedInput schema / properties / distinct_from

Added value: +{
+  "description": "Each close open ticket the server named, by identifier, that this one is separate from.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / new_because

Added value: +{
+  "description": "Why this work is separate from every close open ticket the server named, in one sentence of at most 300 characters. Posted on the new ticket.",
+  "type": "string"
+}

changedInput schema / properties / parent / description

Previous value: -"Parent issue identifier or UUID"New value: +"The ticket this work is part of, identifier or UUID. A sub-ticket skips the check for close open tickets."

addedInput schema / properties / project_id / description

Added value: +"The project this ticket belongs to; list_projects gives the ids."

First observedv0.1.0Sep 27, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations declare the mutating, non-idempotent, non-destructive profile, and the description adds substantial behavior beyond that: the server auto-discovers the team's closest open tickets and refuses until placed, parent-without-project is refused, and the result lists filed tickets no agent has claimed. It also ties section validation to set_state and explains the Done-when/set_status dependency.

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

Conciseness3/5

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

It is front-loaded with the core action, but the remaining prose is a long run-on chain of dependent clauses ('A new ticket needs a home... and ends up in a project...') that is harder to parse than necessary. Every sentence carries useful information, so it is not padding, but the structure could be tighter.

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

Completeness4/5

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

For a 7-param, mutating tool with conditional server-side refusals, the description covers the branching logic, required sections, and return summary well; an output schema exists so return values need no explanation. It leaves only minor gaps such as the exact shape of the refusal response, which is acceptable.

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

Parameters4/5

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

Schema coverage is already 86%, so baseline is 3, but the description adds real meaning on top: new_because is capped at 300 characters and posted on the ticket, distinct_from names the server-named tickets, and Done when sections must be checklist items. Only marginal gaps remain for `team`/`title`/`project_id` semantics, which the schema covers.

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

Purpose4/5

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

Opens with a specific verb+resource ('Create a ticket'), and the rest of the text clearly delineates it from siblings like comment, set_status and set_state by describing filing semantics. It is unambiguous for an agent, though the purpose statement is buried under a dense block of constraints rather than front-loaded crisply.

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?

Gives explicit when-to-use branches: widen an existing ticket, file under one with `parent`, or file apart using `new_because`/`distinct_from`. It also states the exemption (team with no open projects), the refusal conditions, and the requirement that a parent with no project is refused. This is a full decision tree, not vague guidance.

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