Marketing: API y herramientas MCP

Esta página explica Marketing desde el punto de vista de la API y de las herramientas MCP: para quien integra, para los asistentes de IA que trabajan con Marketing por MCP y para quien quiere entender qué hay detrás de cada acción de la interfaz.

API del panel, no API externa. A diferencia de casi todo el resto de esta sección, las rutas de Marketing están bajo /api/email-marketing/...: son la API del panel y se llaman con la sesión de un usuario (Authorization: Bearer <token>), no con X-Api-Key. No hay API externa con clave para Marketing: para automatizar estas operaciones se usan las herramientas MCP de más abajo. El prefijo email-marketing se mantiene por compatibilidad; en la interfaz el aplicativo se llama Marketing.

Pruebas A/B

Las pruebas A/B comparan dos o más versiones de un correo enviando cada una a una muestra de la audiencia y, una vez declarado el ganador, envían esa versión al resto. El ciclo está integrado de principio a fin: la muestra se reparte de forma determinista, las variantes no se mezclan con las campañas normales en el listado, y el envío del ganador alcanza de verdad a la audiencia restante.

El listado de campañas (GET /api/email-marketing/campaigns) trae el campo isAbTest y la relación de variantes, y no muestra las variantes como campañas sueltas: así distingues sin error una campaña con prueba A/B de una normal.

Cierre comercial: clic a oportunidad o lead

Desde los resultados de una campaña, los destinatarios que hicieron clic pueden convertirse en entidades comerciales del CRM. El flujo es asistido: el solicitante decide qué crear, y las entidades se derivan siempre de la propia campaña dentro del ámbito del tenant (el cuerpo nunca acepta identificadores ni correos, para evitar referencias indirectas a recursos ajenos).

Los dos endpoints exigen el aplicativo CRM en el plan, no el de Marketing, porque lo que se lee y se crea son entidades del CRM. convert-clicks exige además la capacidad de cada tipo que se pida (crm.opportunities para las oportunidades, crm.leads para los leads). Una organización con Marketing pero sin CRM recibe un bloqueo de plan, no un error de permisos.

Parámetros de consulta de conversion-candidates (ambos opcionales):

pageentero

Página del listado detallado. Mínimo 1. Por defecto 1.

limitentero

Tamaño de página. Entre 1 y 100. Por defecto 25.

Cuerpo de convert-clicks:

createOpportunitiesbooleano

Crea oportunidades para quienes hicieron clic y tienen ficha de contacto. Requiere OPPORTUNITIES_CREATE y la capacidad crm.opportunities.

createLeadsbooleano

Crea leads para quienes hicieron clic y no tienen ficha de contacto. Requiere LEADS_CREATE y la capacidad crm.leads.

opportunityStageenum OpportunityStage

Etapa inicial de las oportunidades creadas. Por defecto QUALIFICATION. Solo aplica si createOpportunities es true.

conversionConfirmedbooleano

Confirmación expresa. Formalmente opcional, pero obligatoria en la práctica: sin ella, cualquier llamada que fuese a crear registros se rechaza. Solo se puede omitir cuando no hay nada pendiente de convertir.

La respuesta resume cuántas entidades se crearon y cuántas se omitieron por ya existir:

{
  "opportunities": { "created": 3, "skipped": 1 },
  "leads": { "created": 5, "skipped": 0 }
}

Las entidades creadas llevan el origen email-marketing:<id de la campaña>. Si vuelves a llamar al endpoint con la misma campaña, no se duplican: las que ya existen se cuentan en skipped. Se comprueba el permiso de cada tipo que se va a crear (LEADS_CREATE para los leads, OPPORTUNITIES_CREATE para las oportunidades) y se respeta su alcance.

Automatizaciones: plantillas, prueba de flujo y pasos comerciales

Las automatizaciones son secuencias de pasos que se ejecutan al producirse un disparador. Incluyen una galería de plantillas, la prueba de flujo y dos pasos que conectan con el CRM.

Plantillas de flujo disponibles

Disparadores

El conjunto de disparadores (AutomationTrigger) es: LEAD_CREATED, CONTACT_CREATED, CLIENT_CREATED, LEAD_CONVERTED, TAG_ADDED, LIST_SUBSCRIBED, DATE_BASED y MANUAL. Conviene destacar dos de ellos:

• TAG_ADDED: se dispara al añadir una etiqueta concreta a un lead o cliente del CRM.
• DATE_BASED: un proceso diario recorre las fechas configuradas (por ejemplo, el cumpleaños del contacto) y dispara la automatización en el día correspondiente, respetando la zona horaria de la organización.

