Linear

Attach ONE existing initiative label to an initiative. Takes the initiative id from linear_list_initiatives and the label id from linear_list_initiative_labels - do not transpose them. Labels already on the initiative are untouched. Undone by linear_remove_initiative_label. Use linear_create_initiative_label first if the label does not exist yet.

Add ONE label to an issue without touching the labels already on it. Prefer this over linear_update_issue's label_ids, which REPLACES the whole set: an agent that read a truncated label list and then wrote it back would silently drop the labels it never saw. Reversed by linear_remove_issue_label.

Link a Linear issue to a release. issue_id accepts a UUID OR an identifier like ENG-123; release_id must be a UUID from linear_list_releases. Neither the issue nor the release is otherwise changed. This is the undo for linear_remove_issue_from_release and linear_remove_issue_release_link. To link many issues from a build at once, use linear_sync_release.

Add ONE label to a project without disturbing the labels already on it. The additive alternative to linear_update_project's label_ids, which replaces the whole set.

Attach a project to an initiative. Creates a membership row and changes neither the project nor the initiative; removed by linear_remove_project_from_initiative. The row id this returns is what that removal takes.

Add a Linear project to a roadmap. Needs the roadmap id from linear_list_roadmaps and the project id from linear_list_projects; sort_order is optional. Neither object is otherwise changed. Undo with linear_remove_project_from_roadmap. Prefer linear_add_project_to_initiative for new work - roadmaps are deprecated.

Add a person to a Linear team. Needs a team id from linear_list_teams and a user id from linear_list_users. Linear rejects the call if the person is already a member, if the team is archived or retired, or if the connected account lacks permission to add members. Reversible with linear_remove_team_membership. There is no way to grant team ownership through this tool.

DESTRUCTIVE — archive a cycle. It leaves the team's cycle list and its issues are no longer counted in sprint views; the issues themselves are untouched and keep existing. Linear publishes NO cycleUnarchive, so unlike every other archive Agentic Fabriq exposes, this one has no programmatic inverse: recovery needs a human in the Linear UI. Read the cycle with linear_get_cycle before calling.

DESTRUCTIVE — archive an initiative. It leaves every initiative view; the projects under it survive and stay on their own boards. Restored exactly by linear_unarchive_initiative, which is why this is the removal Agentic Fabriq exposes and initiativeDelete is not.

Archive a Linear initiative status update: it leaves the initiative's visible history but its text, comments and reactions survive. REVERSIBLE - call linear_unarchive_initiative_update with the same id to put it back. Linear offers no way to delete an initiative update outright, so this is the only removal available.

DESTRUCTIVE — archive one Linear issue. It leaves every board, view and search result. REVERSIBLE: linear_unarchive_issue restores it, so you can undo this yourself. Confirm the issue with linear_get_issue first anyway, because both halves leave an audit row. Linear's trash and permanent delete are deliberately not available through Agentic Fabriq at all, and the trash flag on this same mutation is never sent.

Archive one Linear notification, removing it from the connected account's inbox. Needs a notification id from linear_list_notifications. Cheap and fully reversible: linear_unarchive_notification puts it back, and linear_list_notifications with include_archived=true still finds it. Nothing about the underlying issue or project changes. To archive every notification about one issue at once, use linear_archive_notifications_for_entity instead.

Archive every Linear notification about ONE thing at once. Pass EXACTLY ONE of notification_id, issue_id, project_update_id, initiative_id or initiative_update_id - passing none or several is rejected. Note that even notification_id archives the whole group Linear considers related, not just that row; use linear_archive_notification for a single row. Only the connected account's inbox changes. There is no batch undo - linear_unarchive_notification restores one id at a time.

DESTRUCTIVE — archive a project. It leaves every project list and view; the issues inside it survive and keep their other fields. Restored exactly by linear_unarchive_project, which is why this is the removal Agentic Fabriq exposes and projectDelete is not. Linear marks this mutation deprecated in favour of the irreversible projectDelete; it is still public and still the reversible one, so it stays.

DESTRUCTIVE — archive a workspace project status. Every project list loses that column and projects sitting in it must be reassigned. Restored exactly by linear_unarchive_project_status.

DESTRUCTIVE — archive a project status update so it no longer appears in the project's update history. The reversible removal: linear_unarchive_project_update puts it back. Deleting one outright is deliberately not exposed.

DESTRUCTIVE BUT REVERSIBLE. Archive a Linear release so it leaves the pipeline's active list. Nothing attached to it is deleted. Undo with linear_unarchive_release using the same id. Use this instead of linear_delete_release, which trashes the release for eventual permanent deletion. To record that a release was cancelled rather than hide it, move it to a canceled stage with linear_update_release.

DESTRUCTIVE BUT REVERSIBLE. Archive a Linear release pipeline so it and its releases leave the active views. Nothing is deleted. Undo with linear_unarchive_release_pipeline using the same id. USE THIS, not linear_delete_release_pipeline, which trashes every release in the pipeline for permanent deletion and cannot be undone here.

DESTRUCTIVE BUT REVERSIBLE. Archive a Linear release stage. Undo with linear_unarchive_release_stage using the same id. Linear will refuse unless the stage is started-type, has no active releases, has a same-kind sibling, and is not the last non-frozen started stage - a refusal changes nothing, so a failed call is safe. There is no stage delete in Linear's API; this is the only way to remove one.

DESTRUCTIVE BUT REVERSIBLE. Archive a Linear roadmap so it leaves the roadmap list. The projects on it are not affected. Undo it with linear_unarchive_roadmap using the same id. Use this rather than linear_delete_roadmap, which is permanent and also removes every project-to-roadmap link.

DESTRUCTIVE — archive one of a team's board columns. Linear moves the issues sitting in it to another state, so this can change the state of many issues at once, and Linear publishes no workflowStateUnarchive to put the column back. Read the column's occupancy with linear_list_issues before calling.

Create up to 25 issues on one team in a single call, each with its own title and optional description, assignee, state, priority, labels and due date. Purely additive — it only ever adds rows, and each one is individually archivable by linear_archive_issue. Agentic Fabriq caps the batch at 25 regardless of what Linear would accept, so one mistaken call cannot fill a board. Deliberately NOT the counterpart of issueBatchUpdate, which rewrites up to 50 existing issues from one filter and is not exposed at all.

DESTRUCTIVE, NO PER-ISSUE UNDO. Apply one set of changes - state, assignee, project, cycle, priority, estimate, due date or the whole label set - to up to 50 issues you name explicitly by id. Requires confirm='rewrite-every-listed-issue' - that exact string; true, 'yes' and any other wording are refused. There is no filter argument by design: list the ids you got from linear_list_issues or linear_search_issues. label_ids REPLACES the labels on every issue in the list; use linear_add_issue_label to add one without disturbing the others.

Check whether a Linear workspace URL key (the segment in linear.app/<key>) is already in use. Returns a boolean. Works for any key, not just this workspace's.

DESTRUCTIVE, PARTLY IRREVERSIBLE. Mark a Linear release completed. ALWAYS PASS version - without it this completes whatever release is currently the latest started one, which may not be the one you read. The stage can be moved back with linear_update_release, but if the pipeline is scheduled with rollover enabled (the default) the release's open issues are MOVED to the next release and no record says which - check linear_get_release_pipeline first. Use linear_create_release_note to write notes.

Count the projects in a Linear project status - total, private and archived-team counts. Call this BEFORE linear_reassign_project_status or linear_archive_project_status so you know how many projects those will move. Get status ids from linear_list_project_statuses.

Attach a link to a Linear issue with a title, optional subtitle, icon and comment. WARNING - THIS UPSERTS: calling it again with the same url on the same issue OVERWRITES the existing attachment instead of adding one, and you get no error. Check linear_list_attachments first if a link may already be there. http and https only. Use linear_link_url_to_issue instead when you want a plain link that never overwrites.

Post a comment on one Linear issue. Linear notifies every subscriber of that issue and emails anyone the comment @mentions, so a comment can reach people who have never used Agentic Fabriq — treat the body as outbound communication, not as an internal note.

Create a saved Linear view (custom view) over issues. Narrow it with filter_team_id, filter_assignee_id, filter_state_id and filter_project_id - flat ids from linear_list_teams, linear_list_users, linear_list_workflow_states and linear_list_projects. There is deliberately no filter object argument and there will not be one. shared=true makes the view visible to the whole workspace, so leave it unset unless a human asked for a shared view. A view scoped with project_id or initiative_id will not appear in linear_list_custom_views.

Create a new cycle on a team, with a start and an end timestamp. Creating a cycle adds a sprint to the team's board; it moves no issues by itself. Removed by linear_archive_cycle.

Create a Linear document, optionally attached to a project, initiative, issue or team. Additive. Note the asymmetry Linear leaves here: the schema publishes documentUnarchive but NO documentArchive, so there is no reversible removal to pair with this — and documentDelete, the only removal there is, is deliberately not exposed.

