witrack-mcp

El servidor MCP de witrack. Le da a tu IA el contexto de cada proyecto de Wigou —dónde está parado hoy y qué se habló en cada sesión—, los documentos del relevamiento y los tickets.

No hace falta clonar ni compilar nada: se corre con npx, que baja la última versión sola. Las reglas de cómo trabajamos vienen adentro (REGLAS.md) y le llegan a tu IA como instrucciones del servidor, así que se actualizan con el paquete.

Configurarlo

Necesitás dos datos: la URL de witrack y tu API key, que sacás de witrack en Mi perfil y API keys (tocá tu nombre, abajo a la izquierda) o directo en https://witrack.wigou.co/profile?tab=apikeys. Es personal: lo que subas queda firmado con tu nombre y respeta tus permisos.

Claude Desktop — claude_desktop_config.json (Windows: %APPDATA%\Claude\, macOS: ~/Library/Application Support/Claude/):

{
  "mcpServers": {
    "witrack": {
      "command": "npx",
      "args": ["-y", "witrack-mcp@latest"],
      "env": {
        "WITRACK_API_URL": "https://witrack.wigou.co",
        "WITRACK_API_KEY": "wt_tu_api_key"
      }
    }
  }
}

Claude Code, desde la terminal, una sola vez (--scope user lo deja disponible en todos tus proyectos, no sólo en la carpeta donde lo corrés):

claude mcp add witrack --scope user --env WITRACK_API_URL=https://witrack.wigou.co \
  --env WITRACK_API_KEY=wt_tu_api_key -- npx -y witrack-mcp@latest

OpenCode — en opencode.json:

{
  "mcp": {
    "witrack": {
      "type": "local",
      "command": ["npx", "-y", "witrack-mcp@latest"],
      "environment": {
        "WITRACK_API_URL": "https://witrack.wigou.co",
        "WITRACK_API_KEY": "wt_tu_api_key"
      }
    }
  }
}

Cursor (.cursor/mcp.json) usa la misma forma que Claude Desktop. VS Code con Copilot (.vscode/mcp.json) también, pero la clave de arriba es servers en lugar de mcpServers, y cada servidor lleva "type": "stdio".

Qué trae

| Herramienta | Para qué | | --- | --- | | reglas_de_contexto | Las reglas de cómo trabajamos, para los clientes que no muestran las instrucciones del servidor | | find_project_space | Encontrar el proyecto y su spaceId | | get_project_context | El estado actual y la bitácora, por tema y con presupuesto de texto | | search_project_context | Buscar un tema sin traer todo | | read_functional_page | Leer un documento, o una versión anterior | | list_page_versions | El historial de un documento | | read_attachment_text | El texto de un PDF, un Word o un .txt del espacio | | compare_functional_versions | Qué cambió entre dos documentos o versiones | | add_context_entry | Subir la sesión: la entrada de bitácora y, si cambió, el estado | | edit_context_entry | Corregir una entrada ya subida | | update_context_state | Reescribir sólo el estado actual | | write_functional_document | Crear o reescribir un documento del relevamiento | | discard_context_entry | Desactivar una entrada que estaba mal de raíz | | list_tasks, get_task, create_task, update_task, add_comment, list_projects | Los tickets |

Cómo trabajamos con esto

Está en REGLAS.md: cuándo subir, qué va en la entrada y en el estado, qué va en el relevamiento y cómo se corrige. Es markdown plano y sirve con cualquier modelo. Si usás la API sin MCP, leelo en https://unpkg.com/witrack-mcp@latest/REGLAS.md.

Publicar una versión nueva

La publica sola GitHub Actions al pushear un tag, que tiene que decir la misma versión que el package.json:

cd witrack-mcp
npm version patch --no-git-tag-version     # o minor / major
git commit -am "chore(mcp): witrack-mcp 1.3.1"
git tag witrack-mcp-v1.3.1
git push && git push origin witrack-mcp-v1.3.1

Nadie tiene que actualizar nada: como todos lo corren con @latest, la próxima vez que abran su herramienta ya tienen la versión nueva, con sus reglas.