Which integrations are available for this server?

Integrates with Linear to provide tools for retrieving ticket details, listing assigned issues with filtering, adding comments, creating issues, and fetching teams.

How do I use Linear MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Linear MCP Server show my open issues" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Linear MCP Server

by larryhudson

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Linear MCP Server

Overview

This project implements a Model Context Protocol (MCP) server that acts as a bridge between Claude and the Linear task/issue management system. It allows Claude to interact with Linear through the following tools:

get_ticket - Retrieve detailed information about a specific Linear ticket
get_my_issues - List issues assigned to the current user with filtering by state
add_comment - Add comments to Linear tickets
create_issue - Create a new issue in Linear
get_teams - Retrieve available teams for reference

Related MCP server: Linear MCP Server

Installation

No direct installation is needed. The package will be automatically downloaded and used by your Claude integration when configured properly.

Usage

Obtain a Linear API key from your Linear account settings - click 'New API key' under 'Personal API keys'.
Configure the MCP server in your code editor as shown below.

Using with VS Code

One click install:

Install with VS Code Install with VS Code Insiders

Add this to your settings JSON file:

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "linear_api_key",
        "description": "Linear API Key",
        "password": true
      }
    ],
    "servers": {
      "linear": {
        "command": "npx",
        "args": [
          "-y",
          "@larryhudson/linear-mcp-server"
        ],
        "env": {
          "LINEAR_API_KEY": "${input:linear_api_key}"
        }
      }
    }
  }
}

Using with Cursor IDE

Add this to the MCP config JSON file:

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@larryhudson/linear-mcp-server"],
      "env": {
        "LINEAR_API_KEY": "<YOUR_API_KEY>"
      }
    }
  }
}

Using with Claude Desktop App

Add this to your MCP configuration JSON file:

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "@larryhudson/linear-mcp-server"
      ],
      "env": {
        "LINEAR_API_KEY": "<YOUR_API_KEY>"
      }
    }
  }
}

Using with Cline VS Code Extension

Add this to the MCP config JSON file:

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@larryhudson/linear-mcp-server"],
      "env": {
        "LINEAR_API_KEY": "<YOUR_API_KEY>"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Environment Variables

LINEAR_API_KEY - Your Linear API key (required)

How It Works

The server is built on the following key technologies:

Model Context Protocol (MCP) - Framework for allowing AI assistants to interact with external tools and APIs
Linear SDK - Client library for communicating with the Linear API
Node.js - JavaScript runtime environment
Zod - Type validation library for tool parameters

Key Features

Ticket Retrieval

Gets comprehensive ticket details including status, priority, assignee, and team
Fetches the full description and all comments
Processes Markdown content with embedded images
Downloads and includes images from ticket descriptions

Issue Listing

Retrieves issues assigned to the current user
Filters by state (active, backlog, completed, canceled, or all)
Returns a formatted table with key information about each issue

Comment Addition

Allows adding new comments to existing tickets
Provides confirmation of successful comment creation

Technical Implementation Details

Image Handling
- Extracts image URLs from Markdown using regular expressions
- Downloads images to a local temp directory
- Converts images to base64 for inclusion in MCP responses
- Uses MD5 hashing of URLs to create unique filenames
Linear API Integration
- Authenticates using a Linear API key
- Retrieves issues, tickets, comments, and user information
- Formats data for human-readable display
Error Handling
- Gracefully handles API errors, missing tickets, and download failures
- Provides meaningful error messages to the user

Running the Server

The server communicates with Claude through standard input/output (stdio) using the MCP protocol. It requires:

A Linear API key (configured in the code)
Node.js runtime environment
The dependency packages specified in package.json

Project Structure

This is a relatively simple Node.js application with a single main source file (index.ts) that defines the MCP server, tools, and associated helper functions. It uses TypeScript for type safety and better developer experience.

Dependencies

@modelcontextprotocol/sdk: Core MCP implementation
@linear/sdk: Linear API client
dotenv: Environment variable management
node-fetch: HTTP client for image downloads
zod: Schema validation for tool parameters

Limitations and Potential Improvements

There's limited pagination support for large result sets (currently limited to 20 issues)
Error handling could be improved for various edge cases
The image downloading could benefit from better MIME type detection
Consider adding more tools for managing issues (updating status, changing assignees, etc.)
Support for attachments when creating issues or adding comments

Available Tools

6 tools

add_commentA

Add a comment to a Linear ticket

ParametersJSON Schema

Name	Required	Description	Default
`comment`	Yes	The comment text to add
`ticket_id`	Yes	The Linear ticket ID (e.g., LAR-14)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It discloses the basic write action but omits any side effects, permission requirements, or return behavior, making it insufficiently transparent for a mutation tool.

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

Conciseness5/5

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

The description is a single, well-formed sentence with no wasted words, immediately conveying the tool's purpose.

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

Completeness3/5

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

While the simple schema is fully covered, the lack of an output schema and absence of any return-value or prerequisite information leaves the description incomplete for a tool that creates data. A bit more context would be helpful.

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

Parameters3/5

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

The input schema fully describes both parameters (ticket_id with example, comment text), so the description adds no additional semantic value; the baseline of 3 applies.

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

Purpose5/5

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

The description clearly states the action ('Add') and the target ('a comment to a Linear ticket'), which is specific and distinct from sibling tools like get_ticket or create_issue.

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

Usage Guidelines3/5

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

The description implies usage for adding comments to existing tickets but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., ticket must exist).

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