Pasos que crean entidades del CRM

El conjunto de tipos de paso (AutomationStepType) incluye dos acciones de cierre comercial: CREATE_OPPORTUNITY (crea una oportunidad para la entidad de la ejecución) y CREATE_LEAD (crea un lead de captación a partir de la entidad de la ejecución).

Segmentos dinámicos: leads y filtro por facturación

El filtro de un segmento dinámico (listas con sourceType = CRM_SEGMENT) permite distinguir el tipo de audiencia y filtrar por estado de cobro.

El filtro se usa tanto al crear o actualizar una lista de tipo segmento como en la previsualización en vivo (POST /api/email-marketing/lists/preview-segment).

Etiquetas del CRM (autocompletado)

Parámetros de consulta:

qtexto (máx. 64)

Filtra las etiquetas que contienen la subcadena (insensible a mayúsculas).

entityTypelead | client | all

Entidad cuyas etiquetas se consultan. Por defecto all.

limitentero (1 a 50)

Número máximo de etiquetas. Por defecto 20.

Solo los leads y los clientes tienen etiquetas (tags); los contactos no, por eso entityType solo admite lead, client o all.

Exportar el informe de una campaña

Informes y analítica

Las métricas de una campaña y los agregados del periodo se sirven bajo /api/email-marketing/analytics/.... El reparto de permisos no es caprichoso: lo que responde a «cómo le fue a esta campaña» exige EMAIL_MARKETING_VIEW, el mismo permiso con el que se abre su ficha, y lo que permite comparar campañas entre sí y deducir hábitos de la audiencia exige EMAIL_MARKETING_ANALYTICS, que es justo lo que la interfaz oculta con ese permiso.

Las claves siguen en inglés, pero cuentan otra cosa. Desde agosto de 2026 las cifras cambiaron de base, no solo de rótulo: accepted son los correos de los que el servidor de destino se hizo cargo incluidos los que después rebotaron; delivered son los aceptados sin rebote y vale null si la organización no tiene activada la detección de devueltos; bounced deja de sumar los fallos de salida y bounceRate se calcula sobre aceptados. sent se conserva y no es sinónimo de accepted. deliveryRate queda sustituida por acceptanceRate. Las definiciones completas, con su denominador, están en Definiciones de las métricas de Marketing.

Medición del origen

Las etiquetas que se añaden a los enlaces de los correos y el identificador firmado del destinatario se configuran en un controlador propio, /api/email-marketing/tracking-settings.

Las campañas admiten además tres campos anulables en POST /api/email-marketing/campaigns y PATCH /api/email-marketing/campaigns/:id —utmMode (RESPECT u OFF), utmParams y trackingIdentityEnabled— donde null significa «hereda de la organización», que no es lo mismo que no enviar el campo. GET /api/email-marketing/campaigns/:id devuelve el bloque tracking con la configuración efectiva ya resuelta y de dónde sale cada valor.

Los formularios de captación admiten captureUtm y utmPersistence en PATCH /api/lead-forms/:id, y el envío público (POST /api/v1/forms/:slug/submit) acepta _utm y _ur junto al _pageUrl que ya viajaba. Está documentado en Endpoints de formularios públicos.

Enlaces con el dominio del cliente

Los enlaces medidos de una campaña pasan por UTILIA para poder contar los clics, así que por defecto apuntan a un dominio nuestro aunque el correo lo firme el dominio del cliente. Este controlador, /api/email-marketing/tracking-domains, permite que apunten a un subdominio suyo. Es una pieza distinta del dominio de ENVÍO (SPF, DKIM, DMARC) y de la RUTA de envío: aquel responde «quién firma», la ruta «por dónde sale» y este «por dónde vuelve el clic».

Las cuatro escrituras que levantan infraestructura necesitan las dos capacidades. POST /tracking-domains, POST /:id/verify, PATCH /:id/emission y POST /:id/retry-certificate exigen las dos capacidades del lote de medición, Analítica avanzada de Marketing y Negocio por campaña. Sin alguna de ellas responden 403 con errorCode: "CAPABILITY_NOT_ENABLED", que se resuelve contratando y no concediendo permisos.

POST /:id/retire no lleva esa puerta, y tampoco es un olvido: es la salida. Quien deja de tener las capacidades conserva su subdominio sirviendo los enlaces ya enviados y tiene que poder soltarlo sin depender de volver a contratar.

