Linear를 AI 도구로 통합하기 위한 모델 컨텍스트 프로토콜(MCP). 이 도구를 사용하면 AI가 모델 컨텍스트 프로토콜을 통해 Linear와 상호 작용할 수 있습니다.
완전 선형 적분 :
검색 문제
새로운 이슈를 만들어 보세요
업데이트 문제
댓글 추가
댓글 업데이트
사용자 프로필 가져오기
팀 정보 얻기
Related MCP server: Linear MCP Server
Node.js 18 이상
선형 API 키
이 애플리케이션을 사용하려면 Linear API 키가 필요합니다. 키를 얻는 방법은 다음과 같습니다.
로그인 또는 선형 계정 생성
Linear를 방문하여 기존 계정에 로그인하거나 등록하여 새 계정을 만드십시오.
작업 공간 설정에 액세스
메인 페이지에서 왼쪽 상단 모서리에 있는 사용자 이름을 클릭하세요.
"작업 공간 설정" 옵션을 선택하세요
오픈 API 설정
왼쪽의 "설정" 열에서 "API"를 찾을 때까지 아래로 스크롤하세요.
"API" 옵션을 클릭하세요
새 API 키 만들기
API 키에 대한 레이블을 입력하세요(예: "MCP Linear App")
"새 API 키 만들기" 버튼을 클릭하세요
API 키를 안전하게 저장하세요
API 키는 한 번만 표시됩니다.
Linear에서는 다시 표시되지 않으므로 안전한 위치에 복사하여 저장하세요.
중요 참고 : Linear는 API 키에 대해 시간당 1,500개의 요청으로 제한합니다. 429 Too Many Requests 오류를 방지하려면 애플리케이션이 이 제한을 준수해야 합니다.
Linear API 키를 얻고 사용하는 방법에 대한 자세한 내용은 Merge.dev의 가이드를 참조하세요.
이 저장소를 복제하세요:
지엑스피1
종속성 설치:
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
리눅스: ~/.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 - 현재 선형 사용자 프로필을 가져옵니다.
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."클로드는 필요한 매개변수와 함께 create_issue 도구를 사용합니다.
문제 검색 :
Find all high priority issues assigned to me that are currently in progress.클로드는 적절한 필터와 함께 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-321클로드는 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.