Create a workspace custom emoji from an image URL (http or https only). Linear downloads the image itself. The emoji is available to everyone in the workspace and the name must be unique. Deleting it later with linear_delete_emoji breaks every existing reaction that used it.

Add ONE thing to the connected Linear user's sidebar. Pass exactly one of issue_id, project_id, document_id, cycle_id, custom_view_id, label_id, project_label_id, team_id or user_id - passing zero or two is rejected before any call is made, and the error lists the alternatives. The bookmark is private to the connected account; favoriting a colleague does not touch their sidebar. Repeating the same call is safe: Linear returns the existing favorite rather than making a second one.

Create an initiative. Additive: an empty container above projects, archived reversibly by linear_archive_initiative.

Create a Linear initiative label. It is workspace-level and visible to everyone - there is no team scoping - so check linear_list_initiative_labels first rather than creating a near duplicate. is_group=true makes a group header instead of an applicable label; parent_id nests it under an existing group. Note these are a separate taxonomy from issue and project labels.

Nest one Linear initiative under another. parent_initiative_id is the one ABOVE and child_initiative_id is the one BELOW - transposing them builds the hierarchy upside down and nothing will warn you. There is no relation type for initiatives, unlike linear_create_issue_relation: parent-child is the only relation they have. Linear rejects cycles and over-deep nesting. Undone by linear_delete_initiative_relation.

Post a written status update on an initiative with a health rating of onTrack, atRisk or offTrack. TREAT THIS AS OUTBOUND COMMUNICATION: Linear notifies every subscriber and cross-posts to Slack where that integration is configured, and an initiative's audience is normally the widest in the workspace. Requires 'comments:create' for that reason.

Create one Linear issue on a team. team_id is required and is a UUID — call linear_list_teams first, it cannot be derived from the team's key. The issue appears on the team's board immediately and Linear notifies the assignee. Every value is sent as a bound GraphQL variable, so the title and description can contain anything.

Create a new issue label, either on one team or workspace-wide when team_id is omitted. This adds to the workspace's own taxonomy and outlives the agent run that created it; retire it with linear_retire_issue_label, which is reversible.

Create a link between two issues: 'blocks', 'related', 'duplicate' or 'similar'. This is how an agent records that a bug blocks a release or that two reports are the same thing. It creates a pointer and changes neither issue's content, and linear_delete_issue_relation undoes it exactly.

Subscribe the connected Linear account to one entity's notifications. Pass EXACTLY ONE of team_id, project_id, cycle_id, label_id, initiative_id or user_id. user_id means FOLLOW that person - it only ever changes your own inbox, never theirs. Optionally pass notification_subscription_types; Linear publishes no closed list of values, so copy them from an existing subscription via linear_list_notification_subscriptions. To stop notifications later, prefer setting active=false over deleting.

Create a project owned by one or more teams. A project is a container for issues, so creating one is additive and cheap; archiving it later is reversible with linear_unarchive_project. Get team ids from linear_list_teams, a status id from linear_list_project_statuses and label ids from linear_list_project_labels.

Create a project label. Workspace-level taxonomy that outlives the agent run; retire it with linear_retire_project_label, which is reversible.

Create a milestone inside a project. Additive: it adds a checkpoint issues can be attached to and changes no existing issue.

Create a dependency between two projects, optionally anchored to a specific milestone on either side. Creates a pointer and changes neither project's content; undone by linear_delete_project_relation.

Add a project status to the workspace. Workspace-level configuration: every project list in the workspace gains the new column. Removed reversibly by linear_archive_project_status.

Post a written status update on a project with a health rating of onTrack, atRisk or offTrack. TREAT THIS AS OUTBOUND COMMUNICATION: Linear notifies every subscriber of the project, and where the Slack integration is configured it cross-posts the body to the project's channel, so the audience is wider than a comment on one issue. It requires 'comments:create' rather than 'write' for exactly that reason — it is the same class of act as linear_create_comment.

Add an emoji reaction to an issue or a comment. Bounded and reversible by linear_delete_reaction. Shares the 'comments:create' scope with commenting because it is the same class of act — an agent leaving a visible mark on someone else's thread — at a fraction of the noise.

Create a Linear release in a pipeline. name and pipeline_id are required; version, description, commit_sha, stage_id, start_date and target_date are optional. WATCH THE DEFAULT STAGE: omitting stage_id puts the release in the first completed stage for a continuous pipeline and the first started stage for a scheduled one - read linear_get_release_pipeline for the type. Set version if you will later call linear_complete_release, which matches on it.

Create a Linear release note. Supply the pipeline id and EXACTLY ONE coverage shape: either release_ids, or both range_from_release_id and range_to_release_id. A range covers every release created between the two, not just those two. content is markdown and is optional - leave it out on a pipeline that generates notes automatically. Removal is linear_delete_release_note and it is permanent, so this is the cheap direction.

Create a Linear release pipeline. Only name is required. type is 'continuous' (a completed release per sync) or 'scheduled' (issues accumulate into one release you complete). Default stages are created for you. Set rollover_issues_on_completion=false if you do NOT want completing a release to move its open issues onto the next one - Linear defaults that to true and it cannot be undone per release. Reverse with linear_archive_release_pipeline.

Create a Linear release stage in a pipeline. Requires name, pipeline_id, stage_type (planned, started, completed or canceled), color as hex and position. IN PRACTICE ONLY started IS USEFUL - the other three already exist on every pipeline and are unique by type, and asking for a duplicate silently returns the EXISTING stage with success=true rather than erroring, so check the id you get back. Remove a stage with linear_archive_release_stage; there is no delete.

Create a Linear roadmap. PREFER linear_create_initiative - Linear has deprecated roadmaps and this mutation is marked deprecated in the schema. Only use this when the user explicitly asks for a roadmap or is working inside existing roadmaps. name is required; description, colour, owner_id and sort_order are optional. Add projects to it afterwards with linear_add_project_to_roadmap.

Create a Linear team. Only name is required. The fastest way to get sensible settings is copy_settings_from_team_id pointing at an existing team from linear_list_teams - most of Linear's team configuration is NOT exposed as arguments here and can only be inherited that way. If key is omitted Linear derives it from the name. The connected account becomes an owner of the new team. Use linear_update_team to change settings afterwards.

Create a Linear ISSUE template with pre-filled fields. template_type must be 'issue' - project, document and releaseNote templates are refused with an error, because their contents have no documented shape. Omit team_id to make the template global to the workspace. Ids come from linear_list_workflow_states, linear_list_users, linear_list_issue_labels, linear_list_projects and linear_list_cycles.

Store display preferences for a Linear view. preferences and insights are opaque JSON objects - Linear publishes no schema, so copy the shape from an existing view rather than inventing keys. preferences_type must be user or organization; ORGANIZATION writes the workspace-wide default every member sees, so do not use it without a human asking. Linear silently REPLACES any existing preferences for the same view type and scope, and does not return what it replaced. No issue or project is changed.

Add a column to a team's board — a new workflow state of type triage, backlog, unstarted, started, completed or canceled. This is team configuration rather than work: it changes the board every member of that team looks at. Removed by linear_archive_workflow_state.

Check whether a saved Linear view has notification subscribers besides you. Call this BEFORE linear_delete_custom_view or before setting shared=false with linear_update_custom_view: a true here means colleagues lose something they are actively watching, and an agent should stop and ask a human. Returns one boolean and no names.

DESTRUCTIVE — remove a link from an issue. It destroys the attachment row, not the thing it points at: the pull request, dashboard or ticket is untouched, and the link is re-created by linear_link_url_to_issue with the same URL. Loss is bounded to one attachment's title and subtitle.

DESTRUCTIVE AND PERMANENT, NO UNDO ANYWHERE. Delete a Linear comment. Requires confirm='delete-comment-permanently' - that exact string; true, 'yes' and any other wording are refused. Linear publishes no un-delete for comments, in the API or the UI, so this cannot be recovered by anybody. Linear does not restrict this to the comment's author, so it may delete somebody else's words. Use linear_update_comment to correct a comment, or linear_resolve_comment to close a thread.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete a saved custom view. Requires confirm='delete-custom-view-permanently' - that exact string; true, 'yes' and any other wording are refused. No issues are affected, but the filter definition is gone, and for a shared view it disappears for every colleague. Call linear_get_custom_view first to keep a copy of the definition.

DESTRUCTIVE. Move a Linear document and its body to the trash. Requires confirm='delete-document-permanently' - that exact string; true, 'yes' and any other wording are refused. REVERSIBLE while Linear's retention period lasts: call linear_unarchive_document with the same id to restore it. Linear publishes no document archive, so this is the only way to remove a document and there is no safer alternative to prefer.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete a workspace custom emoji. Requires confirm='delete-emoji-and-break-existing-reactions' - that exact string; true, 'yes' and any other wording are refused. Every reaction and comment that used it stops rendering for everyone in the workspace, and re-uploading the image with linear_create_emoji creates a new id rather than repairing them.

