de en es ja ko ru zh

Plane MCP Server

Name: Plane MCP Server
Author: kelvin6365

by kelvin6365

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

플레인 MCP 서버

대장간 배지

LLM이 Plane.so 와 상호 작용하여 Plane API를 통해 프로젝트와 이슈를 관리할 수 있도록 지원하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버를 사용하면 Claude와 같은 LLM이 사용자 제어 및 보안을 유지하면서 프로젝트 관리 워크플로와 직접 상호 작용할 수 있습니다.

특징

Plane 작업 공간의 모든 프로젝트 나열
특정 프로젝트에 대한 자세한 정보를 얻으세요
사용자 정의 가능한 속성으로 새로운 문제 만들기
프로젝트의 문제 나열 및 필터링
특정 문제에 대한 자세한 정보를 얻으세요
기존 문제를 새로운 정보로 업데이트하세요

Related MCP server: Plane MCP Server

필수 조건

Node.js 22.x 이상
Plane.so API 키
Plane.so 작업 공간

설치

옵션 1: 대장간 사용

시작하는 가장 빠른 방법은 Smithery를 사용하여 서버를 직접 설치하는 것입니다.

지엑스피1

이 명령은 Claude와 함께 사용할 Plane MCP 서버를 자동으로 설정합니다. 설치 후 Claude 설정에서 Plane API 키와 작업 공간 슬러그를 사용하여 서버를 구성해야 합니다.

유효한 클라이언트 옵션은 다음과 같습니다: claude, cline, windsurf, roo-cline, witsy, enconvo, cursor

커서를 사용하여 설치하는 예:

npx -y @smithery/cli install @kelvin6365/plane-mcp-server --client cursor

옵션 2: 수동 설정

서버를 수동으로 설정하려면 다음 단계를 따르세요.

이 저장소를 복제하세요:

git clone https://github.com/kelvin6365/plane-mcp-server.git
cd plane-mcp-server

종속성 설치:

npm install

서버를 빌드하세요:

npm run build

Claude for Desktop 사용

참고: 위의 옵션 1(Smithery)을 사용하셨다면 이 섹션을 건너뛸 수 있습니다. Smithery가 자동으로 MCP 서버를 구성해 드립니다.

Claude for Desktop 구성 파일을 엽니다.
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
Plane MCP 서버 구성을 추가합니다.

{
  "mcpServers": {
    "plane": {
      "command": "node",
      "args": ["path/to/plane-mcp-server/build/index.js"],
      "env": {
        "PLANE_API_KEY": "your_plane_api_key_here",
        "PLANE_WORKSPACE_SLUG": "your_workspace_slug_here"
      }
    }
  }
}

데스크톱용 Claude 재시작

사용 가능한 도구

참고: 도구 이름은 밑줄이 아닌 하이픈(예: list-projects )을 사용합니다. 서버는 호환성을 위해 밑줄을 하이픈으로 자동 변환합니다.

프로젝트 목록

Plane 작업 공간에 있는 모든 프로젝트를 나열합니다.

매개변수: 없음

예:

{}

get-project

특정 프로젝트에 대한 자세한 정보를 얻습니다.

매개변수:

project_id : 검색할 프로젝트의 ID

예:

{
  "project_id": "01abc123-4567-89de-0123-456789abcdef"
}

이슈 생성

지정된 프로젝트에서 새로운 이슈를 생성합니다.

매개변수:

project_id : 이슈가 생성되어야 하는 프로젝트의 ID
name : 이슈 제목
description_html : 문제에 대한 HTML 설명(Plane API에 필요함)
priority (선택 사항): 문제의 우선순위("긴급", "높음", "보통", "낮음", "없음")
state_id (선택 사항): 이 문제에 대한 상태 ID
assignees (선택 사항): 이 문제에 할당할 사용자 ID 배열

참고: assignees 매개변수는 사용자 ID 문자열 배열이어야 합니다. 일반적인 오류로는 배열 대신 사전/객체를 제공하거나, assignees 필드에 전체 이슈 데이터를 실수로 중첩하는 경우가 있습니다. 서버는 이러한 경우를 처리하려고 시도하지만, 올바른 형식을 사용하는 것이 가장 좋습니다.

예:

{
  "project_id": "01abc123-4567-89de-0123-456789abcdef",
  "name": "Implement new feature",
  "description_html": "<p>We need to implement the new reporting feature</p>",
  "priority": "high",
  "assignees": ["user-id-1", "user-id-2"]
}

