Skip to main content
Glama
deenesjakoruzh
mustafa-patharia

ProofHub MCP Server

by mustafa-patharia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

🔌 ProofHub MCP 서버

npm version License: MIT MCP

ProofHub의 프로젝트 관리 기능과 Claude, GitHub Copilot, Cursor와 같은 AI 어시스턴트를 연결하는 MCP(Model Context Protocol) 서버입니다. AI 채팅에 ProofHub 작업 URL을 붙여넣으면, 에이전트가 자동으로 작업 세부 정보, 댓글 및 버그 추적기 링크를 가져와 개발 작업을 더 빠르게 완료할 수 있도록 돕습니다.

🎯 해결하는 문제

ProofHub를 사용하여 작업을 관리하는 개발자는 일반적으로 다음과 같은 과정을 거쳐야 합니다:

  1. 브라우저에서 ProofHub 열기

  2. 작업으로 이동

  3. 설명 및 모든 댓글 읽기

  4. 관련 버그 추적기 링크(Jira, Linear, GitHub Issues 등) 복사

  5. 코드 편집기로 컨텍스트 전환

이 MCP 서버를 사용하면, AI 어시스턴트에 ProofHub URL을 붙여넣기만 하면 다음과 같은 작업이 자동으로 수행됩니다:

  • ✅ 전체 작업 설명 가져오기

  • ✅ 모든 댓글 및 기록 검색

  • ✅ 작업 내 어디에서나 버그 추적기 링크 추출

  • ✅ AI가 코딩을 도울 수 있도록 구조화된 컨텍스트 제공

Related MCP server: Redmine MCP Server

⚡ 기능

  • 🔒 보안: API 키는 환경 변수에 저장되며 코드에 포함되지 않음

  • ⏱️ 속도 제한 처리: 재시도 로직을 통해 ProofHub의 25 req/10s 제한을 자동으로 준수

  • 🧹 HTML 정리: AI가 읽기 쉽도록 설명/댓글에서 HTML 태그 제거

  • 🔗 스마트 링크 추출: 정규식 패턴을 사용하여 모든 텍스트 필드에서 버그 추적기 URL 감지

  • 🎯 원샷 도구: get_task_with_bug_links로 한 번의 호출로 모든 정보 가져오기

  • 🛡️ 오류 처리: API 상태 코드가 포함된 유용한 오류 메시지 제공

🚀 빠른 시작

1. 설치

npm install

2. 구성

.env 파일을 생성합니다 (.env.example을 템플릿으로 사용):

PROOFHUB_API_KEY=your_api_key_here
PROOFHUB_API_BASE=https://company.proofhub.com/api/v3

API 키 얻기: ProofHub 로그인 → 계정 설정(Account Settings) → 앱 및 통합(Apps & Integrations) → API → 새 API 키 생성

3. AI 어시스턴트에 연결

🤖 Claude Desktop

claude_desktop_config.json에 추가:

{
  "mcpServers": {
    "proofhub": {
      "command": "node",
      "args": ["/absolute/path/to/proofhub-mcp/index.js"],
      "env": {
        "PROOFHUB_API_KEY": "your_key_here"
      }
    }
  }
}

구성 파일 위치:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

💻 VS Code Copilot

워크스페이스 또는 사용자 설정의 .vscode/mcp.json에 추가:

{
  "servers": {
    "proofhub": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/proofhub-mcp/index.js"],
      "env": {
        "PROOFHUB_API_KEY": "your_key_here"
      }
    }
  }
}

📋 사용 가능한 도구

도구

설명

사용 사례

proofhub_parse_url

ProofHub URL에서 프로젝트/목록/작업 ID 추출

다른 도구를 호출하기 전에 URL 파싱

proofhub_get_task

전체 작업 세부 정보(제목, 설명, 단계, 사용자 지정 필드, 담당자) 가져오기

전체 작업 컨텍스트 확보

proofhub_get_comments

타임스탬프가 포함된 모든 작업 댓글 검색

팀 토론 검토

proofhub_get_task_with_bug_links

⭐ 원샷: 작업 + 댓글 가져오기 + 버그 추적기 URL 자동 추출

가장 유용함 - 한 번의 호출로 모든 정보 확보

proofhub_create_comment

작업에 새 댓글 게시

