참고: 이는 사용자 지정 구현입니다. 공식 Cline Linear MCP 서버는 cline/linear-mcp 를 참조하세요.
Linear의 API와 상호 작용하기 위한 도구를 제공하는 MCP(Model Context Protocol) 서버로, AI 에이전트가 Linear 플랫폼을 통해 문제, 프로젝트 및 팀을 프로그래밍 방식으로 관리할 수 있도록 합니다.
이슈 관리
사용자 정의 가능한 속성(제목, 설명, 팀, 담당자, 우선순위, 레이블)을 사용하여 새로운 이슈를 생성합니다.
유연한 필터링 옵션(팀, 담당자, 상태)을 사용하여 문제 목록 작성
기존 문제 업데이트(제목, 설명, 상태, 담당자, 우선순위)
팀 관리
작업 공간에 있는 모든 팀을 나열합니다.
ID, 이름, 키, 설명을 포함한 팀 세부 정보에 액세스하세요.
프로젝트 관리
선택적 팀 필터링을 사용하여 모든 프로젝트를 나열합니다.
이름, 설명, 상태 및 관련 팀을 포함한 프로젝트 세부 정보를 확인하세요.
Related MCP server: Linear MCP Server
Node.js(v16 이상)
API 액세스가 가능한 선형 계정
적절한 권한이 있는 선형 API 키
Linear 개발자 설정 에서 Linear API 키를 받으세요
API 키로 실행하세요:
지엑스피1
또는 환경에 설정하세요:
export LINEAR_API_KEY=your-api-key
npx @ibraheem4/linear-mcp저장소를 복제합니다.
git clone [repository-url]
cd linear-mcp종속성 설치:
npm install프로젝트를 빌드하세요:
npm run build로컬 개발 및 디버깅을 위해 MCP Inspector를 사용할 수 있습니다.
Supergateway 설치:
npm install -g supergateway포함된 run.sh 스크립트를 사용하세요.
chmod +x run.sh
LINEAR_API_KEY=your-api-key ./run.sh검사기에 접속하세요:
브라우저에서 localhost:1337을 엽니다.
검사기는 SSE(Server-Sent Events)를 통해 연결합니다.
Inspector 인터페이스를 통한 테스트 및 디버그 도구 호출
클라이언트에 따라 설정 파일에서 MCP 서버를 구성하세요.
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
윈도우: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"linear-mcp": {
"command": "node",
"args": ["/path/to/linear-mcp/build/index.js"],
"env": {
"LINEAR_API_KEY": "your-api-key-here"
},
"disabled": false,
"alwaysAllow": []
}
}
}위치: ~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json
{
"mcpServers": {
"linear-mcp": {
"command": "node",
"args": ["/path/to/linear-mcp/build/index.js"],
"env": {
"LINEAR_API_KEY": "your-api-key-here"
},
"disabled": false,
"alwaysAllow": []
}
}
}커서의 경우 서버는 전체 경로로 실행되어야 합니다.
node /Users/ibraheem/Projects/linear-mcp/build/index.jsLinear에서 새로운 문제를 생성합니다.
{
title: string; // Required: Issue title
description?: string; // Optional: Issue description (markdown supported)
teamId: string; // Required: Team ID
assigneeId?: string; // Optional: Assignee user ID
priority?: number; // Optional: Priority (0-4)
labels?: string[]; // Optional: Label IDs to apply
}선택적 필터와 관련된 문제를 나열합니다.
{
teamId?: string; // Optional: Filter by team ID
assigneeId?: string; // Optional: Filter by assignee ID
status?: string; // Optional: Filter by status
first?: number; // Optional: Number of issues to return (default: 50)
}기존 문제를 업데이트합니다.
{
issueId: string; // Required: Issue ID
title?: string; // Optional: New title
description?: string; // Optional: New description
status?: string; // Optional: New status
assigneeId?: string; // Optional: New assignee ID
priority?: number; // Optional: New priority (0-4)
}작업 공간의 모든 팀을 나열합니다. 매개변수는 필요하지 않습니다.
선택적 필터링을 통해 모든 프로젝트를 나열합니다.
{
teamId?: string; // Optional: Filter by team ID
first?: number; // Optional: Number of projects to return (default: 50)
}특정 문제에 대한 자세한 정보를 얻습니다.
{
issueId: string; // Required: Issue ID
}자동 재빌드를 사용한 개발의 경우:
npm run watch서버에는 다음에 대한 포괄적인 오류 처리 기능이 포함되어 있습니다.
잘못된 API 키
필수 매개변수가 없습니다
선형 API 오류
잘못된 도구 요청
모든 오류는 올바르게 형식화되어 설명 메시지와 함께 반환됩니다.
다음으로 구성됨:
타입스크립트
선형 SDK (@linear/sdk v37.0.0)
MCP SDK (@modelcontextprotocol/sdk v0.6.0)
서버는 통신에 stdio를 사용하고 AI 에이전트와의 원활한 통합을 위해 모델 컨텍스트 프로토콜을 구현합니다.
MIT
Create a new issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Issue title | |
| description | No | Issue description (markdown supported) | |
| teamId | Yes | Team ID | |
| assigneeId | No | Assignee user ID (optional) | |
| priority | No | Priority (0-4, optional) | |
| labels | No | Label IDs to apply (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides no behavioral details beyond stating it creates an issue. No mention of return values, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (one sentence) but lacks informational content. It is not wasteful, but it is under-specified for a tool with six parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, no output schema, no annotations), the description provides insufficient context. It does not explain what the tool returns or how to obtain required IDs like teamId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds no additional meaning beyond what's in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (issue in Linear). It distinguishes from sibling tools like create_comment, create_cycle, etc. However, it lacks nuance about what an 'issue' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., update_issue, search_issues). No context about prerequisites or typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific issue
| Name | Required | Description | Default |
|---|---|---|---|
| issueId | Yes | Issue ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description lacks behavioral details such as read-only nature, authentication requirements, or response characteristics, which is particularly problematic without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is minimally adequate but omits what 'detailed information' includes. Lacks output schema, so more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with 'Issue ID'. The description adds no additional meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific issue' clearly states the action (get) and resource (issue), and distinguishes it from sibling tools that create, update, or delete issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_issues or list_issues. No context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List issues with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| teamId | No | Filter by team ID (optional) | |
| assigneeId | No | Filter by assignee ID (optional) | |
| status | No | Filter by status (optional) | |
| first | No | Number of issues to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'optional filters', failing to describe key traits such as pagination behavior (implied by 'first' parameter), rate limits, authentication needs, or whether it's read-only. This is a significant gap for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema, and multiple sibling tools), the description is incomplete. It lacks details on behavioral traits, usage differentiation, and output expectations, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no meaning beyond the schema, merely restating that filters are optional without explaining parameter interactions or semantics. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List issues with optional filters' states the basic action (list) and resource (issues), but it's vague about scope and doesn't differentiate from sibling tools like 'search_issues' or 'get_issue'. It lacks specificity about what 'list' entails (e.g., all issues, paginated, sorted).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_issue'. The description mentions 'optional filters' but doesn't specify contexts or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects
| Name | Required | Description | Default |
|---|---|---|---|
| teamId | No | Filter by team ID (optional) | |
| first | No | Number of projects to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states a read operation but lacks details on optional filtering, pagination defaults, or potential performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but sacrifices completeness; front-loading is fine but could include key details like optional filters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with two optional params and no output schema, but description omits context like pagination limit (default 50) and how it differs from other list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters; description adds no extra meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all projects' with a specific verb and resource, but it does not differentiate from sibling list_* tools or clarify that filtering is available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like search_issues or list_teams, nor any context on filtering or pagination usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all teams in the workspace
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or pagination behavior. The tool is likely read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler words. Information is front-loaded and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple listing tool with no parameters, but lacks details about the return value format or pagination. With no output schema, the description could mention what fields are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. With no parameters to describe, the baseline is 4. The description adds no parameter semantics but is not required to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all teams in the workspace' uses a specific verb ('list') and resource ('teams') with scope ('in the workspace'), clearly distinguishing it from sibling tools that create, update, or get individual teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_team' for a specific team. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for issues using a text query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query text | |
| first | No | Number of results to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching with a text query but fails to describe critical traits like whether results are paginated, sorted, or filtered beyond the query, what permissions are required, or how the search operates (e.g., full-text, exact match). This leaves significant gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., search scope, result format) and doesn't compensate for the absence of structured fields, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting both parameters ('query' and 'first') adequately. The description adds no additional meaning beyond what the schema provides, such as query syntax or result formatting. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('search for issues') and resource ('issues'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'list_issues' or 'get_issue', which might also retrieve issues but with different mechanisms or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'list_issues' or 'get_issue'. The description implies usage for text-based queries but lacks explicit context or exclusions, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing issue
| Name | Required | Description | Default |
|---|---|---|---|
| issueId | Yes | Issue ID | |
| title | No | New title (optional) | |
| description | No | New description (optional) | |
| status | No | New status (optional) | |
| assigneeId | No | New assignee ID (optional) | |
| priority | No | New priority (0-4, optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update an existing issue,' implying a mutation operation, but doesn't specify permissions required, whether changes are reversible, rate limits, or error handling. This leaves significant gaps in understanding the tool's behavior and risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words: 'Update an existing issue.' It's front-loaded and efficiently conveys the core action without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, error cases, or what the update returns, leaving the agent under-informed about how to handle this operation effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, detailing all 6 parameters (e.g., 'issueId' as required, 'title' as optional). The description adds no additional meaning beyond the schema, such as explaining parameter interactions or constraints. Baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing issue' clearly states the action (update) and resource (issue), but it's vague about what aspects can be updated and doesn't distinguish it from sibling tools like 'create_issue' or 'get_issue'. It provides a basic purpose but lacks specificity about the scope of updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as 'create_issue' for new issues or 'get_issue' for viewing. It doesn't mention prerequisites like needing an existing issue ID or context for when updates are appropriate, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_issueget_issuelist_issueslist_projectslist_teamssearch_issuesupdate_issueScored across 7 tools
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific resource (issue, project, team) and action (create, get, list, search, update), making it easy for an agent to select the correct one.
All tools follow a consistent verb_noun pattern (e.g., create_issue, list_issues, update_issue). The naming is uniform and predictable throughout the set, with no deviations in style or convention.
With 7 tools, the count is well-scoped and appropriate for a Linear issue management server. Each tool earns its place by covering essential operations without being overly sparse or bloated.
The tool set provides strong CRUD coverage for issues (create, get, list, search, update) and lists for projects and teams. A minor gap exists in missing delete operations for issues, projects, or teams, but agents can still handle core workflows effectively.
Search, read and create Linear issues, projects, teams and cycles.
Linear MCP — wraps the Linear GraphQL API (OAuth)
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
MCP server for Linear project management and issue tracking
