注: これはカスタム実装です。公式のCline Linear MCPサーバーについては、 cline/linear-mcpをご覧ください。
Linear の API と対話するためのツールを提供するモデル コンテキスト プロトコル (MCP) サーバー。AI エージェントが Linear プラットフォームを通じてプログラムで問題、プロジェクト、チームを管理できるようになります。
問題管理
カスタマイズ可能なプロパティ（タイトル、説明、チーム、担当者、優先度、ラベル）を使用して新しい問題を作成します。
柔軟なフィルタリング オプション (チーム、担当者、ステータス) を使用して問題を一覧表示します
既存の問題を更新する（タイトル、説明、ステータス、担当者、優先度）
チームマネジメント
ワークスペース内のすべてのチームを一覧表示する
ID、名前、キー、説明などのチームの詳細にアクセスします
プロジェクト管理
オプションのチームフィルタリングを使用してすべてのプロジェクトを一覧表示します
名前、説明、状態、関連チームなどのプロジェクトの詳細を表示します
Related MCP server: Linear MCP Server
Node.js (v16 以上)
APIアクセス可能なLinearアカウント
適切な権限を持つリニアAPIキー
Linearの開発者設定からLinear APIキーを取得します
API キーを使用して実行します:
LINEAR_API_KEY=your-api-key npx @ibraheem4/linear-mcpまたは、環境内で設定します。
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 を使用できます。
スーパーゲートウェイをインストールします。
npm install -g supergateway付属のrun.shスクリプトを使用します。
chmod +x run.sh
LINEAR_API_KEY=your-api-key ./run.shインスペクターにアクセスします。
ブラウザでlocalhost:1337を開きます
インスペクターはサーバー送信イベント（SSE）を介して接続します。
インスペクタインターフェースを介したテストおよびデバッグツールの呼び出し
クライアントに基づいて設定ファイルで MCP サーバーを構成します。
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %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 エージェントとのシームレスな統合のためにモデル コンテキスト プロトコルを実装します。
マサチューセッツ工科大学
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
