Skip to main content
Glama
deenesjakoruzh
mustafa-patharia

ProofHub MCP Server

by mustafa-patharia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

🔌 Servidor MCP de ProofHub

npm version License: MIT MCP

Un servidor del Protocolo de Contexto de Modelo (MCP) que conecta las capacidades de gestión de proyectos de ProofHub con asistentes de IA como Claude, GitHub Copilot y Cursor. Pega una URL de tarea de ProofHub en tu chat de IA y el agente obtendrá automáticamente los detalles de la tarea, los comentarios y los enlaces de seguimiento de errores para ayudarte a completar las tareas de desarrollo más rápido.

🎯 Qué resuelve esto

Como desarrollador que utiliza ProofHub para la gestión de tareas, normalmente tienes que:

  1. Abrir ProofHub en un navegador

  2. Navegar a la tarea

  3. Leer la descripción y todos los comentarios

  4. Copiar los enlaces relevantes de seguimiento de errores (Jira, Linear, GitHub Issues, etc.)

  5. Cambiar el contexto de vuelta a tu editor de código

Con este servidor MCP, simplemente pega la URL de ProofHub en tu asistente de IA y este automáticamente:

  • ✅ Obtiene la descripción completa de la tarea

  • ✅ Recupera todos los comentarios y el historial

  • ✅ Extrae enlaces de seguimiento de errores de cualquier parte de la tarea

  • ✅ Proporciona un contexto estructurado para que la IA te ayude a programar

Related MCP server: Redmine MCP Server

⚡ Características

  • 🔒 Seguro: La clave API se almacena en variables de entorno, nunca en el código

  • ⏱️ Gestión de límites de tasa: Respeta automáticamente el límite de 25 peticiones/10s de ProofHub con lógica de reintento

  • 🧹 Limpieza de HTML: Elimina etiquetas HTML de descripciones/comentarios para un consumo limpio por parte de la IA

  • 🔗 Extracción inteligente de enlaces: Los patrones de Regex detectan URLs de seguimiento de errores en todos los campos de texto

  • 🎯 Herramienta de una sola ejecución: get_task_with_bug_links obtiene todo en una sola llamada

  • 🛡️ Gestión de errores: Mensajes de error claros con códigos de estado de la API

🚀 Inicio rápido

1. Instalación

npm install

2. Configuración

Crea un archivo .env (usa .env.example como plantilla):

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

Cómo obtener tu clave API: Inicia sesión en ProofHub → Configuración de cuenta → Aplicaciones e integraciones → API → Generar nueva clave API

3. Conecta con tu asistente de IA

🤖 Claude Desktop

Añade a tu claude_desktop_config.json:

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

Ubicación de la configuración:

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

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

💻 VS Code Copilot

Añade a .vscode/mcp.json en tu espacio de trabajo o configuración de usuario:

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

📋 Herramientas disponibles

Herramienta

Descripción

Caso de uso

proofhub_parse_url

Extrae IDs de proyecto/lista/tarea de una URL de ProofHub

Analizar URL antes de llamar a otras herramientas

proofhub_get_task

Obtiene detalles completos de la tarea (título, descripción, etapa, campos personalizados, asignados)

Obtener contexto completo de la tarea

proofhub_get_comments

Recupera todos los comentarios de la tarea con marcas de tiempo

Revisar discusiones del equipo

proofhub_get_task_with_bug_links

⭐ Una sola ejecución: Obtiene tarea + comentarios + extrae automáticamente enlaces de seguimiento de errores

Más útil - obtener todo en una llamada

proofhub_create_comment

Publica un nuevo comentario en una tarea

Actualizar tarea desde tu chat de IA

proofhub_get_task_history

Obtiene el historial de actividad/cambios de etapa

Rastrear la evolución de la tarea

💡 Ejemplos de uso

Ejemplo 1: Obtener contexto de la tarea

Simplemente pega una URL de ProofHub en tu chat de IA:

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

La IA llamará a proofhub_get_task_with_bug_links y devolverá:

  • Título y descripción de la tarea

  • Todos los comentarios (limpios de HTML)

  • Lista de enlaces de seguimiento de errores encontrados

  • Etapa, asignados y campos personalizados

Ejemplo 2: Flujo de trabajo de desarrollo

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.

La IA hará lo siguiente:

  1. Obtendrá el contexto completo de la tarea

  2. Extraerá enlaces de Jira/GitHub/Linear

  3. Usará tu MCP de seguimiento de errores para obtener detalles del problema

  4. Proporcionará un plan de desarrollo integral

Ejemplo 3: Actualizar tarea

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

🤝 Contribuciones

¡Las contribuciones son bienvenidas! Haz un fork del repositorio, realiza tus cambios y envía un pull request.

Referencias

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