Remove one bookmark from the connected Linear user's sidebar. The bookmarked issue, project or document is NOT deleted or changed - only the sidebar entry. Takes the FAVORITE's own id from linear_list_favorites. Re-created by linear_create_favorite with the same target. Linear reports success even if the favorite did not exist, so do not treat success as proof it was there.

DESTRUCTIVE. Move a Linear initiative to the trash, taking its update history and its project links with it; the projects themselves survive. Requires confirm='delete-initiative-permanently' - that exact string; true, 'yes' and any other wording are refused. Linear does not document whether linear_unarchive_initiative restores a TRASHED initiative - it documents that for projects and documents and not for this - so treat this as unrecoverable from Agentic Fabriq. Prefer linear_archive_initiative, which linear_unarchive_initiative definitely reverses.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete an initiative label, removing it from every initiative that carries it. Requires confirm='delete-initiative-label-from-every-initiative' - that exact string; true, 'yes' and any other wording are refused. Prefer linear_retire_initiative_label, which is reversible with linear_restore_initiative_label.

DESTRUCTIVE. Remove one parent-child link between Linear initiatives. Neither initiative is deleted - only the link. Takes the relation id from linear_list_initiative_relations, NOT an initiative id. Re-created by linear_create_initiative_relation with the same two endpoints; call linear_get_initiative_relation first to record them and the sort order, which a re-create does not restore.

DESTRUCTIVE, NO UNDO FROM AGENTIC FABRIQ. Move a Linear issue to the trash together with its description, comments, history and attachments. Requires confirm='delete-issue-permanently' - that exact string; true, 'yes' and any other wording are refused. Nothing in this toolset restores a trashed issue - linear_unarchive_issue does not reach one - so a human has to recover it from Linear's trash in the UI before Linear's grace period expires. Prefer linear_archive_issue, which removes the issue from every board and IS reversible with linear_unarchive_issue.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete an issue label, removing it from every issue that carries it. Requires confirm='delete-issue-label-from-every-issue' - that exact string; true, 'yes' and any other wording are refused. Re-creating the label afterwards does NOT restore the classification - it makes an empty label with a new id. Prefer linear_retire_issue_label, which is reversible with linear_restore_issue_label.

DESTRUCTIVE — remove a link between two issues. It destroys a pointer, not an issue: both issues survive untouched and the link is re-created by calling linear_create_issue_relation with the same two ids and type. Marked destructive because it is the delete half of the pair, not because the loss is unbounded.

DESTRUCTIVE and DEPRECATED BY LINEAR. Delete a notification subscription. Linear's own deprecation notice says to call linear_update_notification_subscription with active=false instead - do that unless a human explicitly asked for the row to be removed. Only the connected account's notifications change. linear_create_notification_subscription re-creates it from the same target, but the configured type list is lost, so read it with linear_get_notification_subscription first.

DESTRUCTIVE. Move a Linear project to the trash. Requires confirm='delete-project-permanently' - that exact string; true, 'yes' and any other wording are refused. The project's issues survive but leave its board, and the project's content, milestones and status updates go with it. REVERSIBLE while Linear's retention period lasts: call linear_unarchive_project with the same id to restore it. Prefer linear_archive_project when the project is simply finished.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete a project label, removing it from every project that carries it. Requires confirm='delete-project-label-from-every-project' - that exact string; true, 'yes' and any other wording are refused. Prefer linear_retire_project_label, which is reversible with linear_restore_project_label.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete a project milestone. Requires confirm='delete-milestone-and-detach-its-issues' - that exact string; true, 'yes' and any other wording are refused. The issues on it survive and stay in the project but lose the milestone, and that grouping cannot be rebuilt. Linear publishes no milestone archive, so there is no safer alternative; use linear_move_project_milestone to move it to another project instead of deleting it.

DESTRUCTIVE — remove a dependency between two projects. Destroys a pointer, not a project; re-created by linear_create_project_relation with the same arguments.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete a project status update and its text. Requires confirm='delete-project-update-permanently' - that exact string; true, 'yes' and any other wording are refused. Prefer linear_archive_project_update, which is reversible with linear_unarchive_project_update, or linear_update_project_update to correct what it says.

DESTRUCTIVE — remove an emoji reaction. The delete half of the reaction pair; re-created by linear_create_reaction with the same emoji. Loss is one reaction.

DESTRUCTIVE. Move a release, its notes and its issue links to Linear's trash; they are destroyed after Linear's retention period. Requires confirm='delete-release-permanently' - that exact string; true, 'yes' and any other wording are refused. linear_unarchive_release probably restores it during that window - Linear documents this for projects and documents but not for releases - so treat recovery as uncertain. Prefer linear_archive_release for a release that is merely finished.

DESTRUCTIVE AND PERMANENT, NO UNDO ANYWHERE. Delete a Linear release note and its whole body. Requires confirm to be exactly 'delete-release-note-permanently'. Linear has no archive or trash for release notes, so nobody can restore it - call linear_get_release_note first to keep the text. Prefer linear_update_release_note to correct a note. The releases it covered are not affected.

DESTRUCTIVE - TRASHES THE PIPELINE AND EVERY RELEASE IN IT for permanent deletion after Linear's retention period. Requires confirm to be exactly 'delete-release-pipeline-and-all-its-releases'. Check linear_get_release_pipeline for the release count first - that is what you are destroying. There is no documented undo; linear_unarchive_release_pipeline only un-archives. An already archived pipeline is trashed rather than skipped. Use linear_archive_release_pipeline instead unless a human explicitly asked for permanent deletion.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete a roadmap and its project links. Requires confirm='delete-roadmap-and-its-project-links' - that exact string; true, 'yes' and any other wording are refused. The projects themselves are not deleted. Prefer linear_archive_roadmap, which is reversible with linear_unarchive_roadmap.

DESTRUCTIVE - DELETES AN ENTIRE TEAM. One call archives the team and schedules for deletion every issue it owns, every cycle, every workflow state, every team label and all of its history. Requires confirm='delete-team-and-all-its-issues' - that exact string; true, 'yes' and any other wording are refused. It can be undone with linear_unarchive_team, which cancels the scheduled deletion - but only until that deletion runs, and Linear does not publish how long that is. After that nothing recovers it, in this toolset or in Linear's UI. Do not call this to tidy up an unused team without a human saying so first.

DESTRUCTIVE AND PERMANENT - DELETES EVERY CYCLE ON A TEAM. One call removes all of the team's cycles, all issue-to-cycle associations and disables cycles for that team. Requires confirm='delete-all-cycles-for-this-team' - that exact string; true, 'yes' and any other wording are refused. There is NO undo, in this toolset or in Linear's UI: Linear publishes no cycle un-archive at all, and re-enabling cycles creates new empty ones. The issues are not deleted, but which sprint each was in is gone for good. Do not call this without a human explicitly asking for it.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete a team's previously used key. Requires confirm='delete-team-key-and-break-old-links' - that exact string; true, 'yes' and any other wording are refused. Old issue identifiers built from that key (OLD-123) stop resolving everywhere they were ever pasted - commits, Slack, documents - and none of that can be repaired. Linear will refuse if you name the team's ACTIVE key.

DESTRUCTIVE AND PERMANENT, NO UNDO. Delete a Linear template. Requires confirm='delete-template-permanently' - that exact string; true, 'yes' and any other wording are refused. Issues and projects already created from it are unaffected. linear_create_template can only rebuild ISSUE templates, so a deleted project or document template cannot be re-created with these tools at all - read it with linear_get_template first.

Delete a stored Linear view-preferences object, resetting that view to its default layout. No issues, projects or documents are affected. If the object was organization-type the reset is visible to the entire workspace, and the id alone does not tell you which it is - read the view with linear_get_custom_view first. Linear reports success even when nothing existed.

Break the sync between a Linear issue and an external tool. Takes the sync ATTACHMENT id from linear_list_attachments on that issue, not the issue id. Nothing is deleted and the issue is unaffected, but there is NO enable counterpart - you cannot turn the sync back on, a human has to do that in Linear or in the other tool. Ask before calling it.

Stop a Linear project syncing with github, jira or slack. Nothing is deleted and the project is unaffected. There is NO enable counterpart - you cannot turn the sync back on, a human has to do it in Linear or in the other tool, so ask before calling this.

Fetch Linear data using a natural-language description instead of a specific tool. Be explicit about the entity, the properties you want, the sort order and the limit - Linear turns your sentence into a GraphQL query and returns whatever that query returned, plus the query itself so you can see what it understood. Reaches only what this connection can already read. Prefer the specific tools (linear_list_issues, linear_get_project, ...) when one fits: they are cheaper, their output shape is stable, and this endpoint is marked internal by Linear and may change.

Find all Linear issue attachments pointing at a URL. Use it to see which issues reference a pull request or a document, and to check whether a link is already attached before calling linear_create_attachment, which OVERWRITES on a duplicate url. Exact string match - a trailing slash counts as a different URL. Paginate with cursor.