El seguimiento público de aperturas y clics no lleva puerta de aplicativo ni de capacidad: ponerla rompería los enlaces de los correos ya enviados de cualquier cliente que cambie de plan.

Negocio originado por campaña

Necesita el plan que incluye «Negocio por campaña». Todos estos endpoints están detrás de la capacidad Negocio por campaña, que además exige tener contratado el aplicativo CRM. Sin ella responde 403 con errorCode: "CAPABILITY_NOT_ENABLED", que no es lo mismo que una falta de permiso: se resuelve contratando, no concediendo permisos. Ver Errores de plan.

La vista inversa vive en los módulos de la ficha que se pregunta, no aquí:

Un bloque que no se puede ver no viaja con cero ni con null. La regla de contrato de estos endpoints es que un bloque que quien pregunta no puede ver no aparece en el JSON. En su lugar aparece su motivo en excludedBlocks, con block, reason (missing_permission, missing_scope, missing_module o missing_capability) y, según el caso, permission, moduleKey o capabilityKey.

Existe para que ninguna capa pueda pintar un cero engañoso por descuido: un cero afirma que no hubo negocio, y ahí sería falso la mitad de las veces.

Viajan además scopeLimited (el ámbito de filas de quien pregunta recorta lo agregado), truncated (se tocó el tope y la cifra es un mínimo), measuredSince (desde cuándo hay medición), reconstructed y reconstructedRows. rebuilding (se está reconstruyendo el histórico ahora mismo) viaja solo en la ficha de una campaña, no en el resumen del periodo. Los importes viajan siempre como { currency, amount }, nunca como un número suelto.

Ciclo de vida del envío

Estas rutas gobiernan lo que le pasa a una campaña desde que se decide enviarla hasta que se explica qué le ocurrió a cada correo. Todas viven bajo /api/email-marketing/ y todas exigen el aplicativo Marketing en el plan: sin él responden 403 con errorCode: MODULE_NOT_ENABLED, que es una puerta comercial y no un problema de permisos.

Tres cosas que estas respuestas no afirman:

Aceptado no es entregado. Un correo SENT y un hito ACCEPTED significan que el servidor de destino se hizo cargo del mensaje. Que llegara a una bandeja de entrada no lo sabe nadie salvo quien abra el buzón, y para eso existe el paquete de comprobación, cuya confirmación caduca a los 90 días.

Excluido no es fallido. Desde el 5 de septiembre de 2026, los correos que no salieron a propósito —baja respetada, rebote definitivo anterior, correo desactivado en la ficha, apartado por inactividad o tope de frecuencia— salen de la cifra de fallidos y van en excluded, con su desglose en excludedByReason. La cifra de fallidos de las campañas ya enviadas bajó por eso, no porque nada se haya arreglado.

Automático no es interés. En replies, automatic: true es una respuesta de máquina, normalmente un aviso de ausencia. Un aviso de no entrega no es una respuesta.

Entregabilidad operativa

/api/email-marketing/sending-routes/... no depende del aplicativo Marketing, sino de la capacidad Servidor de envío propio: la identidad de envío afecta también a facturas, presupuestos, portal y avisos, que existen en todos los planes. Entre sus nueve rutas está GET /sending-routes/:id/header-report (qué cabeceras llevaría el correo, sin enviarlo). Ninguna devuelve claves privadas ni el secreto de la ruta.

Herramientas MCP

Las operaciones anteriores se exponen a los agentes de inteligencia artificial mediante las herramientas MCP del servidor Marketing (POST /api/mcp/marketing, documentado en Servidor MCP Marketing). Cada operación se controla con su permiso concreto; las operaciones que crean entidades del CRM o disparan envíos masivos exigen permisos adicionales o confirm: true.

marketing_campaigns

Gestión completa de campañas. Operaciones: list, get, create, update, delete, send, get_send_status, schedule, pause, resume, cancel, duplicate, test_send, preview, preview_html, by_contact, get_branding, update_branding, conversion_candidates, convert_clicks, delivery_summary, export, list_recipients, recipients_preview, add_recipients, remove_recipient, remove_recipients, retry_failed, failure_summary, sending_quota, edit_content, engagement_breakdown, resend_preview, create_resend y list_resends.

create y update aceptan además utmMode, utmParams y trackingIdentityEnabled (los tres anulables, donde null significa «hereda de la organización»), y get devuelve el bloque tracking con la configuración efectiva ya resuelta. No son operaciones nuevas: son campos del mismo create y update de siempre.