목록 문제

선택적 필터링을 사용하여 지정된 프로젝트의 문제를 나열합니다.

매개변수:

project_id : 이슈를 가져올 프로젝트의 ID
state_id (선택 사항): 주 ID로 필터링
priority (선택 사항): 우선순위별 필터링
assignee_id (선택 사항): 담당자 ID로 필터링
limit (선택 사항): 반환할 최대 문제 수(기본값: 50)

예:

{
  "project_id": "01abc123-4567-89de-0123-456789abcdef",
  "priority": "high",
  "limit": 10
}

get-issue

특정 문제에 대한 자세한 정보를 얻습니다.

매개변수:

project_id : 문제가 포함된 프로젝트의 ID
issue_id : 검색할 이슈의 ID

예:

{
  "project_id": "01abc123-4567-89de-0123-456789abcdef",
  "issue_id": "01def456-7890-12gh-3456-789ijklmnopq"
}

업데이트-문제

프로젝트의 기존 이슈를 업데이트합니다.

매개변수:

project_id : 문제가 포함된 프로젝트의 ID
issue_id : 업데이트할 이슈의 ID
name (선택 사항): 이슈의 업데이트된 제목
description_html (선택 사항): 문제에 대한 HTML 설명(Plane API에 필요함)
priority (선택 사항): 문제의 업데이트된 우선순위
state_id (선택 사항): 문제의 업데이트된 상태 ID
assignees (선택 사항): 이 문제에 할당할 사용자 ID 배열이 업데이트되었습니다.

참고: assignees 매개변수는 create-issue 도구와 동일한 형식 지침을 따르는 사용자 ID 문자열 배열이어야 합니다.

예:

{
  "project_id": "01abc123-4567-89de-0123-456789abcdef",
  "issue_id": "01def456-7890-12gh-3456-789ijklmnopq",
  "priority": "urgent",
  "description_html": "<p>Updated description with <strong>more details</strong></p>"
}

개발

개발 종속성 설치:

npm install --save-dev typescript @types/node

개발 모드로 서버를 시작합니다.

npm run dev

테스트

MCP Inspector를 사용하여 서버를 테스트할 수 있습니다.

npx @modelcontextprotocol/inspector node dist/index.js

예시

Plane MCP 서버를 설정한 후 Claude와 시도할 수 있는 몇 가지 상호작용 예시는 다음과 같습니다.

"Plane 작업 공간에 있는 모든 프로젝트를 나열해 주시겠어요?"
"마케팅 프로젝트에서 '소셜 미디어 전략 업데이트'라는 제목으로 우선순위가 높은 새 이슈를 생성해 주세요."
"개발 프로젝트에서 가장 우선 순위가 높은 문제는 무엇입니까?"
"QA 프로젝트의 문제 #123을 업데이트하여 우선순위를 긴급으로 변경합니다."

클로드는 문제를 만들거나 수정하기 전에 귀하의 승인을 요청하면서 Plane과 상호 작용하기 위해 적절한 도구를 사용합니다.

보안 고려 사항

API 키는 작동하려면 적절한 Plane 권한이 필요합니다.
데이터를 수정하는 모든 작업에는 명시적인 사용자 승인이 필요합니다.
환경 변수는 적절하게 보호되어야 합니다.
API 키는 버전 제어에 커밋되어서는 안 됩니다.

기여하다

저장소를 포크하세요
기능 브랜치를 생성합니다( git checkout -b feature/amazing-feature )
변경 사항을 커밋하세요( git commit -m 'Add some amazing feature' )
브랜치에 푸시( git push origin feature/amazing-feature )
풀 리퀘스트 열기

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

지원하다

문제가 발생하거나 질문이 있는 경우:

GitHub 문제 섹션을 확인하세요
modelcontextprotocol.io 에서 MCP 설명서를 참조하세요.
자세한 재생산 단계를 담은 새로운 이슈를 열어보세요

스타 역사

Available Tools

6 tools

create-issueC

Create a new issue in a project

ParametersJSON Schema

Name	Required	Description
`project_id`	Yes	ID of the project where the issue should be created
`name`	Yes	Title of the issue
`description_html`	No	HTML description of the issue (required by Plane API)
`priority`	No	Priority of the issue (urgent, high, medium, low, none)
`state_id`	No	ID of the state for this issue (optional)
`assignees`	No	Array of user IDs to assign to this issue (optional)