Find the Linear issue behind a git branch name. Pass the branch exactly as it appears in the repository (e.g. alice/eng-123-fix-export-timeout). Returns the issue, or NULL if no issue matches - null is a normal answer here, not an error. Use this before commenting on or updating the issue a pull request belongs to.

List Linear issues attached to a Figma file. Pass the file KEY - the segment after /file/ in a Figma URL - not the whole URL. Returns an empty page rather than an error when nothing links to that file. Paginate with cursor.

Read the public details (name, description, icon, developer) of a Linear OAuth application from its client id. Returns nothing secret. Use it to explain what application a client id in a log or an audit record refers to.

Read one attachment by id, with its URL, source type and the metadata the source integration stored on it.

Find the Linear issue an attachment belongs to, from the attachment id. Get attachment ids from linear_list_attachments or linear_find_attachments_for_url. Call this before linear_disable_issue_external_sync so you know which issue you are changing.

Read one comment by id, including whether it has been edited or resolved and who resolved it. Comment bodies frequently carry more sensitive detail than the issue they hang off.

Read one saved Linear view including its filter definition. Takes a custom view UUID from linear_list_custom_views, or the slug id out of the view's URL. This is the only read that reaches a view scoped to a project or initiative. Call it before linear_delete_custom_view to keep a copy of the filter that the delete destroys.

Read one cycle by id, with its dates, progress and position relative to today.

Read a Linear code diff by id - changed file paths, per-file additions and deletions, the change kind (added, modified, renamed, deleted...), totals, and the linked pull request. This is a CODING-SESSION working tree, not a comparison between releases. NO OTHER TOOL HERE PRODUCES A DIFF ID: it must come from a Linear diff URL. An empty files list with non-zero counts means the credential lacks repository access, not that the diff is empty. Linear marks this endpoint internal - it may change without notice.

Read one document in full, including its Markdown body. Document bodies routinely carry specs, incident write-ups and decision records, so this is a read of substantive business content.

Read up to 10 Linear document revision entries INCLUDING the document content at each snapshot. Pass entry ids from linear_list_document_history. More than 10 is refused. Use this to answer 'what did this document say before' - the list tool returns metadata only.

Read a Linear document's history timeline, including AI checkpoints - rows showing when an AI conversation edited the document, which conversation and turn, who invoked it, and whether it hit the draft or the live document. Use this rather than linear_list_document_history when the question is who or what made a change. Does not return the document text; use linear_get_document_history_entries for that.

Read one Linear custom emoji. Accepts EITHER the emoji's UUID or its name, which is unusual for these tools. Use the name to check whether an emoji already exists before linear_create_emoji.

Read one external user (a person who interacted with Linear from outside the workspace) by id. Use it to resolve the external-user id on a notification or on a customer-raised issue. Get ids from linear_list_external_users.

Read one Linear favorite by the FAVORITE's own id from linear_list_favorites - not the id of the issue, project or view it bookmarks. Returns the target, the folder it sits in and its sort position, which are what linear_update_favorite changes.

Read one initiative in full, including its brief, its projects and its most recent update. This is the roll-up view a leadership-reporting agent needs.

Read one Linear initiative label by id. Returns its name, colour, parent group, isGroup flag and its retirement state - retiredAt and retiredBy tell you whether linear_retire_initiative_label has been used on it, which is what decides whether it can still be applied to a new initiative.

Preview what linear_update_initiative_lead_team WOULD do. Returns how many sub-initiatives a cascading change would rewrite and whether the change could alter who can see the initiative. Call this FIRST whenever the change might cascade, and stop and ask a human if visibilityMayChange comes back true. Nothing is modified. It returns counts, not names - page linear_list_initiative_relations if you need the affected initiatives.

Read one Linear initiative-to-project link by the LINK's id from linear_list_initiative_projects - not the initiative id and not the project id. Returns both endpoints and the sort order, which is what linear_update_initiative_project changes.

Read one Linear initiative parent-child link by its relation id from linear_list_initiative_relations. Returns both endpoints - initiative is the PARENT, relatedInitiative is the CHILD - and the sort order. Use it to confirm direction before calling linear_delete_initiative_relation.

Read one Linear initiative status update - the written post, its health rating, its author and the diff against the previous one. Takes an initiative UPDATE id from linear_list_initiative_updates, not an initiative id. To edit an initiative itself use linear_update_initiative; to edit this post use linear_update_initiative_update.

Read one Linear issue in full — description, state, assignee, creator, project, parent, cycle, milestone, labels, relations, attachments, subscribers and dates — together with a PAGE of its comments. ALWAYS check comments.pageInfo.hasNextPage before drawing a conclusion from the discussion: it used to be capped at 50 with no way past it, which meant an agent read a truncated thread and could not tell. Pass comment_cursor to page, or use linear_list_comments. Comments frequently carry more sensitive detail than the issue itself. Accepts either the UUID or the human identifier (ENG-123).

Read one issue label by id, including whether it is a group, its parent group and its owning team.

Return Linear's priority scale as integer/label pairs (0 No priority, 1 Urgent, 2 High, 3 Medium, 4 Low). Lets an agent map the word a human used onto the integer linear_create_issue and linear_update_issue take, instead of guessing.

Read one issue relation by id, with both endpoints and the relation type.

Read one Linear issue-to-release link by the LINK's id (not the issue or release id), returning the issue and the release at each end. Get link ids from linear_list_issue_releases. Call it before linear_remove_issue_release_link to confirm you have the right link.

Get one Linear notification by id. Needs a notification id from linear_list_notifications - no other tool produces one. Returns the same fields as a row of that list. Reading it does NOT mark it read; use linear_update_notification with read_at for that.

Get one Linear notification subscription by id, from linear_list_notification_subscriptions. Shows the target entity, the active flag and the subscriber. Call this BEFORE linear_update_notification_subscription if you intend to change notification_subscription_types: that update REPLACES the whole list, so you need the current one to avoid dropping types.

Read one project in full: description, content, lead, teams, labels, status, health, progress, dates and its most recent status update. linear_list_projects returns the id and the headline fields; this returns the ones a status-report agent actually needs.

Read one Linear project label by id, including whether it has been retired. Get ids from linear_list_project_labels. Check this before linear_add_project_label if a label may have been retired.

Read one project milestone by id, with its target date, status and progress.

Read one Linear project relation (a dependency between two projects or milestones) by id. Get ids from linear_list_project_relations. Read it before linear_update_project_relation so you know which end you are moving.

Read one Linear project status by id. Get ids from linear_list_project_statuses or from the status field on a project returned by linear_get_project.

Read one project status update in full, including the diff against the previous one. Note the name collision in Linear's schema: the QUERY projectUpdate reads a status post, while the MUTATION projectUpdate edits a project. Agentic Fabriq keeps them apart as linear_get_project_update and linear_update_project.

Report how much of Linear's request and complexity budget this credential has left, and when the window resets. Pure diagnostics: it is what lets an agent that has just been rate-limited say how long to wait instead of retrying blindly.

Read one Linear release by UUID or slug id. Returns its version, description, stage, pipeline type, issue count, dates, and its archived and trashed flags. Call this before linear_update_release, linear_complete_release, linear_archive_release or linear_delete_release so you know the current stage and can restore the previous values.

Read one Linear release note by UUID or slug, WITH its markdown body and the full list of releases it covers. This is the only tool that returns the note text. Always call it before linear_update_release_note (which replaces coverage and content) or linear_delete_release_note (which is permanent).

Read one Linear release pipeline by UUID or slug. Returns type (continuous or scheduled), isProduction, rolloverIssuesOnCompletion, autoGenerateReleaseNotesOnCompletion and an approximate release count. Call it before linear_sync_release and linear_complete_release - type and rollover decide what those actually do - and before linear_delete_release_pipeline, whose blast radius is that release count. Stages come from linear_list_release_stages.

Read one Linear release stage by UUID (no slug form exists). Returns its kind, colour, position, frozen flag and pipeline. Check type before calling linear_update_release_stage - only started-type stages are editable - and before linear_archive_release_stage, which has several refusal conditions.

Read one Linear roadmap by id or slug id. Get ids from linear_list_roadmaps. Returns name, description, colour, owner and url but NOT the projects on it - call linear_list_roadmap_projects for those. Roadmaps are deprecated by Linear; prefer linear_get_initiative for current planning.

Read one Linear project-to-roadmap link by the LINK's id (not the roadmap or project id). Get link ids from linear_list_roadmap_projects. Returns which project sits on which roadmap and at what sort position. Call it before linear_remove_project_from_roadmap to confirm you have the right link.

Read one team in full: its key, description, whether cycles are enabled, the cycle length, the timezone, the default state new issues land in and the currently active cycle. linear_list_teams gives the id; this is what tells an agent whether a team runs sprints at all before it tries to file into one.

