Skip to main content
Glama
deenesjakoruzh
mustafa-patharia

ProofHub MCP Server

by mustafa-patharia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

🔌 ProofHub MCP-Server

npm version License: MIT MCP

Ein Model Context Protocol (MCP)-Server, der die Projektmanagement-Funktionen von ProofHub mit KI-Assistenten wie Claude, GitHub Copilot und Cursor verbindet. Fügen Sie eine ProofHub-Aufgaben-URL in Ihren KI-Chat ein, und der Agent ruft automatisch Aufgabendetails, Kommentare und Bug-Tracker-Links ab, damit Sie Entwicklungsaufgaben schneller erledigen können.

🎯 Was dieses Tool löst

Als Entwickler, der ProofHub für das Aufgabenmanagement nutzt, müssen Sie normalerweise:

  1. ProofHub in einem Browser öffnen

  2. Zur Aufgabe navigieren

  3. Die Beschreibung und alle Kommentare lesen

  4. Relevante Bug-Tracker-Links (Jira, Linear, GitHub Issues, etc.) kopieren

  5. Zurück in Ihren Code-Editor wechseln

Mit diesem MCP-Server fügen Sie einfach die ProofHub-URL in Ihren KI-Assistenten ein, und dieser führt automatisch folgende Schritte aus:

  • ✅ Ruft die vollständige Aufgabenbeschreibung ab

  • ✅ Lädt alle Kommentare und den Verlauf

  • ✅ Extrahiert Bug-Tracker-Links aus allen Bereichen der Aufgabe

  • ✅ Stellt strukturierten Kontext bereit, damit die KI Sie beim Programmieren unterstützen kann

Related MCP server: Redmine MCP Server

⚡ Funktionen

  • 🔒 Sicher: API-Schlüssel werden in Umgebungsvariablen gespeichert, niemals im Code

  • ⏱️ Ratenbegrenzungs-Handling: Respektiert automatisch das Limit von ProofHub (25 Anfragen/10s) mit Wiederholungslogik

  • 🧹 HTML-Bereinigung: Entfernt HTML-Tags aus Beschreibungen/Kommentaren für eine saubere KI-Verarbeitung

  • 🔗 Intelligente Link-Extraktion: Regex-Muster erkennen Bug-Tracker-URLs in allen Textfeldern

  • 🎯 One-Shot-Tool: get_task_with_bug_links ruft alles in einem einzigen Aufruf ab

  • 🛡️ Fehlerbehandlung: Aussagekräftige Fehlermeldungen mit API-Statuscodes

🚀 Schnellstart

1. Installation

npm install

2. Konfiguration

Erstellen Sie eine .env-Datei (verwenden Sie .env.example als Vorlage):

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

API-Schlüssel abrufen: Melden Sie sich bei ProofHub an → Kontoeinstellungen → Apps & Integrationen → API → Neuen API-Schlüssel generieren

3. Verbindung mit Ihrem KI-Assistenten herstellen

🤖 Claude Desktop

Fügen Sie dies zu Ihrer claude_desktop_config.json hinzu:

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

Speicherort der Konfiguration:

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

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

💻 VS Code Copilot

Fügen Sie dies zu .vscode/mcp.json in Ihrem Arbeitsbereich oder Ihren Benutzereinstellungen hinzu:

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

📋 Verfügbare Tools

Tool

Beschreibung

Anwendungsfall

proofhub_parse_url

Extrahiert Projekt-/Listen-/Aufgaben-IDs aus einer ProofHub-URL

URL parsen, bevor andere Tools aufgerufen werden

proofhub_get_task

Ruft vollständige Aufgabendetails ab (Titel, Beschreibung, Status, benutzerdefinierte Felder, Verantwortliche)

Vollständigen Aufgabenkontext abrufen

proofhub_get_comments

Ruft alle Aufgabenkommentare mit Zeitstempeln ab

Teamdiskussionen überprüfen

proofhub_get_task_with_bug_links

⭐ One-Shot: Ruft Aufgabe + Kommentare ab + extrahiert automatisch Bug-Tracker-URLs

Am nützlichsten - alles in einem Aufruf erhalten

proofhub_create_comment

Postet einen neuen Kommentar zu einer Aufgabe

Aufgabe aus Ihrem KI-Chat aktualisieren

proofhub_get_task_history

Ruft den Aktivitäts-/Statusänderungsverlauf ab

Aufgabenentwicklung verfolgen

💡 Anwendungsbeispiele

Beispiel 1: Aufgabenkontext abrufen

Fügen Sie einfach eine ProofHub-URL in Ihren KI-Chat ein:

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

Die KI ruft proofhub_get_task_with_bug_links auf und gibt Folgendes zurück:

  • Aufgabentitel und -beschreibung

  • Alle Kommentare (von HTML bereinigt)

  • Liste der gefundenen Bug-Tracker-Links

  • Status, Verantwortliche und benutzerdefinierte Felder

Beispiel 2: Entwicklungs-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.

Die KI wird:

  1. Den vollständigen Aufgabenkontext abrufen

  2. Jira-/GitHub-/Linear-Links extrahieren

  3. Ihr Bug-Tracker-MCP verwenden, um Issue-Details abzurufen

  4. Einen umfassenden Entwicklungsplan bereitstellen

Beispiel 3: Aufgabe aktualisieren

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

🤝 Mitwirken

Beiträge sind willkommen! Forken Sie das Repo, nehmen Sie Ihre Änderungen vor und senden Sie einen Pull Request.

Referenzen

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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

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