AI 채팅에서 작업 업데이트

proofhub_get_task_history

활동/단계 변경 기록 가져오기

작업 진행 상황 추적

💡 사용 예시

예시 1: 작업 컨텍스트 가져오기

AI 채팅에 ProofHub URL을 붙여넣기만 하면 됩니다:

Get context for this task:
https://kpi.proofhub.com/bappswift/#app/todos/project-7189443252/list-270280503800/task-514774338823

AI는 proofhub_get_task_with_bug_links를 호출하여 다음을 반환합니다:

  • 작업 제목 및 설명

  • 모든 댓글 (HTML 정리됨)

  • 발견된 버그 추적기 링크 목록

  • 단계, 담당자 및 사용자 지정 필드

예시 2: 개발 워크플로우

I need to work on this ProofHub task:
https://kpi.proofhub.com/.../task-514774338823

Fetch the task, find any Jira links, and help me understand what needs to be built.

AI는 다음을 수행합니다:

  1. 전체 작업 컨텍스트 가져오기

  2. Jira/GitHub/Linear 링크 추출

  3. 버그 추적기 MCP를 사용하여 이슈 세부 정보 가져오기

  4. 포괄적인 개발 계획 제공

예시 3: 작업 업데이트

Add a comment to task 514774338823 in project 7189443252, list 270280503800:
"Completed the API endpoint implementation. Ready for review."

🤝 기여하기

기여를 환영합니다! 저장소를 포크하고, 변경 사항을 적용한 후 풀 리퀘스트를 제출하세요.

참조

Available Tools

6 tools
proofhub_create_commentC

Post a new comment on a ProofHub task.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYes
list_idYes
task_idYes
descriptionYesComment text (plain text or HTML).

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, and the description lacks disclosure of side effects, authentication needs, rate limits, or error behavior. As a write operation, minimal transparency about idempotency or responses is critical.

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

Conciseness4/5

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

The description is concise (7 words) and front-loaded with the action. However, for a 4-parameter tool, slightly more structure (e.g., listing parameters) would improve clarity without adding significant length.

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 4 required parameters, no output schema, and no annotations, the description is insufficient. It does not explain how parameters connect, response format, or constraints, leaving the agent without enough context for correct invocation.

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

Parameters2/5

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

With only 25% schema coverage (only 'description' has a brief description), the description does not add meaning for project_id, list_id, or task_id. The general statement 'Post a new comment' fails to clarify parameter roles or relationships.

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 'Post a new comment on a ProofHub task' clearly identifies the verb (post), resource (comment), and context (on a task), distinguishing it from sibling tools like proofhub_get_comments.

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 on when to use this tool versus alternatives, prerequisites, or exclusions is provided. For a creation tool, explicit context about task existence or complementary use with proofhub_get_comments would improve usability.

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

proofhub_get_commentsC

Fetch all comments on a ProofHub task, including their full text.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYes
list_idYes
task_idYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states 'fetch all comments' but does not mention pagination, rate limits, authentication requirements, or any side effects. The minimal description does not compensate for the lack of annotations.

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

Conciseness4/5

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

The description is a single, clear sentence that is front-loaded with the core purpose. It is appropriately concise, though slightly too brief for the complexity of a three-parameter fetch tool.

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 absence of an output schema and three required parameters, the description should explain the return structure beyond 'full text'. It does not specify what fields are returned, how comments are ordered, or any limits, leaving the agent with insufficient context.

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

Parameters1/5

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

The input schema has three required parameters with zero description coverage. The tool description does not explain what project_id, list_id, or task_id represent or how they relate to the task. The description adds no semantic value beyond the parameter names.

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 (fetch) and the resource (all comments on a ProofHub task), and adds specificity with 'including their full text'. It distinguishes from sibling tools like proofhub_create_comment (write) and proofhub_get_task (different resource).

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 when to fetch comments vs. task details. The description lacks any context about prerequisites or conditions.

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

proofhub_get_taskC

Fetch full task details (title, description, stage, custom fields, assignees) from ProofHub.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYes
list_idYes
task_idYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided. The description only implies a read operation ('Fetch') but does not disclose any additional behaviors such as authentication requirements, rate limits, or side effects.

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

Conciseness4/5

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