Get one Linear team membership by id, from linear_list_team_memberships. Returns the person, the team, the owner flag and the sort order. Check the owner flag before trying linear_update_team or linear_delete_team - Linear requires team owner or workspace admin rights for those.

Read one template's metadata by id. The template's stored field payload is deliberately not returned: it is an opaque Linear-internal JSON blob whose shape is undocumented and version-dependent, and nothing an agent does with it would be reliable.

Get the number of unread Linear notifications for the connected account as one integer. No arguments, no paging - use it as a cheap check before calling linear_list_notifications. Linear marks this query Internal, so prefer paging linear_list_notifications if the count ever looks wrong or the call starts failing.

Read one workspace member by id, including whether they are active, a guest, or an admin, and their current status. Reads a colleague's email address, so grant it only to agents that need to identify people rather than merely count them.

Read the connected Linear account's own settings — notification preferences and which categories it has unsubscribed from. Viewer-scoped and read-only; useful for a triage agent deciding whether a notification would actually reach anybody.

Identify the Linear account this connection authenticates as, returning its id, name, email, whether it is a workspace admin, and the workspace it belongs to. The cheapest authenticated query Linear offers — run it first when a connection is behaving unexpectedly.

Read one Linear workflow state (issue status) by id. Returns its type - triage, backlog, unstarted, started, completed or canceled - which is how to tell whether an issue in that state is finished. Names are team-specific and unreliable for that. Get ids from linear_list_workflow_states or from an issue's state field.

Attach a URL to an issue — a pull request, a dashboard, a runbook, a customer ticket. Where the workspace has the matching integration Linear renders it as a rich attachment. NOTE THE UPSERT: Linear keys an attachment on url + issueId, so linking a URL that is already on that issue updates the existing attachment rather than adding a second one. Removed by linear_delete_attachment. Agentic Fabriq never forwards Linear's createAsUser or displayIconUrl arguments on this mutation, so an attachment always carries the connected account's real identity.

List the subset of teams the connected account can administer, as opposed to merely see. Diagnostic: when a team-configuration write fails with a permission error, this is the read that says whether the credential could ever have succeeded.

List every archived Linear team in the workspace, with each team's id, key, name and settings. Use it to find the team id that linear_unarchive_team needs to cancel a scheduled deletion started by linear_delete_team. No arguments and no paging: Linear's field takes none, so the whole archive comes back in one response. Linear marks this query Internal, so treat a failure here as a reason to get the id another way rather than as a bug.

List the distinct attachment sources (github, slack, zendesk, plain links, ...) present on Linear issues, optionally narrowed to one team. Use it to work out which external tools are attached to this workspace's work - Linear's integration list itself is not available to these tools.

List the links attached to issues — pull requests, Sentry events, Zendesk tickets, Figma files and plain URLs — with each attachment's id, title and source. The only read that produces an attachment id, which linear_update_attachment and linear_delete_attachment both require.

List the Linear workspaces the connected account can access or join. Takes no arguments. Note this reaches BEYOND the current workspace and names other organisations the account belongs to. For the connected identity in the current workspace, use linear_get_viewer instead - it is cheaper and does not disclose other workspaces.

List comments with a real cursor, optionally narrowed to one issue, one project or one author. THE ESCAPE FROM A SILENT TRUNCATION: linear_get_issue returns only the first page of comments inline, so on a long-running incident an agent would otherwise read a partial discussion with no way to tell that it had. Page this until pageInfo.hasNextPage is false.

List saved Linear views (custom views) with their ids, names, owners and saved filters. Use this to get the custom_view_id that linear_get_custom_view, linear_update_custom_view, linear_custom_view_has_subscribers and linear_delete_custom_view take. Linear EXCLUDES views scoped to a specific project or initiative from this list - those exist but only linear_get_custom_view reaches them. There is no filter argument; page with page_size and cursor.

