ghl-pro-mcp

Le das una orden en tu idioma y te monta el embudo entero dentro de GoHighLevel.

«Quiero un embudo para mi clínica de mascotas, y que agende citas»

A partir de ahí, el asistente pregunta lo que le falta —no inventa nada—, investiga el mercado de tu zona, y despliega en tu cuenta: etiquetas, campos personalizados, pipeline con sus etapas, landing con formulario real y el workflow de respuesta y seguimiento. Todo queda en borrador, y se puede deshacer de una pieza.

Esto es un servidor MCP local: funciona con Claude Code, Claude Desktop, Codex, Cursor, Cline, Windsurf o VS Code. Corre en tu ordenador — tus credenciales y los datos de tu CRM no pasan por ningún servidor intermedio.

Por qué este y no otro

No es una opinión: la API pública de GoHighLevel solo permite leer workflows, embudos y páginas. Es un muro de su API, no de su configuración. Cualquier integración que se apoye solo en la API pública se queda fuera de ahí — y ahí es donde está el trabajo.

Este servidor usa además la vía de sesión para esas tres cosas, que es lo que le deja montar el embudo completo en lugar de limitarse a consultarlo.

El flujo, de principio a fin

«quiero un embudo para mi clínica de mascotas»
        │
        ├─ nuevo_proyecto ──────► crea el brief y devuelve las preguntas
        │
        ├─ responder_brief ─────► se contestan (el asistente pregunta lo que falta)
        │
        ├─ guia_de_investigacion ► qué hay que averiguar del mercado de esa zona
        ├─ guardar_investigacion ► 3-5 competidores y las palabras que usa su cliente
        │
        ├─ ver_plan_despliegue ──► enseña qué va a crear y qué falta
        │
        ├─ desplegar_plan ───────► LO CREA TODO, en borrador
        │
        └─ ver_manifiesto ───────► qué se creó, para poder deshacerlo
              deshacer_plan ─────► borra lo que creó, y dice lo que no pudo

El brief manda. Sin las respuestas críticas —sector, objetivo, oferta, zona, quién atiende y qué es un buen lead— el despliegue no se ejecuta. Y sin la investigación del mercado tampoco: sin las palabras que usa tu cliente, la landing sale con los tópicos del sector, igual que la de cualquier competidor.

Qué crea el despliegue

1. Etiquetas de segmentación, según lo que el negocio necesite
2. Campos personalizados — los que tú digas: la fecha de la última visita, la talla, lo que haga falta para el seguimiento. Sin esto no hay recordatorio del próximo servicio, que es la táctica que más dinero devuelve cuando se vende varias veces al mismo cliente
3. Pipeline con etapas derivadas del objetivo (no las mismas cinco para todos)
4. Landing con formulario nativo de GoHighLevel — se comprueba que capte de verdad
5. Workflow: crea la oportunidad en el pipeline, responde al cliente por el canal que tenga, avisa al negocio, espera un día y deja una tarea de repaso

Nada se publica. Los workflows quedan en borrador y la landing sin publicar: publicar es tu decisión.

Nada se duplica. Si despliegas dos veces, reutiliza lo que se llame igual y te dice qué revisar. Y lo que ya tenías no se apunta en el manifiesto, así que deshacer no te borra algo tuyo.

Requisitos

• uv (recomendado), o Python 3.10 o superior.
• Una Private Integration Token de GoHighLevel, creada dentro de la subcuenta que quieras conectar y con los scopes que necesites.

Instalación

No hay que instalar nada a mano. Con uv en el equipo, el cliente MCP se lo baja de PyPI la primera vez que lo usa:

{
  "mcpServers": {
    "ghl-pro": {
      "command": "uvx",
      "args": ["ghl-pro-mcp@latest"],
      "env": { "GHL_ENABLE_SESSION": "1" }
    }
  }
}

Es el equivalente a npx. El @latest comprueba si hay versión nueva cada vez, así que los arreglos llegan solos.

Los comandos de terminal

El cliente se lo baja solo con uvx, así que no hace falta instalar nada — pero los comandos de configuración y diagnóstico (setup, doctor) se lanzan igual, con uvx delante:

uvx ghl-pro-mcp@latest --version     # comprobar que arranca
uvx ghl-pro-mcp@latest setup         # configurar
uvx ghl-pro-mcp@latest doctor        # comprobar contra tu GoHighLevel

Si lo instalas como herramienta (uv tool install ghl-pro-mcp), el uvx sobra y los comandos quedan como ghl-pro-mcp setup y ghl-pro-mcp doctor. Las dos vías valen; uvx no deja nada instalado.

Funciona igual en Windows, macOS y Linux.

Configuración

Un solo comando:

uvx ghl-pro-mcp@latest setup

Te pide el token privado y el Location ID —y te confirma el nombre de la subcuenta antes de guardar nada—, y después te ofrece configurar workflows y embudos: con la extensión de Chrome, a mano, o dejarlo para más tarde.

Hazlo en una terminal, nunca desde el chat de la IA. Lo que se escribe en la conversación acaba en el historial, y el token privado da acceso completo al CRM.

Las credenciales quedan en un único archivo, en tu carpeta de usuario:

Si prefieres decidir tú la ubicación, define GHL_PRO_ENV_PATH y el asistente escribirá ahí: respeta esa variable, igual que el servidor al leer.

Añádelo a tu cliente

Al terminar, setup te muestra el bloque exacto que necesitas. Es el de arriba.

GHL_ENABLE_SESSION enciende workflows, embudos y páginas. Sin esa línea tendrás las 548 operaciones de la API pública, pero no el extra — y ese extra es la diferencia.

Reinicia tu cliente de IA después de añadirlo.

Hace falta uv: winget install astral-sh.uv, o curl -LsSf https://astral.sh/uv/install.sh | sh.

Comprobar que funciona

uvx ghl-pro-mcp@latest doctor

Comprueba la configuración contra tu GoHighLevel real y te dice, una a una, qué funciona y qué no. No modifica nada salvo que se lo pidas expresamente. Y si quieres llegar más lejos, tiene dos banderas que sí escriben, pero que dejan todo como estaba:

uvx ghl-pro-mcp@latest doctor --escritura          # crea un workflow de prueba y LO BORRA
uvx ghl-pro-mcp@latest doctor --pagina <pageId>    # guarda esa página sin cambiarla

Las 61 herramientas

El flujo — de la orden al embudo montado

Cuenta y conocimiento

Workflows — el foso

Embudos y páginas — el foso

Contactos, CRM y agenda

Mensajes y archivos

El resto del catálogo

Las escrituras empiezan en seco

Ninguna herramienta escribe a la primera. Unas usan dry_run=true —la primera llamada enseña lo que haría y no crea nada— y otras usan confirmar=true. En cualquiera de los dos casos, nada se crea ni se envía sin que lo hayas pedido expresamente.

Y hay reglas que están en el código, no en un documento:

• El copy se revisa antes de enviar o guardar. Un SMS con un hueco sin rellenar, o con urgencia inventada, no sale.
• No se manda SMS sin que lo hayas elegido. Cuesta dinero por mensaje y exige consentimiento.
• Los workflows nacen en borrador y la landing sin publicar.

Lo que todavía NO hace

Preferimos decirlo:

• Recordatorio de cita, petición de reseña y reactivación. El plan monta la respuesta inmediata y el seguimiento; esas tres necesitan disparadores de cita o de tiempo que la API no tiene verificados, y un disparador inventado falla en silencio.
• WhatsApp. Fuera de las 24 horas siguientes al último mensaje del cliente, WhatsApp solo admite plantillas aprobadas por Meta. No se pueden inventar.
• El filtro del disparador por formulario. Se crea sin filtro y el asistente te avisa: hay que ponerlo a mano en la interfaz si la cuenta tiene más de un formulario.
• Publicar una página necesita un dominio en la cuenta.

Dónde se guarda cada cosa

Diagnóstico

El servidor nunca escribe en stdout salvo el protocolo: todos los logs van a stderr. Si algo falla, sube el detalle con:

GHL_PRO_LOG_LEVEL=DEBUG uvx ghl-pro-mcp

Errores frecuentes:

Licencia

Propietaria. Ver el paquete en PyPI.