• pause / resume: pausan y reanudan un envío en curso sin perder el progreso (a diferencia de cancel, que es irreversible). Exigen EMAIL_MARKETING_SEND, igual que el envío.
• conversion_candidates: lectura del resumen de clicantes (permiso EMAIL_MARKETING_VIEW).
• convert_clicks: crea oportunidades y/o leads. Exige los permisos del CRM (LEADS_CREATE u OPPORTUNITIES_CREATE), no un permiso de marketing.
• preview_html: devuelve el HTML renderizado, opcionalmente con un branding de prueba sin persistir nada.
• get_branding / update_branding: consultan y modifican el branding propio de la campaña (que hereda del branding de la organización).
• export: descarga el informe de la campaña en CSV (permiso EMAIL_MARKETING_EXPORT).
• engagement_breakdown: reparto de la audiencia en los siete grupos de comportamiento. No son porciones de una tarta: opened ya contiene a clicked y a opened_not_clicked. Y not_opened excluye siempre a quien pulsó. Permiso EMAIL_MARKETING_VIEW, sin capacidad de plan.
• resend_preview / create_resend / list_resends: los segundos intentos. Solo admiten los grupos not_opened y opened_not_clicked —a quien se quejó, se dio de baja o rebotó no se le vuelve a escribir—, exigen un asunto distinto del original, admiten como mucho dos por campaña y no tocan los contadores de la campaña original. Los dos primeros exigen la capacidad Analítica avanzada de Marketing; create_resend pide además EMAIL_MARKETING_CREATE.
• list_recipients: gana los filtros isExcluded (incluidos frente a excluidos del envío) y engagement (qué hizo la persona), que es ortogonal a sendStatus. Filtrar por engagement exige la capacidad Analítica avanzada de Marketing; el resto de filtros, no. Los campos deviceType, emailClient y country de cada destinatario se omiten sin el permiso EMAIL_MARKETING_VIEW_RECIPIENT_DETAIL y el scope marketing:recipients:detail:view: la operación responde igual, esos tres campos no viajan y llega recipientDetailIncluded: false. Nunca devuelve un 403 por eso.

marketing_lists

Listas, segmentos del CRM, suscriptores e interés. Operaciones: list, get, create, update, delete, preview_segment, add_contact, remove_contact, add_subscribers, members, list_subscribers, update_subscriber, crm_countries, calculate, engagement_summary, set_aside_inactive y reactivate_subscriber.

members y list_subscribers no son lo mismo: members devuelve la audiencia efectiva de la lista y no admite filtrar por suscriptor; list_subscribers devuelve los suscriptores con su interés y su estado de apartado, y es la única forma de volver a encontrar a quien se apartó.

Apartar no es dar de baja: set_aside_inactive no toca el estado de suscripción, ni la base jurídica, ni la prueba del consentimiento, ni la fecha de confirmación. Esas personas siguen suscritas, dejan de recibir campañas y se pueden reincorporar cuando quieras. Los mínimos (90 días y 2 correos recibidos) los aplica el servidor, no la interfaz.

marketing_deliverability

Reputación, rebotes, quejas, comprobación de direcciones, control de frecuencia y política de quejas. Operaciones: reputation_summary, bounce_rate, complaint_rate, score_by_domain, blocklist_check, dashboard_summary, measurement_coverage, address_check, frequency_cap_get, frequency_cap_set, campaign_deliverability, campaign_bounce_analysis, get_complaint_policy y set_complaint_policy.

Esta herramienta ha dejado de ser de solo lectura: set_complaint_policy cambia la configuración de envío de la organización.

set_complaint_policy solo permite ser más estricto. El 0,3 % que aplican Gmail y Yahoo y el bloqueo del servidor compartido protegen el correo de todas las organizaciones que lo comparten, así que no se configuran por API. Un bloqueo se revisa a diario y se levanta solo en cuanto la tasa baja, o cuando deja de poder evaluarse por falta de volumen.

marketing_reports

Informes y analítica de campañas. Es el espejo exacto de los endpoints de la sección anterior: mismas cifras, mismos permisos y mismo ámbito de filas. Operaciones: campaign_stats, engagement_overview, click_through, top_campaigns, engagement_heatmap, engagement_trends, campaign_attribution, attribution_summary, entity_origin, complaints, link_heatmap y audience_tech. Todas son de solo lectura. Las seis primeras y complaints no exigen capacidad de plan; las de atribución y las dos de F4 sí (ver más abajo).

