Engineering MCP

MCP local de ingeniería: entran tickets, evidencia de QA y tiempo; la investigación cierra la causa raíz; el conocimiento se queda; el reporting sale listo.

No sustituye lo que ya tienes:

ENGINEERING MCP
      │
      ├── WORK        tickets · tasks · projects
      ├── QA          testing evidence · bugs · artifacts
      └── TIME        tracking · estimates · metrics
              │
              ▼
        INVESTIGATION
              │
              ▼
          KNOWLEDGE
              │
              ▼
          REPORTING

Problema que resuelve

Un ticket en Jira, un fail en CI y un registro de horas viven en tres lugares. A la hora del estado, nadie monta el paquete.

Este MCP registra el ciclo en la misma base de datos local:

1. Abre el ticket (WORK)

2. Adjunta el fail / bug / screenshot (QA) — sin ejecutar la suite

3. Registra horas y estimación (TIME)

4. Investiga hasta la causa raíz (INVESTIGATION)

5. Se convierte en playbook (KNOWLEDGE)

6. report_ticket devuelve el paquete para handoff, daily o evidencia de carrera

Related MCP server: Productivity Tracker MCP Server

Requisitos

• Node 22+ (node:sqlite nativo, igual que qa-oracle)

• Cliente MCP (Cursor)

Instalación (sin ruta absoluta)

Cursor no apunta a la carpeta en el Desktop. Descarga el paquete — igual que qa-lab-agent. La base de datos está en ~/.engineering-mcp/engineering.db, en cualquier máquina.

Configuración en Cursor (~/.cursor/mcp.json)

{
  "mcpServers": {
    "engineering": {
      "command": "npx",
      "args": ["-y", "engineering-mcp"]
    }
  }
}

Sin args con /Users/.... Sin ENGINEERING_MCP_DB. Recarga los MCPs.

Esto funciona cuando el paquete esté en npm o en GitHub (abajo). Hasta que lo publiques, usa el atajo local (también sin ruta en mcp.json):

cd ~/Desktop/engineering-mcp
npm install
npm install -g .

{
  "mcpServers": {
    "engineering": {
      "command": "engineering-mcp"
    }
  }
}

npm install -g . coloca el comando en el PATH. El mcp.json solo menciona el nombre.

Dónde alojar (npm vs GitHub vs nube)

No necesitas un sitio propio. El «sitio» es npmjs.com — el mismo de mcp-lab-agent. Cursor ejecuta el MCP en tu máquina; la nube solo entrega el código.

La nube tipo URL ("url": "https://...") existe en Cursor, pero entonces SQLite deja de ser local: tickets, bugs y horas pasarían a vivir en un servidor. Eso es un producto multi-usuario, no este v0.

Publicar en npm (igual que el lab-agent)

El nombre engineering-mcp está libre. Con la cuenta de npm ya iniciada:

cd ~/Desktop/engineering-mcp
npm test
npm publish --access public

Después de eso, cualquier Mac usa solo el bloque npx de arriba.

Publicar en GitHub (sin npm)

cd ~/Desktop/engineering-mcp
git init
git add .
git commit -m "feat: engineering mcp v0.1"
gh repo create Wesley-Gomes93/engineering-mcp --public --source . --remote origin --push

Configuración alternativa, todavía sin ruta:

{
  "mcpServers": {
    "engineering": {
      "command": "npx",
      "args": ["-y", "github:Wesley-Gomes93/engineering-mcp"]
    }
  }
}

Reinicia Cursor (o recarga los MCPs). La base de datos se crea sola en ~/.engineering-mcp/.

Bucle típico

"Abre um projeto Atlas (ATL) e um bug P1: timeout no checkout"
  → work_upsert_project + work_upsert_ticket

"Registra o fail do checkout.spec.js e anexa o log"
  → qa_record_run + qa_attach_evidence

"Estima 4h e lança 1.5h de repro"
  → time_estimate + time_log

"Abre investigação: hipótese de seletor instável"
  → investigate_open + investigate_add_finding

"Fecha como flaky: timing no botão Finalizar"
  → investigate_conclude

"Vira playbook: wait da animação + data-testid"
  → knowledge_save

"Me dá o pacote do ticket"
  → report_ticket

Si no sabes la herramienta: eng_route con la frase en portugués.

Herramientas

WORK

Estado: backlog · todo · doing · review · done
Prioridad: p0 … p3
external_key guarda la clave Jira/GitLab sin consultar la API todavía.

QA

Ejecutar pruebas continúa en qa-lab-agent. El histórico de Jira corporativo continúa en qa-oracle.

TIME

INVESTIGATION

Clasificación: bug · flaky · infra · regression · unknown

KNOWLEDGE

REPORTING

Estructura

engineering-mcp/
├── src/
│   ├── server.js              # MCP stdio
│   ├── lib/store.js           # SQLite — fonte da verdade
│   └── domains/
│       ├── work.js
│       ├── qa.js
│       ├── time.js
│       ├── investigation.js
│       ├── knowledge.js
│       └── reporting.js
└── test/store.test.js

Base de datos estándar: ~/.engineering-mcp/engineering.db (no viaja con el repo).

Nada sale de la máquina además de lo que el agente ya ve en el chat. Sin Jira/GitLab en el v0 — external_key es el gancho para el sync más adelante.

v0 vs después

Ahora: base de datos local, ciclo cerrado, Cursor.

Después (solo si se usa el v0):

• Sync Jira → tickets (reutilizar el cliente de qa-oracle)

• Importar run de qa-lab-agent / job de GitLab

• Dashboard HTML de report_status

Seguridad

• Base de datos en ~/.engineering-mcp/ (fuera del repo)

• Sin tokens en el v0

• Publicar en npm/GitHub envía código, no tickets