create_issueB

Create a new Linear issue

ParametersJSON Schema

Name	Required	Description
`title`	Yes	The title of the issue
`team_id`	Yes	The Linear team ID (required)
`priority`	No	Priority level (0-4): 0=No priority, 1=Urgent, 2=High, 3=Medium, 4=Low
`assignee_id`	No	The ID of the user to assign (optional)
`description`	No	The description of the issue (optional)
`parent_issue_id`	No	Parent issue identifier (e.g., LAR-14) to create this as a sub-issue (optional)

TDQS

B3.1/5.0

Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely restates the action from the name, providing no details on authentication, side effects, idempotency, or return behavior. For a mutation tool, this is a significant transparency gap.

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

Conciseness4/5

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

The description is a single concise sentence with no unnecessary words. It is efficient but not notably exceptional; it simply states the action without adding context that would require more structure.

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

Completeness2/5

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

The description lacks any mention of return values or post-conditions, and no output schema is present to fill that gap. While the parameter schema is complete, a create tool would benefit from stating what it returns (e.g., created issue object) or any prerequisites beyond the required schema fields.

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

Parameters3/5

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

The input schema covers 100% of parameters with descriptive comments, so the description itself adds no additional parameter meaning beyond what the schema already provides. Baseline score of 3 is appropriate; the schema does the heavy lifting.

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

Purpose5/5

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

The description 'Create a new Linear issue' uses a specific verb and resource, clearly indicating the action. It distinguishes well from sibling tools like get_ticket, search_issues, and add_comment, which are all read or comment operations.

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

Usage Guidelines3/5

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

The description implies usage—if you want to create a Linear issue, use this tool—but does not explicitly state when to use it versus alternatives or mention any exclusions. It lacks explicit guidance like 'use for new issues only' or 'prefer this over search_issues for creation.'

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

get_my_issuesB

Get your assigned Linear issues

ParametersJSON Schema

Name	Required	Description	Default
`state`	No	Filter by issue state (active, backlog, completed, canceled, all)	active

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get your assigned Linear issues' without mentioning read-only status, authentication requirements, pagination, sorting, or possible limitations. For a get operation, the behavior is mostly implied, but the lack of explicit detail about side effects or safety is a gap.

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

Conciseness5/5

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

The description is a single, concise sentence that is front-loaded with the core purpose. There is no redundant information or filler. It earns its place with clear, direct language.

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

Completeness3/5

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

The tool is simple with one optional parameter and no output schema, so the description's brevity is somewhat appropriate. However, it does not mention what the returned data contains (e.g., issue titles, statuses, links) or any response format. Since the agent must select and invoke the tool correctly, the description is minimally adequate but leaves room for ambiguity about output structure and edge cases.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameter 'state' is fully documented in the schema with an enum and default value. The description adds no additional semantic context beyond the schema, which is acceptable given the schema's completeness. Baseline of 3 applies.

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?

The description 'Get your assigned Linear issues' uses a specific verb ('Get') and resource ('assigned Linear issues'), clearly indicating it retrieves issues assigned to the current user. It distinguishes from siblings like 'search_issues' (which searches all issues) and 'get_ticket' (which retrieves one ticket), though not explicitly. Clarity is strong, but differentiation could be more explicit.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'search_issues' or 'get_ticket'. The description does not mention context, prerequisites, or exclusions. With sibling tools present, this lack of usage direction leaves the agent to infer the use case from the name alone.

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

get_teamsB

Get available Linear teams

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. However, it does not explain what 'available' means, what the response contains (e.g., team names, IDs, objects), or any potential edge cases. For a read operation, more detail about the returned data would be expected.

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

Conciseness5/5

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

The description is a single, short sentence that conveys the core purpose with no fluff or redundancy. It is appropriately sized for the simplicity of the tool.

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

Completeness2/5

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

Given the lack of output schema and annotations, the description is too sparse to provide complete context. It does not mention the return format, whether it lists all teams or just the user's teams, or any other behavioral details that would help the agent use the tool correctly.

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?

The tool has zero parameters, so the definition automatically deserves a baseline of 4. There is no parameter information to add, and the schema is empty, so the description is not expected to explain parameter syntax or semantics.

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

Purpose5/5

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

The description clearly states the verb 'Get' and the resource 'available Linear teams', making it obvious what the tool does. It also distinguishes itself from sibling tools like get_ticket and search_issues by focusing on teams rather than tickets or issues.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The description simply states the action without providing context about prerequisites or use cases, so the agent must infer usage.

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

get_ticketA

Get a Linear ticket by ID

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes	The Linear ticket ID (e.g., LAR-14)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. 'Get' clearly indicates a read operation, but no additional behavioral details (e.g., return format, error handling, rate limits) are disclosed. For a simple get-by-ID tool, this is adequate but minimal.

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

