development #mcp #ia #whatsapp #instagram #leads #crm #ventas

WhatsApp, Instagram y Messenger en piloto automático: cómo MCP convirtió a nuestros leads en conversaciones inteligentes

El problema no es el modelo, es el contexto. Así montamos un servidor MCP con +20 herramientas para que la IA responda leads de cualquier canal — con memoria real, permisos por workspace y acciones en el CRM.

V

Víctor Rojas

CEO, Aztecknology

WhatsApp, Instagram y Messenger en piloto automático: cómo MCP convirtió a nuestros leads en conversaciones inteligentes

El problema real: contexto, no inteligencia

Lead llega a Instagram preguntando precio. Tu agente responde con un speech genérico. Al día siguiente el mismo lead te escribe por WhatsApp diciendo “¿me sirve esto para mi negocio de tacos?”. El chatbot — sin saber que es el mismo cliente — vuelve a abrir conversación, vuelve a preguntar el nombre, vuelve a mandar el mismo PDF.

Esto pasa porque la mayoría de implementaciones de IA tratan cada conversación como memoria cero. No es culpa del modelo. Gemini 3.1, Claude 4.7 y GPT-5.1 son suficientemente inteligentes para llevar una conversación coherente. El problema es que no tienen acceso en tiempo real a:

  1. Quién es este lead (incluso si entró por otro canal).
  2. Qué se le ha dicho antes en cualquier punto de contacto.
  3. Qué reglas del negocio aplican (tono de la campaña, status válidos, ofertas vigentes).
  4. Qué tiene permitido hacer: marcar como interesado, agendar follow-up, escalar a humano.

MCP (Model Context Protocol) es el estándar que permite empaquetar todo eso como “herramientas” que el LLM llama en tiempo real. En Aztecknology, cuando construimos LexGuard, montamos un servidor MCP con +20 herramientas específicas para gestión de leads y lo enchufamos a un pipeline visual que dispara cuando llega un mensaje. Resultado: la IA tiene memoria, tiene permisos, y responde por el mismo canal por el que entró el cliente.

Aquí te cuento cómo está armado.

MCP en 60 segundos

Pensado para no-técnicos: MCP es como una caja de herramientas estandarizada que cualquier LLM (Claude, Gemini, GPT) sabe usar. En vez de pegarle al modelo un PDF con tu base de datos, le expones funciones que puede llamar:

  • “Búscame el lead con este teléfono.”
  • “Dame los últimos 30 mensajes de esta conversación.”
  • “Cambia el status de este lead a interested.”
  • “Agenda un follow-up para mañana a las 10am.”

Cada función devuelve datos frescos en tiempo real, no un snapshot de hace una semana. Lo importante: la IA no decide qué puede hacer; el servidor MCP decide qué herramientas exponer, con qué parámetros y con qué permisos.

Arquitectura end-to-end

Este es el camino completo que sigue un mensaje desde que entra por WhatsApp hasta que el cliente recibe la respuesta:

[1] Mensaje entra por Meta (WhatsApp / IG / Messenger)
       ↓
[2] Webhook /api/marketing/meta/webhook.ts
    valida firma HMAC, parsea, guarda en Convex
       ↓
[3] Convex marketingLeads.createLeadMessage
    (direction: "inbound", channel: detectado)
       ↓
[4] Auto-trigger con debounce
    (junta mensajes rápidos del mismo lead antes de disparar)
       ↓
[5] triggerPipeline enriquece contexto:
    lead + campaña (tono, AI instructions) +
    últimos 30 mensajes + canales activos
       ↓
[6] Nodo "leadActions" del pipeline
    LLM: Gemini 3.1 Pro
    Herramientas MCP montadas: las +20 del server de leads
       ↓
[7] LLM genera ACCIONES estructuradas, no texto plano:
    addMessage, addMessageChunks, updateStatus,
    createTask, assignLead, scheduleWorkflow
       ↓