Single sentence, clear and to the point. No unnecessary words. Could be slightly improved by structuring or providing a brief example.

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?

No output schema, no parameter descriptions, and no annotations. The description lists fields returned but lacks enough context for an AI to confidently use this tool, especially given three required IDs with no explanations.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate. However, it only lists parameters by name and provides no extra meaning (e.g., how to obtain project_id, list_id, task_id).

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?

Clearly states the verb 'Fetch' and resource 'full task details', listing specific fields (title, description, stage, custom fields, assignees). Distinguishes from sibling tools like 'get_task_history' and 'get_task_with_bug_links'.

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 on when to use this tool versus alternatives such as 'proofhub_get_task_with_bug_links' or 'proofhub_get_comments'. Does not specify prerequisites or when not to use.

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

proofhub_get_task_historyB

Fetch the activity history of a ProofHub task (stage changes, edits, etc.).

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYes
list_idYes
task_idYes

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool fetches activity history and lists examples (stage changes, edits), which gives some behavioral context. However, it does not specify if results are paginated, ordered, or if it only returns recent history.

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 sentence of 12 words, front-loading the action and object. Every word adds value, with no redundancy or filler.

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?

Given no output schema and three required parameters, the description is minimal but adequate for a simple fetch tool. It lacks explanation of the output format and parameter details, which would be needed for a tool with more complex semantics.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It does not explain what project_id, list_id, or task_id represent beyond the obvious task identification. The agent may not know that list_id refers to a list within the project. The examples in the description are about the output, not the parameters.

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 verb 'Fetch' and the resource 'activity history of a ProofHub task', with examples of content (stage changes, edits). It distinguishes this tool from siblings like proofhub_get_task (which fetches task details) and proofhub_get_comments (which fetches comments) by focusing on history.

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 proofhub_get_task or proofhub_get_task_with_bug_links. The description does not mention prerequisites, limitations, or context for usage.

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

proofhub_parse_urlA

Parse a ProofHub task URL and return the project ID, list ID, and task ID embedded in it. Use this as the first step before calling other ProofHub tools.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFull ProofHub task URL, e.g. https://kpi.proofhub.com/bappswift/#app/todos/project-7189443252/list-270280503800/task-514774338823

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description fully explains the behavior: parsing a URL and extracting three IDs. It does not cover error handling for malformed URLs, but for a low-risk transformation the disclosure is adequate.

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 brief (two sentences) and front-loaded with the action. Every sentence adds essential information: what it does and when to use it. No unnecessary words.

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?

Given the tool's simplicity (one parameter, no output schema), the description adequately covers the return values (three IDs) and usage context. It could explicitly state the output format, but the implied return is sufficient for an AI agent.

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 schema already describes the 'url' parameter fully (100% coverage with example). The description adds value by explaining what IDs are extracted from the URL, going beyond the schema's structural description to convey the tool's purpose.

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's action: 'Parse a ProofHub task URL and return the project ID, list ID, and task ID.' This is a specific verb-resource pair that distinguishes it from sibling tools that create, get, or fetch different entities.

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

Usage Guidelines4/5

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

The description explicitly advises 'Use this as the first step before calling other ProofHub tools,' providing clear sequential context. It does not mention alternatives or when not to use, but the guidance is sufficiently direct for a simple preprocessing tool.

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.

  1. 6 tool updatesv1.0.0
    • First observedproofhub_create_comment
    • First observedproofhub_get_comments
    • First observedproofhub_get_task
    • First observedproofhub_get_task_history
    • First observedproofhub_get_task_with_bug_links
    • First observedproofhub_parse_url
Deploy Server
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

A3.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: creating comments, fetching comments, getting task details, getting task history, a composite bug-link extractor, and a URL parser. No overlap.

Naming Consistency5/5

All tools use the 'proofhub_' prefix followed by consistent snake_case verb_noun patterns (e.g., create_comment, get_task, parse_url). Naming is uniform and predictable.

Tool Count5/5

With 6 tools, the server is well-scoped for interacting with ProofHub tasks. Each tool serves a clear purpose without bloat or deficiency.

Completeness3/5

The tool set covers creation, reading, and composite extraction, but lacks update, delete, and list operations for tasks and comments. This creates notable gaps for full lifecycle management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers