模型上下文协议 (MCP)，用于与 Linear 集成，作为 AI 工具。此工具允许您的 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,500 个。请确保您的应用程序遵循此限制，以避免出现 429 请求过多错误。
有关获取和使用 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 builddist文件夹现在可以用于各种 AI 平台的配置了。
找到您的 Cursor 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 ：您的线性 API 密钥
示例配置：
{
"mcpServers": {
"linear": {
"command": "C:\\nvm4w\\nodejs\\node.exe",
"args": [
"H:\\mcp\\linear\\dist\\index.js"
],
"env": {
"LINEAR_API_KEY": "lin_api_xxxxxxxxxxxxxxxxxxxxx"
}
}
}
}保存文件并重新启动 Cursor 以使更改生效。
要将 MCP Linear Tools 与 Claude 配合使用，您需要将配置添加到 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 ：您的线性 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 列表
如果您在使用此工具时遇到问题，请：
检查您的 Linear 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.
