Skip to main content
Glama
deenesjakoruzh
mustafa-patharia

ProofHub MCP Server

by mustafa-patharia
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

🔌 ProofHub MCP Server

npm version License: MIT MCP

A Model Context Protocol (MCP) server that bridges ProofHub's project management capabilities with AI assistants like Claude, GitHub Copilot, and Cursor. Paste a ProofHub task URL in your AI chat, and the agent automatically fetches task details, comments, and bug tracker links to help you complete development tasks faster.

🎯 What This Solves

As a developer working with ProofHub for task management, you normally have to:

  1. Open ProofHub in a browser

  2. Navigate to the task

  3. Read the description and all comments

  4. Copy relevant bug tracker links (Jira, Linear, GitHub Issues, etc.)

  5. Context-switch back to your code editor

With this MCP server, simply paste the ProofHub URL into your AI assistant, and it automatically:

  • ✅ Fetches the complete task description

  • ✅ Retrieves all comments and history

  • ✅ Extracts bug tracker links from anywhere in the task

  • ✅ Provides structured context for the AI to help you code

Related MCP server: ClickUp MCP

⚡ Features

  • 🔒 Secure: API key stored in environment variables, never in code

  • ⏱️ Rate Limit Handling: Automatically respects ProofHub's 25 req/10s limit with retry logic

  • 🧹 HTML Cleanup: Strips HTML tags from descriptions/comments for clean AI consumption

  • 🔗 Smart Link Extraction: Regex patterns detect bug tracker URLs across all text fields

  • 🎯 One-Shot Tool: get_task_with_bug_links fetches everything in a single call

  • 🛡️ Error Handling: Graceful error messages with API status codes

🚀 Quick Start

1. Installation

npm install

2. Configuration

Create a .env file (use .env.example as template):

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

Getting your API key: Log in to ProofHub → Account Settings → Apps & Integrations → API → Generate new API key

3. Connect to Your AI Assistant

🤖 Claude Desktop

Add to your claude_desktop_config.json:

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

Config location:

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

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

💻 VS Code Copilot

Add to .vscode/mcp.json in your workspace or user settings:

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

📋 Available Tools

Tool

Description

Use Case

proofhub_parse_url

Extracts project/list/task IDs from a ProofHub URL

Parse URL before calling other tools

proofhub_get_task

Fetches complete task details (title, description, stage, custom fields, assignees)

Get full task context

proofhub_get_comments

Retrieves all task comments with timestamps

Review team discussions

proofhub_get_task_with_bug_links

⭐ One-shot: Fetches task + comments + auto-extracts bug tracker URLs

Most useful - get everything in one call

proofhub_create_comment

Posts a new comment on a task

Update task from your AI chat

proofhub_get_task_history

Fetches activity/stage change history

Track task evolution

💡 Usage Examples

Example 1: Fetch Task Context

Simply paste a ProofHub URL in your AI chat:

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

The AI will call proofhub_get_task_with_bug_links and return:

  • Task title and description

  • All comments (cleaned from HTML)

  • List of bug tracker links found

  • Stage, assignees, and custom fields

Example 2: Development Workflow

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.

The AI will:

  1. Fetch the complete task context

  2. Extract Jira/GitHub/Linear links

  3. Use your bug tracker MCP to fetch issue details

  4. Provide a comprehensive development plan

Example 3: Update Task

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

🤝 Contributing

Contributions welcome! Fork the repo, make your changes, and submit a pull request.

References

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. Dates show when Glama detected each change.

  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
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Trello MCP Server

    LorhanSohaky
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to retrieve Trello card information by ID or link, providing access to card details including labels, members, due dates, and attachments through a standardized interface.
    50
    MIT

  • ClickUp MCP

    renatco
    A
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables AI assistants to interact with ClickUp workspaces through natural language - search tasks, manage workflows, track time, collaborate via comments, and access complete task context including comments and images.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mustafa-patharia/proofhub-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server