TDQS

C2.9/5.0

Behavior2/5

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 'Create' which implies a write operation, but doesn't mention permissions, side effects, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation, error conditions, or provide enough context for safe usage despite the comprehensive schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 6 parameters. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Create') and resource ('new issue in a project'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'update-issue' or specify what distinguishes creation from other operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'list-issues', nor does it mention prerequisites or context for creation. It's a basic statement without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-issueC

Get detailed information about a specific issue

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	ID of the project containing the issue
`issue_id`	Yes	ID of the issue to retrieve

TDQS

C2.9/5.0

Behavior2/5

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 'Get detailed information,' implying a read-only operation, but does not disclose behavioral traits such as authentication needs, rate limits, error conditions, or what 'detailed information' includes (e.g., fields, format). This is inadequate for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It is front-loaded with the core purpose, making it easy to parse quickly, though it lacks depth due to its brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It does not explain what 'detailed information' entails, potential return values, or error handling. For a read operation with rich sibling tools, more context is needed to guide the agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for 'project_id' and 'issue_id' in the input schema. The description adds no additional meaning beyond the schema, such as parameter interactions or examples. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('detailed information about a specific issue'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'get-intake-issue' or 'get-issue-activity', which also retrieve issue-related information, leaving some ambiguity about scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 many sibling tools like 'list-issues' for multiple issues or 'get-intake-issue' for specific types, there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-projectB

Get detailed information about a specific project

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	ID of the project to retrieve

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden of behavioral disclosure. It only states 'Get detailed information,' omitting any details about authentication, rate limits, or what 'detailed' encompasses. For a read operation, it is minimally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no extraneous words. It is front-loaded and efficient, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get operation with one parameter and no output schema, the description is adequate but lacks context about the return format or any prerequisites. It does not fully compensate for the absence of annotations or additional behavioral notes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the parameter 'project_id' is adequately described in the schema as 'ID of the project to retrieve.' The description adds no extra meaning beyond that, meeting the baseline for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves detailed information about a specific project, using a specific verb+resource structure. It successfully distinguishes from sibling tools like create-project, delete-project, and get-issue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as list-projects or get-issue. There are no exclusions, prerequisites, or context for appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-issuesC

List issues from a project

ParametersJSON Schema

Name	Required	Description
`project_id`	Yes	ID of the project to get issues from
`state_id`	No	Filter by state ID (optional)
`priority`	No	Filter by priority (optional)
`assignee_id`	No	Filter by assignee ID (optional)
`limit`	No	Maximum number of issues to return (default: 50)

TDQS

C2.7/5.0

Behavior2/5

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 'List issues' but doesn't disclose behavioral traits like pagination (implied by 'limit'), default sorting, rate limits, authentication needs, or error handling. This leaves significant gaps for an agent to understand how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a basic listing tool, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain return values (e.g., issue format), pagination behavior, or error cases. For a tool with 5 parameters and no structured behavioral hints, this leaves the agent under-informed about critical usage aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 5 parameters. The description adds no meaning beyond the schema, such as explaining how filters combine or the format of returned issues. 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.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List issues from a project' clearly states the verb ('List') and resource ('issues'), but it's vague about scope (e.g., all issues vs. filtered) and doesn't distinguish from siblings like 'get-issue' (single issue) or 'list-projects' (different resource). It's functional 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention using 'get-issue' for a single issue or 'list-projects' to find project IDs first. The description implies usage for listing issues but offers no context on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-projectsA

List all projects in the workspace

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should fully describe behavior. It is minimal, only stating a read operation. It lacks details on pagination, ordering, or whether results are comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at 5 words, with no filler. Every word is informative and necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter list tool, the description is mostly complete. It specifies workspace scope, but could mention if results are limited or paginated. Still adequate for the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so schema coverage is 100%. The description does not need to add parameter details, and it appropriately avoids extraneous information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (List), the resource (projects), and the scope (in the workspace). It effectively distinguishes from sibling tools like get-project (single project) and create-project.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like get-project. Usage is implied but not clarified with when-not or specific contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update-issueC

Update an existing issue in a project, delete just update the issue title with 'delete' or 'remove'

ParametersJSON Schema

Name	Required	Description
`project_id`	Yes	ID of the project containing the issue
`issue_id`	Yes	ID of the issue to update
`name`	No	Updated title of the issue (optional)
`description_html`	No	HTML description of the issue (required by Plane API)
`priority`	No	Updated priority of the issue (optional)
`state_id`	No	Updated state ID of the issue (optional)
`assignees`	No	Updated array of user IDs to assign to this issue (optional)

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but is inadequate. It mentions updating and a deletion method, but doesn't disclose critical behavioral traits like required permissions, whether updates are reversible, rate limits, or what happens to unspecified fields. The deletion note is vague and doesn't explain if it's a standard feature or workaround.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two clauses, but the second clause about deletion is poorly integrated and confusing, reducing clarity. It's front-loaded with the main purpose but the additional note doesn't earn its place effectively, making the structure somewhat disjointed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a mutation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error handling, return values, and how it differs from siblings. The deletion note adds confusion rather than completeness, failing to provide adequate context for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 meaningful parameter semantics beyond what's in the schema, such as explaining interactions between fields or special cases. It mentions 'delete' or 'remove' for the title but doesn't tie this to the 'name' parameter clearly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Update') and resource ('existing issue in a project'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'create-issue' or 'get-issue' beyond the update action, and the second part about deleting with 'delete' or 'remove' is confusing rather than clarifying.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 'create-issue' or 'get-issue'. It mentions a deletion method but doesn't clarify if this is the primary deletion mechanism or when to use it over other tools, offering minimal usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesOct 1, 2025
- First observedcreate-issue
- First observedget-issue
- First observedget-project
- First observedlist-issues
- First observedlist-projects
- First observedupdate-issue

Deploy Server

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

B3.4/5.0

Scored 2026-04-18 11:00 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity: create-issue, get-issue, update-issue, and list-issues handle issues, while get-project and list-projects handle projects. The descriptions reinforce this separation, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with hyphen separation (e.g., create-issue, list-projects). This predictable naming scheme enhances readability and usability across the tool set.

Tool Count5/5

With 6 tools, the server is well-scoped for managing issues and projects in a workspace. Each tool earns its place by covering essential CRUD operations without being overly sparse or bloated.

Completeness4/5

The tool set provides strong coverage for issues (create, get, list, update) and projects (get, list), but lacks explicit create-project, update-project, and delete operations. Agents can work around this with the update-issue workaround for deletion, but minor gaps exist.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
Mercado PagoOAuth
com.mercadopago.mcp
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.
Finance E-commerce & Retail App Automation
2
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3

Related MCP Servers

Linear MCP Server
Project Management Developer Tools
magarcia
A
license
A
quality
C
maintenance
A Model Context Protocol server that enables large language models to interact with Linear's issue tracking system, allowing management of issues, projects, teams, and other Linear resources.
Updated 2 years ago (2025-03-24 09:18 UTC)
19
35 npm
1
MIT
Plane MCP Serverofficial
Project Management Developer Tools
makeplane
A
license
B
quality
A
maintenance
A Model Context Protocol server that enables AI interfaces to seamlessly interact with Plane's project management system, allowing management of projects, issues, states, and other work items through a standardized API.
Updated 10 days ago (2026-09-29 08:24 UTC)
5
46
121 npm
336
MIT
Plane MCP Server
Project Management Developer Tools
disrex-group
A
license
B
quality
C
maintenance
A Model Context Protocol (MCP) server that enables LLMs to interact with Plane.so, allowing them to manage projects and issues through Plane's API. Using this server, LLMs like Claude can directly interact with your project management workflows while maintaining user control and security.
Updated a year ago (2025-08-27 12:13 UTC)
76
10 npm
1
MIT
Plane MCP
Project Management Developer Tools
Rockysingh116
A
license
B
quality
D
maintenance
An MCP server that enables LLMs to fully manage a Plane workspace, including projects, work items, states, labels, cycles, modules, comments, and members.
Updated 4 months ago (2026-06-22 13:08 UTC)
38
MIT

플레인 MCP 서버

특징

필수 조건

설치

옵션 1: 대장간 사용

옵션 2: 수동 설정

Claude for Desktop 사용

사용 가능한 도구

프로젝트 목록

get-project

이슈 생성

목록 문제

get-issue

업데이트-문제

개발

테스트

예시

보안 고려 사항

기여하다

특허

지원하다

스타 역사

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Plane MCP Serverofficial

Appeared in Searches