• complaints: quejas por correo no deseado del periodo, agrupadas por campaña o por dominio del destinatario (complaintsGroupBy). La tasa llega como null —nunca como 0— cuando la organización no tiene ninguna vía por la que enterarse, y cuando hay medición es un suelo. Permiso EMAIL_MARKETING_ANALYTICS.
• link_heatmap: qué enlace concreto se pulsa, con su posición, su texto visible y el reparto de la atención. Distingue dos botones que llevan al mismo sitio, que es lo que click_through no puede hacer. Permiso EMAIL_MARKETING_VIEW y capacidad Analítica avanzada de Marketing. El desglose por dirección de destino de siempre (click_through) sigue siendo gratuito.
• audience_tech: aparato, programa de correo o país (dimension), a partir de los clics por defecto (source). El país es aproximado y sale de una base de datos local, nunca de una consulta a un tercero. Con menos de 20 clics llega sufficientSample: false y no debe presentarse. Permiso EMAIL_MARKETING_VIEW y capacidad Analítica avanzada de Marketing.

• campaign_stats devuelve el bloque stats con los recuentos (accepted, delivered, sent, opened, clicked, bounced, unsubscribed), las tasas (acceptanceRate, openRate, clickRate, clickToOpenRate, bounceRate, unsubscribeRate), el bloque metricsAvailability y la señal bounceDetectionEnabled. Una métrica que metricsAvailability marca como no disponible no es un cero: preséntela como «sin datos» o su asistente afirmará algo que nadie ha medido.
• clickToOpenRate («Clics por apertura») se divide entre las aperturas únicas, no entre los correos aceptados, y puede superar el 100 % cuando hay gente que pulsa sin que se registre su apertura. No lo recorte.
• top_campaigns admite metric: OPENS | CLICKS | CTR | CONVERSIONS | REVENUE_ISSUED | REVENUE_COLLECTED. CONVERSIONS ordena por oportunidades originadas, no por ventas cerradas; hasta agosto de 2026 devolvía un error diciendo que el producto no registra conversiones, y eso ya no es cierto. Las dos métricas de dinero exigen INVOICES_VIEW y la capacidad de plan. El ranking excluye los reenvíos y las variantes de una prueba A/B, que competirían contra su propia campaña madre. minSent deja fuera las campañas de poco volumen, donde una tasa altísima sobre tres envíos no dice nada.
• click_through agrupa por la dirección original del enlace, no por la dirección de redirección con la que se mide el clic: dos destinatarios que pulsan el mismo enlace cuentan en la misma fila.

Los importes no viajan por el servidor MCP de marketing. El token de /api/mcp/marketing solo admite scopes marketing:*, org:email-senders:* y crm:*:view: nunca puede portar finance:invoices:view. Por ese carril llegan los recuentos y las tasas de conversión, y el bloque de dinero se declara ausente en excludedBlocks con reason: "missing_scope". No lo presentes como un cero. Las cifras están en la pantalla de Marketing y en los endpoints REST de la sección anterior.

Por el mismo motivo, entity_origin cubre oportunidad y cliente, pero no factura: el origen comercial de una factura está solo en GET /api/finance/invoices/:id/commercial-origin.

marketing_tracking_settings

Configuración de medición de la organización. Tres operaciones: get, update y preview_link.

• preview_link es una función pura: no escribe nada, no firma nada y no emite ningún identificador de destinatario real.
• update solo exige capacidad de plan si la llamada trae recipientTokenEnabled. Apagar los parámetros de origen no está detrás de ningún muro de pago.
• La plantilla admite cinco marcadores y ninguno más: {{campaign.name}}, {{campaign.id}}, {{campaign.type}}, {{variant}} y {{date}}.

Los formularios de captación reciben captureUtm y utmPersistence como propiedades de org_integrations_settings → lead_forms_create y lead_forms_update. No hay operaciones nuevas en esa herramienta.

Con tipos en los dos SDK. marketing_reports está cubierta entera en el SDK de JavaScript (sdk.mcp.marketing.reports.campaignStats(...), engagementOverview, clickThrough, topCampaigns, engagementHeatmap, engagementTrends, campaignAttribution, attributionSummary y entityOrigin), y también marketing_tracking_settings (sdk.mcp.marketing.trackingSettings.get(), update(...) y previewLink(...)) y email_tracking_domains (sdk.mcp.marketing.trackingDomains, sus ocho operaciones). Los mismos nombres en snake_case en el SDK de Python, en las variantes asíncrona y síncrona. Más en la referencia del SDK.