List cycles (Linear's sprints) with their ids, numbers, dates, progress and which one is currently active. THE MISSING LINK FOR SPRINT PLANNING: cycle ids are UUIDs, and until this action existed no Agentic Fabriq tool could produce one, so 'put this in the current cycle' and 'what is left this sprint' were both unreachable. Filter to one team, or to just the active/next/previous cycle.

List a Linear document's revision history - snapshot times, the actors involved, and change metadata. Does NOT return the document text; call linear_get_document_history_entries with the entry ids from here to get that, up to 10 at a time. Document ids come from linear_list_documents or linear_search_documents.

List Linear documents with their ids, titles and owning project, initiative or team. Document ids are what linear_get_document and linear_update_document take. Note Linear's schema publishes no public-share mutation for documents, so nothing here can expose one outside the workspace.

List the custom emojis in the Linear workspace, with names and image URLs. Use it before writing :emoji_name: into a comment body - an unknown name is stored as plain text with no error. Also the source of ids for linear_delete_emoji. Paginate with cursor.

List external users - people who created Linear issues or comments from outside the workspace (email intake, support integrations, customer requests) and hold no seat. linear_list_users does NOT include them. Returns names, display names, emails and last-seen times. Paginate with cursor.

List the connected Linear user's sidebar favorites - issues, projects, documents, cycles, saved views, labels, teams and people. Each row carries the favorite's own id, which is what linear_update_favorite and linear_delete_favorite take; that id is NOT the id of the thing being favorited. Only the connected user's own favorites are visible.

List Linear initiative labels with their ids, colours and retirement state. These are a SEPARATE taxonomy from issue labels (linear_list_issue_labels) and project labels (linear_list_project_labels) - the ids do not cross over. Use this to get the label_id that linear_add_initiative_label and the initiative label write tools take. A row with retiredAt set is retired: still on the initiatives that carry it, but not offered for new ones.

List all links between Linear initiatives and projects. Workspace-wide with no filter argument, so page through with page_size and cursor. Each row carries its OWN id, which is what linear_update_initiative_project takes - it is not the initiative id or the project id. Use linear_add_project_to_initiative and linear_remove_project_from_initiative to create and destroy these links.

List all parent-child links between Linear initiatives. This is workspace-wide: there is no filter argument, so page through with page_size and cursor. On each row, initiative is the PARENT and relatedInitiative is the CHILD. This is the only way to get the relation id that linear_update_initiative_relation and linear_delete_initiative_relation take.

List the written status updates posted on initiatives, with health rating, author and body. The read a reporting agent needs before it writes another one.

List initiatives — Linear's layer above projects — with their ids, status, health and target dates. Initiative ids are what every other initiative tool takes, and this is the family Linear added to its own MCP server most recently.

List issue labels with their ids, colours, groups and owning team. THE MISSING LINK: linear_create_issue and linear_update_issue both take label ids, a Linear label id is a UUID that cannot be derived from the label's name, and until this action existed there was no way for an agent to obtain one. Optionally narrowed to one team or to labels whose name contains a string.

List the blocks/related/duplicate links between issues, with each link's id and both endpoints. The only read that produces a relation id, which linear_delete_issue_relation and linear_update_issue_relation both require. Note this is a workspace-wide list with no server-side issue filter — page it, or read one issue's own relations through linear_get_issue.

List issue-to-release links across the whole workspace, paginated. There is NO filter, issue or release argument - Linear publishes none - so finding a specific pair means paging and matching yourself. Only use this when you need the LINK's own id. To unlink an issue from a release, call linear_remove_issue_from_release with the issue and release ids instead; it needs no paging.

List Linear issues, optionally narrowed to one team, assignee, workflow state or project, most-recently-updated first. Returns title, priority, state, team, assignee, project, labels and URL for each. The narrowing arguments are separate ids, not a filter object — Agentic Fabriq assembles Linear's filter from them. Paginates with `cursor`.

List the connected Linear account's notification subscriptions: what it gets notified about, which entity each subscription points at, and whether it is active. This is the tool that produces the subscription id that linear_update_notification_subscription and linear_delete_notification_subscription need. Check the active flag before assuming a subscription is delivering anything.

List the connected Linear account's notifications - the inbox. Returns each notification's id, type, category, title, subtitle, readAt, snoozedUntilAt, archivedAt and a direct inboxUrl. This is the tool that produces the notification id every other notification tool needs. Archived notifications are excluded unless include_archived=true. Listing does not mark anything read. There is no filter argument: page through and filter the rows yourself.

List project labels with their ids and colours. Project labels are a separate taxonomy from issue labels and their ids are what linear_create_project, linear_update_project and linear_add_project_label take.

List project milestones with their ids, target dates and progress, optionally for one project. Milestone ids are what linear_create_issue and linear_update_issue take as project_milestone_id, so without this that field is unusable.

List the dependency links between projects and milestones, with each link's id and both endpoints. The only read that produces a project-relation id, which linear_delete_project_relation requires.

List the workspace's project statuses (Backlog, Planned, In Progress, Completed, Cancelled, Paused and any custom ones) with their ids and types. Status ids are what linear_create_project and linear_update_project take, so this is what makes 'mark this project complete' possible at all.

List the written status updates posted on projects, with their health rating, author and body, optionally for one project. This is the read a reporting agent needs before it writes another one, and the only way to obtain a project-update id.

List Linear projects with their id, name, description, state, progress, start date and target date. Project ids are what linear_list_issues filters on and what linear_create_issue and linear_update_issue accept to place an issue in a project.

List Linear release notes with titles, coverage and generation status, optionally filtered to one pipeline. Does NOT return the note body - call linear_get_release_note for that. generationStatus 'pending' means Linear is still writing it automatically, so an empty body is expected. Paginate with cursor.

List Linear release pipelines - id, name, type (continuous or scheduled), production flag, path patterns and note-generation setting. START HERE: every other release tool needs a pipeline id. Filter with pipeline_type or is_production. Read the type before syncing or completing anything: continuous pipelines create a new release per sync, scheduled ones accumulate into one. Paginate with cursor.

List Linear release stages with their name, kind, colour, position, frozen flag and owning pipeline. Filter by stage_type only - there is NO pipeline filter in Linear's API, so match pipeline.id on the rows yourself. Use the ids with linear_create_release and linear_update_release. Paginate with cursor.

List Linear releases with their version, stage, pipeline, issue count and dates. Narrow with pipeline_id, with stage_type (planned, started, completed or canceled), or with has_release_notes=false to find releases still needing notes. There is no free-form filter argument. Paginate with cursor. Pass include_archived=true to see archived or trashed releases; each row's trashed flag tells the two apart.

List project-to-roadmap links across the whole workspace, paginated. There is NO filter argument - Linear does not publish one - so to find the projects on a specific roadmap you must page through and match roadmap.id yourself. Each row carries the link id you need for linear_reorder_roadmap_project and linear_remove_project_from_roadmap. Prefer the initiative tools; roadmaps are deprecated.

List Linear roadmaps with their names, descriptions, owners and urls. Roadmaps are DEPRECATED by Linear in favour of initiatives - prefer linear_list_initiatives for anything new, and use this only to read planning that already lives on a roadmap. Paginate with cursor. Pass include_archived=true to see archived roadmaps.

List the membership rows joining members to teams, with each row's id, whether that member owns the team, and both sides of the join. This is the only read that produces a team-membership id, which linear_update_team_membership and linear_remove_team_membership both require.

List the Linear teams this connection can see, with each team's id, key (e.g. ENG), name and whether it is private. START HERE: linear_create_issue requires a team_id, and a Linear team id is a UUID that cannot be derived from the team's key. Paginates with `cursor`; pass back `pageInfo.endCursor` for the next page.

List the issue, project and document templates defined in the workspace, with their ids and owning teams. Template ids are what linear_create_issue takes as template_id, so this is what lets an agent file an issue the way the team already files them. Returns the whole set; Linear publishes no pagination on this query.

List Linear templates associated with an integration type. Pass the type string directly - 'slack', 'github', 'jira', 'zendesk'. There is no tool that lists the valid values, so an unknown one simply returns nothing. Use linear_list_templates for the workspace's templates generally.

List Linear workspace members with their id, name, display name, email and whether they are active. This is where an assignee_id comes from: Linear's issue tools take a member UUID, never a name or an email address. Returns colleagues' email addresses, so this is a read of real personal data.

List Linear workflow states (Todo, In Progress, Done, Canceled and any custom ones) with their ids, optionally for one team. Call this before linear_update_issue: an issue is closed by moving it to a state, states are per-team, and their ids are not guessable. Without it an agent can read and comment but cannot move anything.

Mark every Linear notification about ONE thing as read. Pass EXACTLY ONE of notification_id, issue_id, project_update_id, initiative_id or initiative_update_id, plus read_at, a REQUIRED ISO-8601 timestamp such as 2026-08-15T09:30:00Z (Linear has no default for it). Only the connected account's inbox changes. Reversible with linear_mark_notifications_unread_for_entity using the same selector.

Mark every Linear notification about ONE thing as unread. Pass EXACTLY ONE of notification_id, issue_id, project_update_id, initiative_id or initiative_update_id. No timestamp argument - unread means no read time. This is the inverse of linear_mark_notifications_read_for_entity, and the only way to undo a linear_update_notification call that set read_at, though it acts on the whole group rather than the one row.

Move a milestone, and the issues attached to it, into a different project. Reversed by calling it again with the original project id — Linear returns the undo information in the payload.

DESTRUCTIVE - moves EVERY project from one Linear project status to another in a single call. Nothing is deleted. Call linear_count_projects_in_status on both statuses first: you can only undo this by swapping the ids, and that only works if the destination was empty, because afterwards the two sets of projects are indistinguishable. Intended as the cleanup step before linear_archive_project_status.

Detach ONE label from ONE initiative. The label itself is not deleted and stays on every other initiative. Other labels on this initiative are untouched. The exact inverse of linear_add_initiative_label. To stop a label being used anywhere, use linear_retire_initiative_label instead.

DESTRUCTIVE but reversible. Remove an issue from a Linear release using the issue id and the release id. USE THIS rather than linear_remove_issue_release_link, which needs a link id you would have to page an unfilterable list to find. Neither the issue nor the release is otherwise changed. Undo with linear_add_issue_to_release using the same two ids.

Remove ONE label from an issue, leaving every other label alone. The inverse of linear_add_issue_label and trivially undone by it. Detaches a label from an issue; it does not delete the label itself.

DESTRUCTIVE but reversible. Remove an issue from a release using the LINK's id. PREFER linear_remove_issue_from_release, which takes the issue id and release id you already have - the link id this needs only comes from linear_list_issue_releases, which cannot be filtered. Neither the issue nor the release is deleted. Undo with linear_add_issue_to_release.

DESTRUCTIVE — detach a project from an initiative. Destroys the membership row only: the project keeps its issues, its team and its board. Re-created by linear_add_project_to_initiative.

DESTRUCTIVE but reversible. Remove a project from a Linear roadmap by deleting the link. Takes the LINK id from linear_list_roadmap_projects, not the project id - confirm it with linear_get_roadmap_project first. Neither the project nor the roadmap is deleted. Recreate the link with linear_add_project_to_roadmap using the same roadmap and project ids.

Remove ONE label from a project, leaving the others alone. The inverse of linear_add_project_label and undone by it. Detaches the label; it does not delete it.

DESTRUCTIVE. Remove a person from a Linear team using a membership id from linear_list_team_memberships. Requires confirm='remove-this-person-from-the-team' - that exact string; true, 'yes' and any other wording are refused. They lose the team's boards, issues and notifications at once, and this may be a colleague rather than the connected account. Reversible with linear_add_team_membership, which needs the team id and user id - read them with linear_get_team_membership BEFORE calling this, because the id itself is gone afterwards. It removes exactly one membership; parent teams are never touched.

Reorder a project within a Linear roadmap by setting a new sort_order on the link. Takes the LINK id from linear_list_roadmap_projects. This is the ONLY editable field - to move a project to another roadmap use linear_remove_project_from_roadmap then linear_add_project_to_roadmap. Read the current position with linear_get_roadmap_project first so you can put it back.

Reset the connected Linear account's UI flags. Pass the specific UserFlagType names you mean. CALLING THIS WITH NO FLAGS RESETS EVERY FLAG, which makes every dismissed tip and onboarding prompt reappear for the person who owns the account - do not do that unless they asked. Nothing about issues or projects is affected.

Mark a comment thread resolved, which collapses it in Linear's UI. Reversed exactly by linear_unresolve_comment. Nothing is deleted and the thread stays readable.

Un-retire a Linear initiative label so it can be applied to new initiatives again. The exact inverse of linear_retire_initiative_label. Find retired labels with linear_list_initiative_labels - they are the rows with retiredAt set.

Un-retire an issue label so it is offered on new issues again. The exact inverse of linear_retire_issue_label, shipped alongside it so retiring is never a one-way door.

Un-retire a project label. The exact inverse of linear_retire_project_label.

Retire a Linear initiative label: it stops being offered for new initiatives, and every initiative already carrying it keeps it. Reversible with linear_restore_initiative_label. Prefer this over linear_delete_initiative_label, which strips the label from every initiative permanently.

DESTRUCTIVE — retire an issue label. It stops being offered on new issues across the whole workspace and disappears from the label picker, though issues already carrying it keep it. Retiring is Linear's reversible removal: linear_restore_issue_label puts it back. Deleting a label outright is deliberately not exposed.

DESTRUCTIVE — retire a project label so it stops being offered across the workspace. Projects already carrying it keep it. Reversed by linear_restore_project_label; deleting a label outright is deliberately not exposed.

Full-text search across document titles and bodies, ranked by relevance. Capped at 50 results per page because Linear rate-limits its search queries separately. The term is a bound GraphQL variable and is never part of the query document.

Full-text search across Linear issues, ranked by relevance, optionally including comment bodies. Linear rate-limits this query separately at 30 requests per minute, so it returns at most 50 results per page — use linear_list_issues with a team or assignee filter when you know what you are looking for. The search term is sent to Linear as a bound GraphQL variable and never becomes part of the query itself.

Full-text search across project names and descriptions, ranked by relevance. Linear rate-limits its search queries separately, so this is capped at 50 results per page. The search term is sent as a bound GraphQL variable and is never part of the query.

Search Linear releases by name, version or pipeline name. Omit term to get the currently relevant releases ordered started, planned, completed, canceled - the fastest way to answer 'what is shipping'. Optionally restrict to one pipeline with pipeline_id. NOT PAGINATED - limit caps the result at 50 and there is no cursor; use linear_list_releases to walk everything.

Semantic (meaning-based) search across Linear issues, projects, initiatives and documents. Use this when you do not know the exact words used in Linear - it matches on meaning, so 'slow exports' finds 'Report generation times out'. Returns each hit's type and id plus a short identity stub; follow up with linear_get_issue, linear_get_project, linear_get_initiative or linear_get_document for the full record. Restrict with types=['issue'] and cap with max_results (1-50). Use linear_search_issues instead when you know the exact term.

DESTRUCTIVE (bulk) - shift a Linear cycle and EVERY cycle after it on that team by a number of days. Requires confirm='shift-this-cycle-and-every-later-cycle' - that exact string; true, 'yes' and any other wording are refused. Pass a CYCLE id from linear_list_cycles, not a team id. Negative days move them earlier. You can undo it by calling again from the same cycle with the day count negated, as long as nothing else changed meanwhile. To move one cycle only, use linear_update_cycle.

Snooze every Linear notification about ONE thing until a chosen time. Pass EXACTLY ONE of notification_id, issue_id, project_update_id, initiative_id or initiative_update_id, plus snoozed_until_at, a REQUIRED ISO-8601 timestamp such as 2026-08-18T08:00:00Z. The notifications leave the inbox and come back at that moment. Undo early with linear_unsnooze_notifications_for_entity.

DESTRUCTIVE - start a Linear team's upcoming cycle today. This ALSO completes the current cycle early if it has not ended, closing the running sprint on today's date. There is no un-start and no un-complete in Linear's API. Pass the id of a NOT-YET-STARTED cycle from linear_list_cycles with only_next=true; Linear refuses anything else. Do not call this to 'move things along' without being asked.

Subscribe the connected account to an issue so Linear notifies it of changes. Viewer-scoped and reversed exactly by linear_unsubscribe_from_issue. Agentic Fabriq does not forward Linear's userId or userEmail arguments, so this can only ever subscribe the connected account — never sign a colleague up for notifications they did not ask for.

Suggest a name, description and icon for a Linear saved view from the filter it would use. Pass the filter as filter_json - a JSON object, most easily copied from the filterData of an existing view read with linear_get_custom_view. Nothing is created or changed; the three suggested strings come back as text and you must still call linear_create_custom_view yourself to make the view. Linear rate limits this to 30 calls a minute, so do not loop over it, and the suggestion is AI-generated rather than authoritative.

Ask Linear to turn a plain-language prompt into an initiative filter object. IMPORTANT: no other tool here accepts a filter object, so you cannot pipe the result into a listing tool - use linear_list_initiatives with its named arguments for that. What this is good for is showing a human what a prompt would select, and feeding linear_suggest_custom_view_details to get a name for it. Nothing is created or changed.

Ask Linear to convert a natural-language description into its own issue-filter JSON. Returns the filter only - it does not run a search and changes nothing. Useful before creating a saved view with linear_create_custom_view. It does NOT feed into linear_list_issues, which takes named arguments (team_id, assignee_id, state_id, project_id) rather than a filter object; read the suggestion and pick those.

Ask Linear to suggest an issue title from a customer's raw words (ticket body, email, chat transcript). Returns a title string and changes nothing. Use it before linear_create_issue when you have a customer's message and need a title that matches the board's style.

Ask Linear to convert a natural-language description into its own project-filter JSON. Returns the filter only - no search is run and nothing changes. Useful before linear_create_custom_view. It does not feed into linear_list_projects, which takes no filter argument.

Sync a build into a Linear release: give the pipeline id, the commit SHA and the issue identifiers (ENG-123 style) that shipped in it. BEHAVIOUR DEPENDS ON THE PIPELINE - continuous pipelines create a new completed release on EVERY call, so do not retry blindly; scheduled pipelines add the issues to the release already in progress. Check linear_get_release_pipeline for the type. There is no single undo: archive the release, or remove links with linear_remove_issue_from_release.

Record one named event in Linear's product analytics. NO UNDO - Linear publishes no way to delete an event or to read one back, so you cannot check or correct what you sent. Only an event name and an optional session id can be sent; arbitrary event properties are not supported here on purpose. This affects no issue, project or document.

Restore a document that was archived in the Linear UI. Recovery-only: Linear's schema publishes no documentArchive, so nothing Agentic Fabriq exposes can archive a document in the first place. It is here because a restore with no matching removal is the safe half of an asymmetry, not the dangerous one.

Restore an archived initiative. The exact inverse of linear_archive_initiative.

Restore an archived Linear initiative status update. The exact inverse of linear_archive_initiative_update - the post returns to the initiative's history with its comments and reactions intact. List initiative updates with archived rows included to find the id.

Restore an issue that linear_archive_issue removed from the board. This is the exact inverse of archiving and it is why archiving is safe to grant: an agent that archives the wrong issue can put it back itself, with an audit row for both halves, instead of needing a human in the Linear UI. Restores the issue to the state and team it had; it does not recover a trashed or deleted issue, which Agentic Fabriq cannot reach at all.

Restore an archived Linear notification to the connected account's inbox. The exact inverse of linear_archive_notification. Get the id from linear_list_notifications with include_archived=true - the default listing excludes archived rows, so a plain list will never show you a candidate.

Restore an archived project to the project list. The exact inverse of linear_archive_project, shipped in the same migration so archiving a project is never a one-way door.

Restore an archived project status. The exact inverse of linear_archive_project_status.

Restore an archived project status update. The exact inverse of linear_archive_project_update.

Restore an archived Linear release. The documented inverse of linear_archive_release - same id and the release returns to the pipeline. Get the id from linear_list_releases with include_archived=true. It MIGHT also recover a release trashed by linear_delete_release, since Linear calls trashed releases archived, but Linear does not document that and it is not guaranteed - do not treat linear_delete_release as reversible. The returned trashed flag tells you which case you are in.

Restore an archived Linear release pipeline. The inverse of linear_archive_release_pipeline - same id, and the pipeline with its stages, releases and notes returns to the active views. Get the id from linear_list_release_pipelines with include_archived=true. Linear does NOT document this as recovering a pipeline deleted with linear_delete_release_pipeline; do not rely on it for that.

Restore an archived Linear release stage. The inverse of linear_archive_release_stage - same id, and the stage returns to its pipeline. Get the id from linear_list_release_stages with include_archived=true. Archiving is the only way a stage is removed in Linear, so this recovers every removed stage.

Restore an archived Linear roadmap. The inverse of linear_archive_roadmap - same id, and the roadmap returns to the roadmap list. Get the id from linear_list_roadmaps with include_archived=true. This is NOT documented to recover a roadmap removed with linear_delete_roadmap.

Cancel a scheduled Linear team deletion and bring the team back. This is the forward-half undo for linear_delete_team, which archives a team and SCHEDULES its issues, cycles, workflow states, labels and history for deletion - this call cancels that schedule. It only works until the deletion actually runs, and Linear does not publish that window, so call it as soon as a mistaken linear_delete_team is noticed. Find the team id with linear_list_archived_teams.

Re-open a comment thread that was marked resolved. The exact inverse of linear_resolve_comment.

Un-snooze every Linear notification about ONE thing, returning them to the inbox now. Pass EXACTLY ONE of notification_id, issue_id, project_update_id, initiative_id or initiative_update_id, plus unsnoozed_at, a REQUIRED ISO-8601 timestamp. unsnoozed_at records WHEN the snooze was lifted - it is NOT a new snooze deadline, so the notifications come back immediately. The inverse of linear_snooze_notifications_for_entity.

Unsubscribe the connected account from an issue. The exact inverse of linear_subscribe_to_issue, and equally limited to the connected account.

Change an attachment's display title or subtitle. Linear requires a title on every update, so pass the existing one from linear_get_attachment when only the subtitle is changing. The URL itself cannot be changed.

Edit the body of an existing comment. This is a revision, not a deletion: Linear keeps the comment, its thread position and its reactions, and marks it edited. It exists so an agent that posted something wrong can correct it rather than leaving it standing or piling a second comment on top. Deleting comments is deliberately not exposed — removing a colleague's words is moderation, not integration.

Edit a saved Linear view. Named fields change, unnamed fields stay - except the filter: passing ANY of filter_team_id, filter_assignee_id, filter_state_id or filter_project_id replaces the view's whole saved filter, and passing none of them leaves it untouched. shared=false removes the view from every colleague's sidebar; call linear_custom_view_has_subscribers first to find out whether anyone else is using it. This tool cannot re-scope a view to a project or an initiative - Linear marks those fields internal.

Rename a cycle, change its goal, or move its start or end date. Fields not named are left alone. Moving the end date of an active cycle changes what every burn-down chart on that team reports.

Change a document's title, body, owner or attachment. Fields not named are left alone. READ IT FIRST WITH linear_get_document: content REPLACES the whole body rather than merging, so writing a partial body silently discards the rest, and Agentic Fabriq exposes no way to archive or restore a document to soften that.

Move or re-order one Linear sidebar favorite. Only folder_name, parent_id and sort_order can change - there is no way to re-point a favorite at a different entity, so delete and re-create it for that. Takes the FAVORITE's own id from linear_list_favorites, not the id of the bookmarked entity. At least one field must be given.

Change an initiative's name, description, brief, owner, status or target date. Fields not named are left alone; description and content replace rather than merge. Setting the status to Completed or Canceled is how an initiative is closed.

Edit a Linear initiative label - name, description, colour, group flag or parent group. Named fields change and the rest stay. A rename shows up on every initiative carrying the label at once. This tool cannot retire or restore a label: use linear_retire_initiative_label and linear_restore_initiative_label, which are the reversible pair for that. At least one field must be given.

Change which Linear team leads an initiative. mode must be selectedOnly or includeDescendants; includeDescendants ALSO rewrites every editable sub-initiative, so call linear_get_initiative_lead_team_change_impact first to see how many that is and whether the change alters who can see the initiative. Omitting lead_team_id leaves the current lead team alone - this tool cannot clear one. Reversible by setting the previous team back.

Re-order a project within a Linear initiative. sort_order is the only thing this changes; it CANNOT move a project to a different initiative - use linear_remove_project_from_initiative then linear_add_project_to_initiative. Takes the LINK id from linear_list_initiative_projects, not the project or initiative id.

Re-order a child initiative among its siblings under the same parent. sort_order is the only thing this can change - it CANNOT move an initiative to a different parent. For that, call linear_delete_initiative_relation then linear_create_initiative_relation. Takes the relation id from linear_list_initiative_relations, not an initiative id.

Edit a Linear initiative status update. body REPLACES the whole text, so read the current text with linear_get_initiative_update first and send the full corrected version. health must be onTrack, atRisk or offTrack. At least one of the two must be given. The post keeps its comments and reactions and is marked edited. To post a NEW update use linear_create_initiative_update; to edit the initiative itself use linear_update_initiative.

Update one Linear issue, changing ONLY the fields named in the request — anything not named is left exactly as it is. But the fields that ARE named replace rather than merge: setting `description` overwrites the previous description, and setting `label_ids` replaces the whole label set. Moving the issue to a different state_id is how an issue is closed. At least one field must be supplied; an empty update would report success while changing nothing.

Rename or recolour an issue label, move it under a different group, or change its description. Fields not named are left alone. Renaming a label changes it everywhere it is used, which is the whole point but is worth stating.

Change an existing issue link — most usefully its type, e.g. promoting 'related' to 'blocks' once the dependency is confirmed. Re-pointing either endpoint is also possible. Fully reversible by calling it again.

Mark one Linear notification read (pass read_at) or snooze it (pass snoozed_until_at), using ISO-8601 timestamps such as 2026-08-15T09:30:00Z. At least one of the two is required. Needs a notification id from linear_list_notifications. This tool CANNOT mark something unread or unsnooze it - use linear_mark_notifications_unread_for_entity or linear_unsnooze_notifications_for_entity with notification_id, which act on the whole notification group.

Update one Linear notification subscription: active=false pauses it, active=true resumes it. This is Linear's OWN recommended way to stop notifications - prefer it over linear_delete_notification_subscription, which Linear has deprecated. WARNING: notification_subscription_types REPLACES the entire list, so read the current list with linear_get_notification_subscription first or you will silently drop types. The target entity cannot be changed.

Change a project's name, description, brief, lead, status, labels, members, priority or dates. Fields not named are left alone, but the ones that ARE named replace rather than merge: description and content overwrite, and label_ids and team_ids replace the whole set. Moving a project to a 'completed' or 'canceled' status is how a project is closed.

Rename, recolour, re-describe or regroup a project label. Fields not named are left alone.

Rename a milestone, change its description or move its target date. Fields not named are left alone.

Update a Linear project relation - change the dependency type or move either end to a different project or milestone. Read the current values with linear_get_project_relation first, both to know what you are changing and so you can put them back. Prefer this over delete-then-create.

Rename, recolour, reorder or retype a workspace project status. Fields not named are left alone.

Edit a project status update that has already been posted — correct the text or change the health rating. A revision, not a deletion: the post keeps its place, its comments and its reactions, and Linear marks it edited.

Update a Linear release - name, description, version, commit_sha, stage_id, start and target dates, or the recorded started_at and completed_at times. stage_id is what actually moves the release between planned, started, completed and canceled. Read linear_get_release first: description OVERWRITES the existing text, and the old values are how you undo this. This tool cannot trash a release - use linear_delete_release.

DESTRUCTIVE. Move a Linear pipeline's release to a stage BY NAME, without a release id. Prefer linear_update_release, which takes exact ids. Two traps: without version this acts on whatever release is currently latest started or planned, and the stage name is matched loosely (case-insensitive, dashes and underscores treated as spaces). Pass version whenever you know it. If the target stage completes the release, the open-issue rollover cannot be undone.

Update a Linear release note's title, body or coverage. CALL linear_get_release_note FIRST - content REPLACES the entire markdown body and release_ids REPLACES the whole coverage set, and that read is your only undo. Give either release_ids or both range ids, never both shapes. To remove a note entirely use linear_delete_release_note, which is permanent.

Update a Linear release pipeline. Read linear_get_release_pipeline first - team_ids and include_path_patterns REPLACE the existing lists rather than adding to them, and that read is your undo. Linear preserves private teams you cannot see, so the returned team list may not match what you sent. Changing slug_id breaks existing links. Changing type changes how in-flight releases behave.

Update a Linear release stage's name, colour, position or frozen flag. ONLY started-type stages can be edited - check type with linear_get_release_stage first or the call fails. No releases are moved. Renaming a stage changes the name that linear_update_release_by_pipeline matches on, so anything using the old name will stop working.

Update a Linear roadmap's name, description, colour, owner or sort order. Call linear_get_roadmap first: description OVERWRITES the whole existing text, and the old values are what you need to undo this. At least one field must be supplied. Roadmaps are deprecated by Linear - prefer linear_update_initiative.

Update a Linear team's settings. Needs a team id from linear_list_teams and at least one field to change. Two traps: private=false makes every issue the team holds visible to the whole workspace, and changing key re-mints the team's issue identifiers so new issues get a new prefix. Linear requires team owner or workspace admin rights for most changes and will refuse cleanly otherwise. This tool cannot retire or delete a team - that is linear_delete_team.

Set the position of a team in one member's Linear team list, using a membership id from linear_list_team_memberships. Sort order is the ONLY thing this tool changes. It CANNOT promote anyone to team owner - Linear's mutation supports that but this toolset never sends the field, because team ownership is what permits deleting a team. To add or remove somebody from a team, use linear_add_team_membership or linear_remove_team_membership.

Update a Linear template. By default only the name, description, icon, colour and team change. Set replace_issue_fields=true to also replace the template's pre-filled issue fields - that is a WHOLESALE replace, not a merge, so pass every issue_* value you want to keep, and read linear_get_template first. Only issue templates can have their contents rewritten.

Set one of the connected Linear account's UI flags (dismissed tips, onboarding state, desktop-app installed). operation must be clear, incr, decr or lock. flag is a Linear UserFlagType name - an unknown name is rejected by Linear with a message naming it. Affects no issue or project and only the connected account.

Update a Linear user's profile - name, display name, bio, title, timezone, or the status emoji and label. Use linear_get_viewer for the connected account's own user id; Linear will refuse any other user unless this account is a workspace admin. Changes how that person appears on everything they have ever written, so confirm with them first. Cannot change roles or permissions.

Update the connected Linear account's own settings - mark the feed as read up to a timestamp, or turn the changelog, invitation, legal and marketing emails on or off. Get the settings id from linear_get_user_settings. Affects only the connected account. Notification category and channel preferences are not settable here.

Update a stored Linear view-preferences object by its id. preferences and insights are opaque JSON objects and each REPLACES the stored one wholesale, so include every key you want to keep. At least one must be given. Linear rejects the call if the preferences are user-type and belong to somebody else. Use linear_create_view_preferences when no preferences object exists yet.

Rename, recolour, re-describe or reorder one of a team's board columns. The state's TYPE cannot be changed after creation — Linear does not accept it on update — so moving a column between 'started' and 'completed' means creating a new one.