Conciseness5/5

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

The description is a single, focused sentence. Every word earns its place, with no fluff or repetition.

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?

Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description is sufficient to convey its core function. It could mention that the full ticket object is returned, but this is largely implied by 'Get' and the tool's purpose.

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

Parameters3/5

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

The input schema fully documents the ticket_id parameter with an example. The description adds no new semantic information beyond what the schema already provides, making this a baseline score.

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

Purpose5/5

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

The description clearly specifies the action (Get) and resource (Linear ticket by ID). It is easily distinguishable from siblings like get_my_issues, search_issues, and create_issue, which cover other retrieval and creation scenarios.

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

Usage Guidelines3/5

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

The tool's purpose implies usage when a specific ticket ID is known, but no explicit guidance is given about when to use this instead of search_issues or get_my_issues. Usage context is implied rather than stated.

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

search_issuesC

Search for Linear issues with various filters

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of issues to return (default: 20)
`status`	No	Status name to filter by (e.g., 'Todo', 'In Progress')
`is_unassigned`	No	Filter for unassigned issues (true) or assigned issues (false)
`team_identifier`	No	Team identifier (e.g., 'ENG' for Engineering)
`is_current_cycle`	No	Filter for issues in the current cycle

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description alone bears the burden of behavioral disclosure. It only claims 'search' (implying read-only) but does not describe matching behavior, sorting, pagination, or what fields are returned—significant gaps.

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

Conciseness4/5

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

One sentence, front-loaded, and free of filler. However, 'various filters' is vague, and the sentence is efficient but lacks substance, so it does not reach a perfect score.

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

Completeness2/5

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

Given 5 parameters, no output schema, and no annotations, the description is far too thin. It omits search behavior details, return format, and relationship to sibling tools, making the tool difficult to use correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents all parameters. The phrase 'various filters' adds no specific parameter semantics beyond the schema.

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?

The description uses a specific verb ('Search') and resource ('Linear issues') with a general indication of filters, which helps distinguish from get_ticket (single ticket) and get_my_issues (personal scope). However, it does not enumerate filter types, leaving some ambiguity.

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

Usage Guidelines2/5

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

No guidance on when to choose search_issues over get_my_issues or get_ticket, nor any exclusions or prerequisites. The implied usage is broad, but the description offers no explicit context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.4Aug 2, 2026
- First observedadd_comment
- First observedcreate_issue
- First observedget_my_issues
- First observedget_teams
- First observedget_ticket
- First observedsearch_issues

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation4/5

Each tool has a distinct purpose: fetching a specific ticket, listing assigned issues, adding comments, creating issues, listing teams, and searching. The only potential overlap is between get_my_issues and search_issues, but the descriptions clearly separate the convenient personal view from general-purpose search.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, such as get_ticket, add_comment, and create_issue. The verbs are varied but appropriate, and the naming style is uniform throughout.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose. It includes the key operations for reading, creating, searching, and commenting on issues, plus team listing, without unnecessary bloat or missing core basics.

Completeness3/5

The server covers core read and create operations, comments, and search, but lacks update and delete for issues. This leaves a notable gap in the issue lifecycle, as agents cannot modify or close tickets, making it incomplete for comprehensive Linear workflow coverage.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

linear A
io.usefulapi
Search, read and create Linear issues, projects, teams and cycles.
Project Management Developer Tools
82
Linear AOAuth
app.linear
MCP server for Linear project management and issue tracking
Project Management Developer Tools
10
Linear A
io.github.pipeworx-io
Linear MCP — wraps the Linear GraphQL API (OAuth)
Project Management Developer Tools App Automation
362
SuperlistOAuth
io.github.superlistapp
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Project Management Workplace & Productivity
2

Related MCP Servers

Linear MCP Server
Project Management Developer Tools App Automation
gerbal
A
license
Not graded
quality
D
maintenance
Allows LLMs to integrate with Linear's issue tracking system, enabling them to create, update, search, and comment on issues through the Linear API.
Updated 2 years ago (2025-02-05 18:21 UTC)
713
MIT
Linear MCP Server
Project Management Developer Tools
veddnd
A
license
Not graded
quality
D
maintenance
Enables LLMs to interact with Linear's issue tracking system, including creating, updating, searching issues, adding comments, and accessing resources via the Linear API.
Updated 3 months ago (2026-05-30 05:17 UTC)
713
MIT
streamlinear
Project Management Developer Tools
prime-radiant-inc
A
license
Not graded
quality
D
maintenance
A lightweight MCP server that enables Claude to interact with Linear via a single tool with seven actions: search, get, update, comment, create, graphql, and help.
Updated 10 days ago (2026-08-27 06:28 UTC)
529
89
MIT
linear-mcp-server
Project Management Developer Tools
dshurick
F
license
Not graded
quality
D
maintenance
MCP server for integrating Linear with Claude Code and other MCP clients. Enables issue management, project planning, and status tracking through a set of tools.
Updated 7 months ago (2026-01-31 22:22 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/larryhudson/linear-mcp-server-again'

If you have feedback or need assistance with the MCP directory API, please join our Discord server