email_tracking_domains

El dominio propio por el que vuelve el clic. Ocho operaciones: list, get, get_setup_instructions, create, verify, set_emission, retry_certificate y retire. Espejo exacto del controlador REST de arriba.

• verify y retire exigen confirm: true: la primera consulta el DNS real y tiene tope de cinco por minuto; la segunda pone fecha al fin del servicio.
• Ninguna operación borra nada. La herramienta declara destructiveHint: false y es literal, no un descuido de anotación.
• No se inventa ningún scope: se reutilizan los dos de entregabilidad, que a diferencia de org:email-senders:* no los expanden crm:full ni dev:full.
• Cuatro escrituras exigen capacidad de plan, igual que en el REST: create, verify, set_emission y retry_certificate necesitan las dos capacidades del lote de medición, Analítica avanzada de Marketing y Negocio por campaña. Las lecturas y retire no llevan esa puerta: retirar es la salida y tiene que poder hacerse aunque cambie el plan.

marketing_automations

Diseño y gestión de automatizaciones. Operaciones: list, get, validate, create, update, replace_steps, delete, activate, pause, bulk_set_status, test_trigger, duplicate, add_step, update_step, remove_step, list_templates, create_from_template, list_runs, get_run, retry_run, cancel_run, stats.

• validate: comprueba una definición entera (nombre, disparador, triggerConfig y pasos) con los mismos validadores que el guardado, sin persistir nada; devuelve la lista de problemas en castellano. Solo lectura (EMAIL_MARKETING_VIEW).
• replace_steps: sustituye el flujo entero de pasos en una llamada (equivale a update con steps); exige EMAIL_MARKETING_EDIT.
• bulk_set_status: activa o pausa hasta 25 automatizaciones con resultado por id (los fallos no detienen el resto); con action: "activate" exige confirm: true. Permiso EMAIL_MARKETING_EDIT.
• duplicate: crea una copia en borrador («X (copia)») con disparador, configuración y pasos; exige EMAIL_MARKETING_CREATE.
• list_templates: catálogo de plantillas de flujo (permiso EMAIL_MARKETING_VIEW).
• create_from_template: crea la automatización en borrador desde una plantilla (templateKey); exige EMAIL_MARKETING_CREATE. Acepta name y departmentIds opcionales.
• test_trigger: prueba el flujo contra un contacto; con dryRun: true (por defecto) solo simula, y con dryRun: false ejecuta un run de prueba real marcado como test, fuera de las métricas. Exige EMAIL_MARKETING_EDIT.
• list_runs / get_run / retry_run / cancel_run: consultan las ejecuciones de una automatización, reintentan una concreta o la cancelan. Las dos lecturas van con EMAIL_MARKETING_VIEW; cancel_run exige EMAIL_MARKETING_EDIT y retry_run exige EMAIL_MARKETING_SEND, porque reenvía correos reales.

marketing_ab_testing

Ciclo completo de pruebas A/B sobre una campaña. Operaciones: setup, add_variant, remove_variant, split_recipients, comparison, determine_winner, send_winner, disable.

• comparison es de solo lectura (EMAIL_MARKETING_VIEW).
• El resto de operaciones exigen EMAIL_MARKETING_AB_TESTING.
• send_winner dispara un envío masivo y requiere confirm: true.

El resto de herramientas del servidor

Las ocho anteriores son las que cubre esta página en detalle, pero el servidor Marketing expone quince en total. Estas siete no se documentan aquí; su esquema completo (parámetros, permisos y descripciones) viaja en el propio tools/list del servidor MCP:

Relación con otros módulos

• El cierre comercial conecta Marketing con el CRM: un clic interesado se convierte en oportunidad o en lead.
• El filtro de facturación de los segmentos se apoya en Finanzas para segmentar por estado real de cobro.
• La guía de uso del módulo, con el flujo completo de la interfaz, está en Campañas de correo.
• Qué cuenta exactamente cada cifra de marketing_reports y sobre qué se divide, en Definiciones de las métricas de Marketing.

Siguiente paso

Si vas a trabajar con Marketing por MCP, empieza por los primeros pasos con MCP para la autenticación y el formato de las llamadas, y luego usa las herramientas de arriba para crear campañas, consultar sus resultados, lanzar pruebas A/B y diseñar automatizaciones desde código.