[8] Delivery router enruta cada addMessage al provider correcto
    Meta → Graph API
    WhatsApp Bridge (Go) → ChannelBridge DO (WebSocket outbox)
    Crisp / Telnyx / Webchat → handler dedicado
       ↓
[9] El cliente recibe la respuesta POR EL MISMO CANAL
    por donde escribió originalmente

Cada paso es auditable. El código completo está abierto.

Las +20 herramientas MCP que exponemos para leads

Las organizamos en cuatro categorías. Cada una tiene un Zod schema que el LLM lee como parte de su prompt — le da type-safety al modelo en vez de pasarle “haz lo que quieras”.

Lectura (la “memoria” del LLM)

  • search_leads — busca por nombre, email, teléfono, status, tag, channel.
  • get_lead — contexto completo de un lead (campaña, sesiones, tasks).
  • get_messages — historial filtrado por canal/tipo.
  • find_lead_by_channel — buscar por ID externo (ej. manual_whatsapp:521234@lid).
  • get_pending_messages — mensajes redactados pero no enviados (cola de revisión).
  • list_pipelines — qué pipelines de IA están disponibles.
  • list_schedules — workflows agendados a futuro.

Conversación

  • send_message — redacta mensaje saliente (queda pending hasta confirm_message).
  • confirm_message — marca como realmente enviado.
  • import_messages — bulk de histórico (no dispara pipelines, no crea loops infinitos).
  • link_channel — adjunta una identidad de canal externa a una sesión existente.

Estado del CRM

  • create_lead / update_lead — alta y modificación; auto-detecta por teléfono.
  • add_note — nota interna (no llega al lead).
  • assign_lead — enrutar a un humano del equipo + notificar.
  • merge_leads — unir dos leads con sesiones, mensajes y tasks.

Acción

  • create_task / complete_task — tareas atadas al lead.
  • run_pipeline — dispara manualmente un pipeline de IA.
  • schedule_workflow — agenda un pipeline para una fecha/hora futura.
  • cancel_schedule — cancela un agendamiento.

El pipeline visual: dónde se conecta el LLM

LexGuard tiene un editor visual (React Flow) donde el equipo de marketing arma un grafo de nodos:

[trigger: inbound message] → [enrich context] → [LLM con MCP tools] → [route by action]

El nodo “leadActions” es el corazón. Monta el LLM, le inyecta el contexto enriquecido, le da las herramientas MCP. El campo aiInstructions de la campaña entra como system prompt extra — ahí defines cosas como “responde siempre en español neutro, máximo 2 mensajes de 200 caracteres, nunca prometas plazos exactos”.

El punto vendible para equipos no-técnicos: marketing edita la campaña, no el código. El programador tocó este pipeline una vez. Después, cada ajuste de tono es un cambio de texto en la UI.

Routing por canal: por qué la IA debe responder por WhatsApp si entró por WhatsApp

Esto suena obvio y casi nadie lo implementa bien. La regla:

Auto-detecta el canal: elige la sesión conectada más reciente (prefiere los bridges ws_*).

Implicaciones:

  • Si el cliente escribe por Instagram, la IA responde por Instagram aunque también tenga su WhatsApp registrado.
  • Si el cliente cambia a WhatsApp para mandarte un audio, la IA detecta el switch y migra el canal.
  • Nada de “responde por email” cuando el cliente quería respuesta inmediata por WhatsApp.

Esto que parece detalle implementacional es lo que más mueve la sensación de “tu chatbot me entiende” vs “tu chatbot es un robot tonto”.

Acciones, no solo texto

Diferenciador clave vs “el chatbot que solo responde”. El LLM no emite un string — emite una lista de acciones estructuradas:

[
  {
    "type": "addMessageChunks",
    "channel": "ws_whatsapp",
    "chunks": [
      "Hola Juan, qué bueno saber de ti 👋",
      "Te confirmo que el plan PRO sí incluye lo que necesitas para tu taquería."
    ],
    "delayMs": 1500
  },
  { "type": "updateStatus", "status": "interested" },
  { "type": "createTask", "title": "Demo agendado", "dueAt": "2026-05-27T18:00:00" },
  {
    "type": "scheduleWorkflow",
    "projectId": "follow_up_24h",
    "at": "2026-05-26T17:00:00",
    "prompt": "Recuerda confirmar asistencia al demo"
  }
]

