---
type: DC
asset_id: DC-EL-LoopX-HighLevelMCP-EvaluacionDesarrollo-v01
version: v01
status: Canonical · documento técnico · para revisión del equipo de desarrollo
owner: Victor Heredia
sherpa_owner: Jay
fecha_creacion: 2026-05-30
fecha_ultima_actualizacion: 2026-05-30
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-LoopX
tipo: DC — documento de criterio · evaluación técnica del MCP de HighLevel para el puente OneRocket ↔ Vault
room_destino: PB-LoopX
audiencia: Equipo de desarrollo EmpowerLabs
proposito: >
  Evaluar las opciones de conectividad MCP para construir el puente bidireccional entre el
  Sherpa LoopX (Cowork / agente Claude) y la capa de ejecución del CRM. OneRocket está
  construido sobre HighLevel; este documento reúne lo que ofrece el MCP oficial de HighLevel,
  sus límites, las alternativas, y las preguntas que el equipo de desarrollo debe responder
  para decidir el alcance del puente.
referencia_canonica:
  - XP-EL-LoopX-DisenoYPiloto-v01 (XPack del Room · lista el puente como componente a desarrollar)
  - DC-EL-LoopX-NaturalezaDelSistema-v01 (gravity score de doble fuente)
  - DC-EL-LoopX-RescateComponentesDemandGen-v01 (componentes y conceptos)
nota_terminologica: >
  En este documento se usa "HighLevel" deliberadamente porque se refiere a la tecnología MCP de
  la plataforma base. OneRocket es la versión mejorada propia de EmpowerLabs construida sobre
  HighLevel. La verificación central de este documento es justamente si OneRocket hereda y expone
  el MCP/API de HighLevel.
tags: [dc, loopx, highlevel, mcp, onerocket, integracion, equipo-desarrollo, gravity-score]
---

# DC · LoopX · evaluación del MCP de HighLevel para el puente OneRocket ↔ Vault

## Documento para revisión del equipo de desarrollo

---

## 1. Contexto y por qué este documento

El sistema LoopX necesita un **puente programático bidireccional** entre el Sherpa LoopX (un agente Claude operando vía Cowork / API / MCP) y la capa de ejecución del CRM (OneRocket):

- **Lectura (CRM → Vault):** traer datos de engagement, contactos, conversaciones y estado de pipeline hacia el LoopDoc. Esto alimenta la **parte automática del gravity score**.
- **Escritura (Vault → CRM):** crear/actualizar contactos, mover etapas de oportunidad, inscribir en workflows, enviar mensajes, agendar.

El XPack del proyecto lista este puente como un componente "a desarrollar". El propósito de este documento es informar al equipo de desarrollo de que **buena parte de esa plomería probablemente ya existe** a nivel de la plataforma base (HighLevel), y aterrizar las preguntas que faltan por resolver.

---

## 2. Hallazgo principal

HighLevel lanzó a inicios de 2026 su **MCP oficial**: una conexión estandarizada que permite a un agente de IA **leer y escribir** en una cuenta de HighLevel vía HTTP. Como OneRocket está construido sobre HighLevel, esto abre la posibilidad de que el puente de LoopX no se construya desde cero, sino que se monte sobre infraestructura ya existente.

En el registro de conectores nativos de Claude (Cowork) **no** hay un conector de HighLevel; pero el MCP del lado de HighLevel sí existe y es lo relevante.

---

## 3. Detalles técnicos del MCP oficial de HighLevel

**Endpoint:** `https://services.leadconnectorhq.com/mcp/`

**Autenticación:** Private Integration Token (PIT). Se genera en `Settings > Private Integrations` de la Location, eligiendo los scopes necesarios.

**Transporte:** HTTP Streamable.

**Headers:**

```json
{
  "mcpServers": {
    "ghl-mcp": {
      "url": "https://services.leadconnectorhq.com/mcp/",
      "headers": {
        "Authorization": "Bearer pit-XXXXX",
        "locationId": "XXXXXXXX"
      }
    }
  }
}
```

`locationId` puede ir en header o pasarse dinámicamente en el prompt (soporta multi-location).

**Herramientas disponibles hoy (~36, roadmap a 250+).** Las que importan para LoopX, separadas por dirección:

| Categoría | Lectura (alimenta gravity) | Escritura (acciones del Sherpa) |
|---|---|---|
| Contactos | get-contact, get-contacts, get-all-tasks | create-contact, update-contact, upsert-contact, add-tags, remove-tags |
| Conversaciones | search-conversation, get-messages | send-a-new-message |
| Oportunidades / Pipeline | search-opportunity, get-pipelines, get-opportunity | update-opportunity |
| Calendario | get-calendar-events, get-appointment-notes | (edit-calendar-events vía scope) |
| Pagos | get-order-by-id, list-transactions | — |
| Social | get-posts, get-social-media-statistics, get-account | create-post, edit-post |
| Custom fields | get-custom-fields | — |
| Email | fetch-template | create-template |

**Scopes requeridos (PIT):** View/Edit Contacts, View/Edit Conversations + Messages, View/Edit Opportunities, View/Edit Calendars + Events, View Custom Fields, View Forms, View Locations, View Payment Orders/Transactions, View/Edit Social Media Posts + Accounts, View/Edit Email Templates.

**Compatibilidad y clientes:** funciona con clientes que soportan HTTP Streamable MCP (Cursor, Windsurf, OpenAI Playground, n8n v1.104+). Hay ejemplos oficiales con LangGraph y n8n.

---

## 4. Caveats que el equipo debe tener presente

1. **Claude Desktop / Cowork y HTTP Streamable.** El roadmap oficial menciona un paquete npx "para integración rápida con clientes que aún no soportan HTTP Streamable, incluyendo Claude Desktop". Es decir: la conexión directa desde Claude Desktop puede requerir un wrapper npx mientras tanto. **Verificar el soporte actual de HTTP Streamable en el entorno donde correrá el Sherpa LoopX.**
2. **OAuth aún en roadmap.** Hoy la autenticación es por PIT (token estático por location). Para multi-instancia (5 instancias de LoopX) esto implica gestionar varios PITs/locations. OAuth viene después.
3. **Cobertura de herramientas.** 36 tools hoy; 250+ es roadmap, no presente. Si LoopX necesita algo fuera de las 36 (p. ej. workflows nativos, formularios a profundidad), hoy se cubre vía API REST directa, no vía MCP.
4. **Consumo de tokens.** El MCP unificado busca no "comerse" tokens del LLM; aún así, exponer muchas tools a un agente tiene costo de contexto. Conviene exponer solo el subconjunto que LoopX usa.

---

## 5. Alternativas (por si OneRocket no expone el MCP oficial)

- **MCPs open-source de la comunidad** sobre la API de HighLevel: `mastanley13/GoHighLevel-MCP` (269+ tools) y `BusyBee3333/Go-High-Level-MCP-2026-Complete` (520+ tools). Mucha más cobertura, pero sin soporte oficial.
- **API REST de HighLevel directa** + un wrapper MCP propio de EmpowerLabs. Máximo control, más trabajo. Es la ruta si OneRocket tiene backend modificado.
- **Zapier MCP / n8n** como capa intermedia de orquestación si se prefiere no acoplar directo.

---

## 6. La pregunta crítica para OneRocket

OneRocket es la versión *mejorada* construida sobre HighLevel. De aquí salen las preguntas que solo el equipo de desarrollo puede responder:

1. **¿OneRocket corre sobre la infraestructura de LeadConnector/HighLevel (white-label) o tiene backend propio modificado?** De esto depende todo lo demás.
2. **Si es white-label:** ¿el endpoint `services.leadconnectorhq.com/mcp/` sirve los datos de las cuentas OneRocket tal cual, usando un PIT generado desde OneRocket? (Lo más probable es que sí.)
3. **Si tiene backend modificado:** ¿las modificaciones rompen la compatibilidad con el MCP oficial? ¿Conviene exponer un MCP propio sobre la API de OneRocket?
4. **¿OneRocket expone `Settings > Private Integrations` para generar PITs con scopes?**
5. **Multi-instancia:** ¿cada instancia de LoopX será una location distinta (un PIT por location) o se resuelve de otra forma?

---

## 7. Qué necesita LoopX del puente (mapeo funcional)

- **Hacia el gravity score (lectura):** señales de engagement (conversaciones, aperturas, citas, estado de pipeline) que el Sherpa lee periódicamente y deposita en el LoopDoc como insumo de la parte automática del gravity.
- **Hacia la ejecución (escritura):** acciones que el Sherpa decide y ejecuta — actualizar contacto, mover etapa, mandar mensaje, agendar, inscribir en secuencia.
- **Capa de gobernanza (a definir):** qué acciones ejecuta el Sherpa sin aprobación humana (nurture de bajo riesgo) y cuáles requieren visto bueno del operador (mensajes a decision makers clave). Esto es decisión de producto, no técnica, pero condiciona qué permisos se otorgan al PIT.

---

## 8. Preguntas concretas a responder por el equipo de desarrollo

- [ ] ¿OneRocket es white-label de HighLevel o backend propio? (bloqueante)
- [ ] ¿El MCP oficial de HighLevel funciona contra cuentas OneRocket con un PIT propio? (prueba de humo)
- [ ] ¿El entorno donde correrá el Sherpa soporta HTTP Streamable, o necesitamos el wrapper npx?
- [ ] ¿Las 36 tools actuales cubren lo que LoopX necesita, o requerimos API REST directa para workflows/forms?
- [ ] ¿Estrategia de auth para 5 instancias: PIT por location ahora, migrar a OAuth después?
- [ ] ¿Construimos wrapper MCP propio de EmpowerLabs o usamos el oficial + REST puntual?

---

## 9. Recomendación preliminar

Si OneRocket resulta ser white-label sobre HighLevel (lo más probable), la ruta de menor esfuerzo es: **usar el MCP oficial de HighLevel para el subconjunto de tools que LoopX necesita, complementar con llamadas REST puntuales para lo que el MCP aún no cubre, y construir encima la lógica de gravity/LoopDoc del lado del Vault.** El puente deja de ser "construir un CRM connector desde cero" y se vuelve "configurar acceso + definir alcance de autonomía + construir la lógica de criterio".

El primer paso accionable es la **prueba de humo del punto 8**: generar un PIT desde OneRocket y hacer una llamada de lectura contra el endpoint oficial. Eso responde la pregunta bloqueante en una tarde.

---

## 10. Anexo · referencias

- MCP oficial de HighLevel (docs): https://marketplace.gohighlevel.com/docs/other/mcp/
- Soporte HighLevel — uso del MCP: https://help.gohighlevel.com/support/solutions/articles/155000005741
- Guía GoHighLevel + Claude Cowork (terceros): https://automatedmarketer.net/how-to-connect-gohighlevel-with-claude-cowork-step-by-step-mcp-integration/
- MCP comunidad (269+ tools): https://github.com/mastanley13/GoHighLevel-MCP

---

**Owner:** Victor Heredia · **Sherpa:** Jay · **Audiencia:** Equipo de desarrollo · **Fecha:** 2026-05-30