AIツールとしてLinearと統合するためのモデルコンテキストプロトコル（MCP）。このツールにより、AIはモデルコンテキストプロトコルを介してLinearと対話できるようになります。
完全な線形積分:
検索の問題
新しい問題を作成する
アップデートの問題
コメントを追加する
コメントを更新
ユーザープロファイルを取得する
チーム情報を取得する
Related MCP server: Linear MCP Server
Node.js 18以降
リニアAPIキー
このアプリケーションを使用するには、Linear APIキーが必要です。取得手順は以下のとおりです。
ログインまたはLinearアカウントを作成
Linearにアクセスして既存のアカウントにログインするか、登録して新しいアカウントを作成してください。
ワークスペース設定にアクセスする
メインページから、左上隅のユーザー名をクリックします
「ワークスペース設定」オプションを選択します
API設定を開く
左側の「設定」列で、「API」が見つかるまで下にスクロールします。
「API」オプションをクリックします
新しいAPIキーを作成する
API キーのラベルを入力します（例:「MCP Linear App」）
「新しいAPIキーを作成」ボタンをクリックします
APIキーを安全に保存する
APIキーは一度だけ表示されます
コピーして安全な場所に保存してください。Linearでは再度表示されません。
重要事項：Linearでは、APIキーに対して1時間あたり1,500リクエストのレート制限があります。429 Too Many Requestsエラーを回避するため、アプリケーションがこの制限を遵守していることを確認してください。
Linear API キーの取得と使用に関する詳細については、 Merge.dev のこのガイドをご覧ください。
このリポジトリをクローンします:
git clone git@github.com:zalab-inc/mcp-linear-app.git
cd mcp-linear-app依存関係をインストールします:
npm installルート ディレクトリに.envファイルを作成します。
LINEAR_API_KEY=your_linear_api_key_hereプロジェクトをビルドします。
npm run buildこれで、 distフォルダーをさまざまな AI プラットフォームでの構成に使用できるようになりました。
カーソル MCP 構成ファイルを見つけます。
Windows: C:\Users\<username>\.cursor\mcp.json
macOS: ~/.cursor/mcp.json
Linux: ~/.cursor/mcp.json
ファイルを編集して、Linear MCP サーバー構成を追加します。
{
"mcpServers": {
"linear": {
"command": "<path-to-node>",
"args": [
"<path-to-project>/dist/index.js"
],
"env": {
"LINEAR_API_KEY": "your_linear_api_key_here"
}
}
}
}プレースホルダーを置き換えます:
<path-to-node> : Node.js実行ファイルへのパス
<path-to-project> : MCP Linear App プロジェクト ディレクトリへの絶対パス
your_linear_api_key_here : Linear APIキー
構成例:
{
"mcpServers": {
"linear": {
"command": "C:\\nvm4w\\nodejs\\node.exe",
"args": [
"H:\\mcp\\linear\\dist\\index.js"
],
"env": {
"LINEAR_API_KEY": "lin_api_xxxxxxxxxxxxxxxxxxxxx"
}
}
}
}変更を有効にするには、ファイルを保存して Cursor を再起動します。
ClaudeでMCP Linear Toolsを使用するには、Claudeの設定ファイルに設定を追加する必要があります。以下の手順に従ってください。
Claude AIデスクトップアプリの設定を開く
「開発者」セクションに移動します
「ツール」設定セクションを探します
次のようにして Linear MCP の構成を追加します。
{
"tools": {
"linear": {
"command": "<path-to-node>",
"args": [
"<path-to-project>/dist/index.js"
],
"env": {
"LINEAR_API_KEY": "your_linear_api_key_here"
}
}
}
}プレースホルダーを置き換えます:
<path-to-node> : Node.js実行ファイルへのパス
<path-to-project> : MCP Linear App プロジェクト ディレクトリへの絶対パス
your_linear_api_key_here : Linear APIキー
構成例:
{
"tools": {
"linear": {
"command": "/usr/local/bin/node",
"args": [
"/Users/username/projects/mcp-linear-app/dist/index.js"
],
"env": {
"LINEAR_API_KEY": "lin_api_xxxxxxxxxxxxxxxxxxxxx"
}
}
}
}基本的な原理は、MCP をサポートする他の AI プラットフォームでも同じです。
外部ツールまたはMCPの設定領域を見つける
このリポジトリのdist/index.jsファイルを使用してNode.jsを実行するように設定します
環境設定にLINEAR_API_KEYを含める
設定後、AI は次の線形ツールにアクセスできるようになります。
search_issues - キーワード、ステータス、優先度で問題を検索します
create_issue - 新しい問題を作成する
get_issue - 問題の詳細を取得する
update_issue - 既存の問題を更新する
create_comment - 問題にコメントを追加する
get_comment - 問題からコメントを取得する
update_comment - コメントを更新または削除する
get_profile - 現在のLinearユーザープロファイルを取得します
get_team_id - チームとそのIDのリストを取得する
このツールの使用中に問題が発生した場合は、次の手順に従ってください。
リニアAPIキーが有効であり、十分な権限があることを確認してください
Node.jsが正しくインストールされていることを確認してください
AIプラットフォームのMCP構成を確認する
ログファイルでエラーメッセージを確認してください
AI環境で線形ツールを設定したら、AIに指示を出すことで使用を開始できます。以下に例をいくつか示します。
Cursor では、Claude に Linear 関連のタスクを実行するよう依頼するだけで済みます。
Search for high priority issues in our Linear project.Create a new issue in Linear with the title "Improve login page performance" and add it to the backlog.Get the details of the issue LIN-123 from Linear.Add a comment to issue LIN-456 saying "This is fixed in the latest release. Please verify."Update the priority of issue LIN-789 to urgent.これらのツールの使用方法を示すワークフローの例を次に示します。
チームIDを見つける:
What's my Linear team ID?Claude はget_team_idツールを使用してチーム情報を取得します。
新しい問題の作成:
Create a new Linear issue titled "Implement password reset feature" for the Engineering team with a high priority. The description should be "Users need a way to reset their passwords when they forget them."Claude は必要なパラメータを指定してcreate_issueツールを使用します。
問題を検索中:
Find all high priority issues assigned to me that are currently in progress.Claude は適切なフィルターを備えたsearch_issuesツールを使用します。
問題の更新:
Update issue LIN-456 to add the description "This issue has been verified and tested on all browsers."Claude はupdate_issueツールを使用して問題を修正します。
コメントを追加:
Add a comment to issue LIN-789 asking "Is this still a priority for this sprint?"Claude はcreate_commentツールを使用してコメントを追加します。
コメントを取得しています:
Show me all the comments on issue LIN-321Claude はget_commentツールを使用してコメントを取得します。
これらの例は、ツールが適切に構成されると、AI アシスタントを介して Linear といかに自然に対話できるかを示しています。
このプロジェクトは最近、ドキュメントと線形ツールの機能が改善され、強化されました。主な改善点は以下のとおりです。
インストールと設定の手順をより明確にしたREADMEを更新しました
さまざまな AI プラットフォームの例を含む強化されたドキュメント
エラー処理と応答フォーマットが改善された線形ツールの改善
コメントの管理（作成、取得、更新、削除）のサポートを追加しました
ステータスと優先度によるフィルタリングによる検索機能の向上
このプロジェクトは MIT ライセンスに基づいてライセンスされています。
A tool that creates a comment on an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| comment | Yes | The comment to send to the issue | |
| issueId | Yes | The ID of the issue to send a comment to |
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 the tool 'creates a comment', implying a write operation, but doesn't address permissions, side effects, rate limits, or response format. This is a significant gap for a mutation tool, making it inadequate for safe usage.
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 purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, with no wasted content.
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 write operation with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., permissions, response), usage context, and output information, failing to provide enough guidance for reliable agent 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 schema description coverage is 100%, with clear descriptions for both parameters ('comment' and 'issueId'). The description doesn't add any semantic details beyond what the schema provides, such as format constraints or examples, so it meets the baseline of 3 without compensating or enhancing.
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 ('creates a comment') and target resource ('on an issue in Linear'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update_comment' or 'get_comment', missing an opportunity for sibling differentiation that would warrant a score of 5.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing issue), exclusions, or comparisons to siblings like 'update_comment' for editing or 'get_comment' for reading, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that creates an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | The description of the issue | |
| dueDate | No | The due date of the issue | |
| parentId | No | The ID of the parent issue, used to create a sub-issue | |
| priority | No | The priority of the issue | no_priority |
| status | No | The status of the issue | backlog |
| teamId | Yes | The team ID the issue belongs to | |
| title | Yes | The title of the issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation tool, implying mutation, but doesn't mention authentication requirements, rate limits, error conditions, or what happens on success (e.g., returns issue ID). For a mutation tool with zero annotation coverage, this is insufficient.
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 states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
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 mutation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns issue object/ID), error handling, or behavioral constraints, leaving significant gaps for agent understanding.
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 7 parameters. The description adds no parameter information beyond what's in the schema, meeting the baseline of 3 when schema coverage is high.
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 ('creates') and resource ('an issue in Linear'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'update_issue' or 'search_issues', but the verb 'creates' is specific enough for basic differentiation.
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 provides no guidance on when to use this tool versus alternatives like 'update_issue' or 'search_issues'. It doesn't mention prerequisites (e.g., needing a teamId) or appropriate contexts for creating versus updating issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that gets comments from an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| issueId | Yes | The ID of the issue to get comments from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't specify whether this is a read-only operation, what permissions are required, how comments are returned (e.g., format, pagination), or any rate limits. The phrase 'gets comments' implies retrieval but lacks operational details needed for safe use.
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, straightforward sentence that efficiently conveys the core function without unnecessary words. However, it could be more front-loaded with critical details like behavioral traits or usage context, which would improve its structure for agent decision-making.
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 lack of annotations and output schema, the description is incomplete for a tool that likely returns structured comment data. It doesn't explain what the output contains (e.g., comment text, authors, timestamps) or address potential complexities like error handling or authentication needs, leaving significant gaps for an AI agent to infer.
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, with the single parameter 'issueId' clearly documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for gaps.
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 tool's purpose with a specific verb ('gets') and resource ('comments from an issue in Linear'), making it immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_issue' or explain what differentiates getting comments from getting the issue itself, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_issue' and 'search_issues' available, there's no indication whether this tool retrieves all comments for a specific issue or if there are filtering options, nor when one might choose this over other comment-related tools like 'create_comment' or 'update_comment'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that gets an issue from Linear
| Name | Required | Description | Default |
|---|---|---|---|
| issueId | Yes | The ID of the issue to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('gets an issue') without disclosing behavioral traits like whether it's a read-only operation, authentication requirements, error handling, or rate limits. For a tool with zero annotation coverage, this is inadequate.
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, directly stating the tool's function 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 complexity (a read operation with one parameter) and lack of annotations/output schema, the description is incomplete. It doesn't explain what 'gets' entails (e.g., returns issue details), error cases, or how it differs from siblings. For a tool with no structured data support, more context is needed.
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%, with the parameter 'issueId' documented as 'The ID of the issue to retrieve'. The description adds no additional meaning beyond what the schema provides. According to rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
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 states the tool 'gets an issue from Linear', which provides a basic verb+resource combination. However, it's vague about what 'gets' means (retrieves, fetches, reads) and doesn't distinguish it from sibling tools like 'search_issues' or 'get_comment'. The purpose is understandable but lacks specificity.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_issue' versus 'search_issues' for finding issues, or prerequisites like needing an issue ID. There's no explicit or implied context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that gets the current user's profile from Linear
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool retrieves the current user's profile but doesn't cover aspects like authentication requirements, rate limits, error handling, or the response format. This leaves significant gaps in understanding how the tool behaves in practice.
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 purpose without any unnecessary words. It is front-loaded and wastes no space, 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 lack of annotations and output schema, the description is incomplete for a tool that likely involves authentication and returns user data. It doesn't explain what the profile contains, how errors are handled, or any dependencies, leaving the agent with insufficient context to use the tool 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 tool has 0 parameters, and schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate, as it avoids redundancy while clearly indicating no inputs are required.
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 ('gets') and resource ('current user's profile from Linear'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_team_id' or 'get_issue', which also retrieve data from Linear but target different resources, so it misses the highest score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as authentication, or compare it to sibling tools like 'get_team_id' for team-related data, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that gets all teams and their IDs from Linear
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying what is retrieved, from where, and the resource type, 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 simplicity (0 parameters, no output schema), the description is minimal but incomplete. It lacks details on behavioral aspects like authentication needs, output format, or error handling. Without annotations or an output schema, the description should provide more context to fully guide an AI agent, but it doesn't compensate for these gaps.
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 0 parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't waste space on non-existent parameters, though it could briefly note the lack of inputs for clarity.
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 tool's purpose: 'gets all teams and their IDs from Linear.' It specifies the verb ('gets'), resource ('teams and their IDs'), and data source ('Linear'). However, it doesn't explicitly differentiate from sibling tools like get_profile or search_issues, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or comparisons to siblings like get_profile (which might return user-specific data) or search_issues (which might filter issues by team). This lack of contextual direction limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that searches for issues in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Filter issues by keyword in title or description | |
| limit | No | Maximum number of issues to return (default: 50) | |
| priority | No | Filter issues by priority | |
| skip | No | Number of issues to skip (default: 0) | |
| status | No | Filter issues by status |
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 but only states the basic action without mentioning critical details like whether this is a read-only operation, if it requires authentication, potential rate limits, or what the return format looks like. For a search tool with multiple parameters, this leaves significant gaps in understanding its behavior.
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 extremely concise with a single sentence that directly states the tool's function without any unnecessary words. It's front-loaded with the core purpose and wastes no space on redundant information, making it efficient for quick understanding.
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 has 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the search returns (e.g., issue objects with fields), how results are ordered, or any behavioral constraints. For a search operation in a system like Linear, more context about the operation's scope and results is needed.
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 schema description coverage is 100%, with all parameters well-documented in the schema itself (e.g., 'keyword' filters by title/description, 'priority' and 'status' have enums, 'limit' and 'skip' have defaults). The description adds no additional parameter information beyond what's already in the schema, meeting the baseline expectation but not providing extra value.
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 tool's purpose as 'searches for issues in Linear' with a specific verb ('searches') and resource ('issues'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_issue' which might retrieve a single issue, leaving some ambiguity about when to use this versus other issue-related tools.
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 provides no guidance on when to use this tool versus alternatives like 'get_issue' or 'create_issue'. It lacks any context about appropriate scenarios, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that updates or deletes an existing comment on an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | The new content for the comment | |
| commentId | Yes | The ID of the comment to update | |
| delete | No | Whether to delete the comment |
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. While it states the tool can update or delete a comment, it lacks critical details: it doesn't specify permissions required, whether updates are reversible, rate limits, error conditions (e.g., invalid commentId), or what happens on deletion (e.g., permanent vs. soft delete). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., by separating update and delete scenarios). Every part of the sentence earns its place by conveying essential information.
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 (a mutation operation with three parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or error handling, nor does it explain return values. For a tool that modifies or deletes data, this leaves the agent with insufficient context to use it safely and 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?
Schema description coverage is 100%, with all three parameters (commentId, comment, delete) well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain parameter interactions (e.g., how 'delete' overrides 'comment'), formats, or constraints. Baseline 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 clearly states the tool's purpose: 'updates or deletes an existing comment on an issue in Linear'. It specifies the verb (update/delete), resource (comment), and context (issue in Linear), which is specific and actionable. However, it doesn't explicitly distinguish this tool from its sibling 'create_comment', which handles comment creation rather than modification/deletion.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing comment ID), when not to use it (e.g., for creating new comments), or refer to sibling tools like 'create_comment' or 'get_comment'. Usage is implied by the purpose statement but not explicitly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A tool that updates an issue in Linear
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | The description of the issue | |
| dueDate | No | The due date of the issue | |
| id | Yes | The ID of the issue to update | |
| parentId | No | The ID of the parent issue, used to create a sub-issue | |
| priority | No | The priority of the issue | no_priority |
| sortOrder | No | The sort order of the issue | |
| status | No | The status of the issue | backlog |
| title | No | The title of the issue | |
| trashed | No | Whether the issue is trashed |
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 states the tool 'updates an issue' which implies a mutation operation, but it doesn't disclose any behavioral traits such as required permissions, whether updates are reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 purpose with zero waste. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every word earns its place, and there's no 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 complexity (a mutation tool with 9 parameters, no annotations, and no output schema), the description is incomplete. It doesn't address behavioral aspects like permissions or side effects, provide usage context, or explain return values. For a tool that modifies data in a system like Linear, this leaves significant gaps that could hinder correct agent 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 schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or provide examples). With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract from the schema's documentation.
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 tool's purpose as 'updates an issue in Linear' with a specific verb ('updates') and resource ('issue in Linear'). It distinguishes from siblings like 'create_issue' (creation vs. update) and 'search_issues' (search vs. update), though it doesn't explicitly mention all siblings. The purpose is clear but could be more specific about what aspects can be updated.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing issue ID), when to choose 'update_issue' over 'create_issue' or 'update_comment', or any constraints like permissions. Usage is implied by the name but not explicitly stated, leaving the agent to infer from context.
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_commentcreate_issueget_commentget_issueget_profileget_team_idsearch_issuesupdate_commentupdate_issueScored across 9 tools
Every tool has a clearly distinct purpose targeting specific resources and actions in Linear. The tools are well-differentiated by resource type (issue, comment, profile, team) and operation (create, get, search, update), with no overlapping functionality that could cause confusion.
All tool names follow a consistent verb_noun pattern using snake_case throughout. The naming convention is perfectly predictable with verbs like create, get, search, and update consistently applied to appropriate nouns like issue, comment, profile, and team.
With 9 tools, this server is well-scoped for issue management in Linear. Each tool earns its place by covering essential operations without being overwhelming, providing a balanced set that supports core workflows without unnecessary complexity.
The tool set provides excellent CRUD coverage for issues and comments, plus profile and team lookup capabilities. The only minor gap is the lack of a delete_issue tool, though update_issue might handle deletion, and there's no direct tool for listing all issues without search parameters, but agents can work around these limitations effectively.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
A Model Context Protocol server for Wix AI tools
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