Dos detalles que importan:

  • Mensajes en chunks con delay: la respuesta llega como humano (dos burbujas separadas por 1.5 segundos), no como wall-of-text robotizado.
  • Acciones que cambian el CRM: el status del lead se actualiza, se crea un task, se agenda un follow-up — todo en la misma “respuesta” del LLM.

Batch + cron: el schedule_workflow que nadie te cuenta

La herramienta schedule_workflow permite que el LLM diga “agéndame para mañana a las 10am un follow-up con este lead”. Un cron en el worker de Cloudflare (cada 5 minutos) consulta getDueWorkflowSchedules, dispara el pipeline con contexto fresco en ese momento.

Esto es exactamente lo que rompe a Zapier + GPT: el GPT que respondió ayer no recuerda nada hoy. El pipeline cron-driven sí, porque enriquece el contexto desde la base de datos al momento de ejecutar — no desde la conversación de ayer.

Cuando ves “follow-up automático” en otras plataformas, suele ser un mensaje pre-armado. Aquí es una segunda pasada del LLM con todo el historial, las notas, el status actual y la decisión de qué decir basada en lo que pasó desde ayer.

Auth y multi-tenant: cómo evitamos que la IA de un cliente lea los leads de otro

Sección técnica importante para credibilidad. El servidor MCP no es un wrapper alrededor de un modelo — es un sistema con permisos reales:

  • Stateless por diseño: cada request crea un nuevo McpServer. No hay estado compartido entre clientes.
  • Auth: Clerk Bearer token + groupId por query param.
  • Filtros a nivel de base de datos: cada tool recibe el groupId y filtra en la query de Convex (no en el código de la tool). La IA del Cliente A no puede ver los leads del Cliente B, ni accidentalmente, ni con un prompt malicioso.

No es un wrapper alrededor de un modelo. Es un servidor MCP con permisos reales por workspace, auditables, con logs por tool call.

Por qué le gana al chatbot tradicional

Tabla de cierre:

Chatbot tradicionalLexGuard + MCP
Memoria entre canales❌✅ (mismo lead = mismo contexto)
Acciones reales en el CRM❌✅ (createTask, updateStatus)
Routing por canal de entradaA veces✅ (preferencia explícita)
Permisos multi-tenant❌✅ (Clerk + groupId)
Follow-up agendado por la IA❌✅ (schedule_workflow + cron)
Cambiar tono sin tocar código❌✅ (campaign.aiInstructions)

La idea grande

Si tu equipo de ventas tiene un chatbot que “más o menos contesta” y necesitas que tu equipo humano lo babysittee, no es problema del modelo. Es problema de contexto y de permisos. MCP resuelve los dos: le da al LLM acceso vivo a tu base de datos, y le da al servidor el poder de decidir qué puede hacer la IA — sin que el LLM tenga que adivinarlo.

En Aztecknology llevamos un año construyendo sobre MCP con LexGuard. Resolvimos los problemas que nadie te cuenta: routing por canal, throttling, auth multi-tenant, batch jobs, idempotencia, follow-ups con contexto fresco. Si tienes leads multicanal y necesitas que la IA los maneje de verdad, hablemos. Es exactamente el tipo de problema que resolvemos.

¿Quieres ver el código? Las +20 herramientas MCP de leads están en src/lib/mcp/leads-tools.ts. El registro del servidor MCP en src/pages/api/mcp/marketing.ts. El webhook de entrada en src/pages/api/marketing/meta/webhook.ts. El enrichment de contexto en src/lib/pipeline/trigger-pipeline.ts. El router de entrega multi-provider en src/lib/deliver.ts. Todo es auditable.

Posts relacionados de la serie: