Servidor MCP de Google Ads: Guía de Configuración y Limitaciones

La trampa del “solo lectura” que nadie te cuenta

Imagina que has pasado tres semanas montando el entorno. Tienes el Developer Token de la Google Ads API aprobado, el proyecto en Google Cloud habilitado, OAuth 2.0 configurado o cuenta de servicio lista. Conectas tu modelo de lenguaje favorito al servidor MCP oficial de Google Ads.

Le preguntas: “¿Qué campañas están desperdiciando presupuesto en la última semana?”

El modelo ejecuta la consulta GAQL, recupera los datos y te da una respuesta brillante. Identifica que la campaña X tiene un ROAS de 0,8 y sugiere pausarla o bajar el presupuesto.

Y ahí se acaba.

El servidor oficial de Google está diseñado estrictamente en modo de solo lectura. Enfocado en diagnóstico y análisis de métricas. No hay herramientas para ajustar pujas. No hay forma de pausar términos. No puedes crear anuncios. Es un espejo muy potente, pero no es un volante.

Si esperabas que la IA no solo analizara, sino que actuara, te vas a encontrar con un muro. Y ese muro es el motivo por el que muchos equipos están evaluando alternativas que sí permiten ejecución, no solo observación.

¿Qué es exactamente el servidor MCP de Google Ads?

Vamos a desmontar la arquitectura porque aquí hay matices que importan.

El servidor es un proyecto de código abierto desarrollado en Python. Vive en el repositorio oficial de GitHub de Google y corre bajo licencia Apache-2.0. Eso significa que puedes clonarlo, leer el código, modificarlo localmente (si quieres) y entender cómo se comunica con la API de Google Ads.

La herramienta central es search. Esta permite a los modelos de lenguaje ejecutar consultas en tiempo real utilizando Google Ads Query Language (GAQL). Si no dominas GAQL, no te preocupes: el LLM traduce tu lenguaje natural a GAQL. Le pides “mostrame el CTR de las campañas de búsqueda en España los últimos 7 días” y el modelo construye la query, la ejecuta contra la API y te devuelve el resultado.

Hay otra herramienta importante: list_accessible_customers. Sirve para identificar y listar las cuentas de Google Ads a las que tiene acceso el usuario autenticado. Crítico si gestionas múltiples clientes o marcas. Sin esto, tu IA no sabe qué cuenta está consultando.

La autenticación admite flujos de credenciales OAuth 2.0 y el uso de cuentas de servicio (Service Accounts). Ojo: el servidor requiere obligatoriamente un Developer Token de la Google Ads API y un proyecto habilitado en Google Cloud. No es “plug and play”. Hay fricción inicial.

En cuanto a despliegue, admite mecanismos de transporte mediante entrada/salida estándar (stdio) y conexiones HTTP/SSE para despliegues en servicios como Google Cloud Run. Si tu equipo de ingeniería es pequeño, el modo stdio local es lo más práctico. Si buscas algo escalable, HTTP/SSE sobre Cloud Run tiene sentido.

Finalmente, el servidor permite activar o desactivar herramientas específicas y personalizar prefijos de espacios de nombres mediante el archivo tools_config.yaml. Esto te da granularidad. Si solo quieres consultas de rendimiento y no quieres exponer otras capacidades, lo configuras ahí.

Por qué la IA no puede tocar tu cuenta de Ads (todavía)

Aquí viene la opinión que no vas a escuchar en muchos hilos de LinkedIn: la limitación de solo lectura no es un fallo de ejecución. Es una decisión de riesgo.

Google sabe que un error de un LLM en una campaña de Ads no es un error “bonito”. No es un texto mal escrito que puedas corregir. Es dinero quemado. Es una puja disparada que te lleva al primer resultado de la SERP durante 24 horas. Es una audiencia mal segmentada que arruina el ROAS de un trimestre entero.

Al mantener el servidor en modo diagnóstico, Google se protege. Y te protege a ti. Pero también te limita.

La realidad es que el ciclo completo de optimización de Ads tiene dos fases:

1. Diagnóstico: ¿Qué está pasando? ¿Por qué?
2. Acción: Ajustar pujas, pausar términos, crear variaciones, reasignar presupuesto.

El MCP oficial cubre el 80% del diagnóstico con gran potencia. Pero el 20% de la acción, que es donde se genera el ROI, queda fuera.

Esto no significa que debas ignorarlo. Significa que debes complementarlo. Necesitas una capa de ejecución. Y aquí es donde las plataformas que integran IA con ejecución real, como la automatización de publicidad de Amazon con IA, ofrecen un enfoque distinto: no solo te dicen qué hacer, sino que lo hacen.

Ojo, Amazon y Google no son el mismo ecosistema. Pero el principio es el mismo: la IA debe cerrar el bucle. Si tu herramienta de IA solo mira, tu equipo sigue trabajando manual en la ejecución. Y ese trabajo manual es exactamente lo que querías eliminar.

Cómo configurarlo sin volverte loco

Si decides probar el servidor oficial, este es el mapa de ruta. No es trivial, pero es factible.

Requisitos previos:

• Developer Token de la Google Ads API. Si no lo tienes, pídelo. El proceso de aprobación puede tardar días.
• Proyecto habilitado en Google Cloud.
• Credenciales OAuth 2.0 o cuenta de servicio configurada.

Despliegue local (stdio):

1. Clona el repositorio de GitHub.
2. Instala dependencias Python.
3. Configura las variables de entorno con tu Developer Token y credenciales.
4. Conecta tu cliente MCP favorito (Claude Desktop, Cursor, o cualquier LLM que soporte MCP).
5. Configura tools_config.yaml para activar solo search y list_accessible_customers si no necesitas más.

Despliegue en la nube (HTTP/SSE):

1. Empaqueta el servidor.
2. Despliega en Google Cloud Run.
3. Expone el endpoint HTTP/SSE.
4. Configura tu LLM para apuntar a ese endpoint.

El archivo tools_config.yaml es tu palanca de control. Si ves que tu modelo intenta acceder a herramientas que no has habilitado, ajusta el prefijo de espacio de nombres. Si quieres que solo haga consultas de rendimiento, desactiva el resto.

Un consejo de campo: no conectes tu MCP a una cuenta de producción el primer día. Usa una cuenta de prueba. Deja que el LLM “exploré” la estructura. Verás cómo construye las queries GAQL. Si las queries son raras, ajusta el prompt. Si son correctas, ya tienes la base del diagnóstico.

La brecha entre diagnóstico y acción: dónde estás perdiendo tiempo

Aquí está el dolor real. Tienes el MCP configurado. Tu IA te dice que la campaña Y tiene un CPA 40% por encima del objetivo. Le preguntas “¿Por qué?”. Te da un análisis brillante: “El término de búsqueda Z tiene un CTR alto pero una tasa de conversión nula. Sugiero pausarlo.”

Y ahora qué.

Ahora tienes que entrar manualmente en la interfaz de Google Ads. Buscar la campaña. Encontrar el término. Pausarlo. Repetir para otros 15 términos que la IA identificó. Repetir para las 3 cuentas que gestionas.

Eso es 2 horas de trabajo manual por día. Multiplicado por 22 días laborables. Más de 40 horas al mes haciendo click-click en una interfaz que ya debería estar automatizada.

El MCP oficial te da la inteligencia. Pero no te da los músculos.

Esta es la razón por la que muchas marcas están mirando hacia plataformas que integran ambos mundos. En el caso de Amazon, por ejemplo, la analítica de publicidad de Amazon no solo muestra métricas, sino que sugiere acciones y puede ejecutarlas. Es el mismo principio: no basta con saber. Hay que hacer.

Si tu equipo está ahogado en trabajo manual de optimización de Ads, el MCP oficial es un buen paso, pero no es el final del camino. Es el inicio de un sistema híbrido donde la IA diagnostica y tú (o una plataforma de ejecución) actúas.

Qué cambió en 2026 y qué esperar

El lanzamiento del servidor MCP oficial de Google Ads es un hito. No es el primero en el ecosistema, pero sí el más relevante por venir de la propia plataforma. Antes, dependías de implementaciones de terceros o de scripts personalizados. Ahora hay una referencia oficial.

Esto cambia las expectativas. La comunidad de desarrolladores y CMOs ahora espera que Google amplíe las capacidades. La pregunta no es “¿tendremos un MCP oficial?”, sino “¿cuándo añadiremos herramientas de escritura?”.

Mientras tanto, el modelo de solo lectura se ha consolidado como el estándar para diagnóstico. Los equipos están construyendo capas de acción por encima. Algunos usan scripts personalizados que conectan con la API de escritura de Google Ads. Otros, como mencioné antes, están usando plataformas que ya tienen esa capa de ejecución integrada.

De cara a lo que queda de 2026, lo que podemos esperar es:

• Mayor adopción del MCP oficial en equipos de marketing que ya tienen infraestructura de datos.
• Más casos de uso donde el LLM no solo consulta, sino que genera informes ejecutivos para el CMO.
• Presión sobre Google para abrir capacidades de escritura en un futuro servidor o en una extensión.

Pero ojo: no esperes que la escritura llegue mañana. El riesgo es demasiado alto para Google. Mientras tanto, la brecha entre diagnóstico y acción se mantiene. Y esa brecha es espacio de oportunidad para plataformas que ya resuelven el bucle completo.

En ese contexto, vale la pena explorar cómo funciona la conexión MCP de Epinium, que está diseñada para cerrar ese bucle en el ecosistema de commerce, no solo para observar.

FAQ

¿El servidor MCP de Google Ads puede ajustar pujas o pausar campañas?

No. El servidor oficial está diseñado estrictamente en modo de solo lectura. Puede ejecutar consultas GAQL para diagnóstico y análisis de métricas, pero no tiene herramientas para modificar ajustes de campañas, pujas, presupuestos ni términos de búsqueda. Para acciones de escritura, necesitas la API de Google Ads estándar o una plataforma de terceros que integre ejecución.

¿Qué necesito para instalar el servidor MCP de Google Ads?

Necesitas un Developer Token de la Google Ads API, un proyecto habilitado en Google Cloud y credenciales OAuth 2.0 o una cuenta de servicio. El servidor está escrito en Python y puedes clonarlo desde el repositorio oficial de GitHub. También necesitas un cliente de LLM que soporte el protocolo MCP, como Claude Desktop o cualquier herramienta compatible.

¿Puedo desplegar el servidor MCP en la nube?

Sí. El servidor admite mecanismos de transporte mediante entrada/salida estándar (stdio) y conexiones HTTP/SSE para despliegues en servicios como Google Cloud Run. Si buscas escalabilidad o acceso multiusuario, el despliegue HTTP/SSE en Cloud Run es la opción recomendada. El modo stdio es ideal para uso local en tu equipo de desarrollo.

¿Qué es la herramienta search en el servidor MCP?

Es la herramienta principal que permite a los modelos de lenguaje ejecutar consultas en tiempo real utilizando Google Ads Query Language (GAQL). Traduce lenguaje natural a consultas GAQL y devuelve los resultados directamente al LLM. Es la puerta de entrada al diagnóstico de tus campañas.

¿Puedo activar o desactivar herramientas específicas?

Sí. El servidor incluye un archivo tools_config.yaml que te permite activar o desactivar herramientas específicas y personalizar prefijos de espacios de nombres. Esto te da control granular sobre qué capacidades expone tu instancia del MCP a tu modelo de lenguaje.

¿El servidor MCP oficial es de código abierto?

Sí. Es un proyecto de código abierto desarrollado en Python bajo licencia Apache-2.0, disponible en el repositorio oficial de GitHub de Google. Puedes inspeccionar el código, modificarlo localmente y entender cómo se comunica con la API de Google Ads.

¿Qué diferencia hay entre el MCP oficial y las plataformas de automatización de Ads?

El MCP oficial es una capa de diagnóstico. Conecta tu LLM con tus datos de Ads para que puedas preguntar y obtener respuestas basadas en datos en tiempo real. Las plataformas de automatización, por otro lado, suelen incluir tanto diagnóstico como ejecución: pueden ajustar pujas, pausar términos y crear anuncios. El MCP es una pieza del rompecabezas, no el rompecabezas completo.

¿Necesito saber GAQL para usar el servidor MCP?

No. El modelo de lenguaje traduce tu lenguaje natural a GAQL. Le preguntas “¿cuál es el ROAS de la campaña X en los últimos 7 días?” y el modelo construye la consulta GAQL, la ejecuta y te da el resultado. Solo necesitas entender la lógica de negocio detrás de tus métricas, no la sintaxis de la API.

¿El servidor MCP funciona con múltiples cuentas de Ads?

Sí. Incluye la herramienta list_accessible_customers para identificar y listar las cuentas de Google Ads a las que tiene acceso el usuario autenticado. Esto es crítico si gestionas múltiples marcas o clientes. Puedes configurar tu LLM para que filtre por cuenta específica en cada consulta.

¿Es seguro conectar el MCP a mi cuenta de producción?

Técnicamente sí, porque es de solo lectura. No puede modificar nada. Pero te recomiendo empezar con una cuenta de prueba. Deja que el LLM explore la estructura de tus campañas y verifica que las consultas que genera son correctas. Si ves queries raras o mal formadas, ajusta el prompt antes de conectar la cuenta real. La seguridad del diagnóstico no es el riesgo; el riesgo está en la interpretación que hagas de los datos.

El diagnóstico es el 50% del viaje

El servidor MCP oficial de Google Ads es una herramienta potente. No es perfecta. No cierra el bucle. No ejecuta acciones. Pero te da acceso directo a tus datos con una capa de inteligencia que antes no existía de forma tan limpia.

El error que veo en muchos equipos es pensar que “si la IA me dice qué hacer, el problema está resuelto”. No. El problema se resuelve cuando lo haces. Y si hacerlo requiere 40 horas al mes de click-click, no has resuelto nada. Has movido el cuello de botella de la decisión a la ejecución.

La estrategia inteligente para 2026 es híbrida: usa el MCP oficial (o cualquier capa de diagnóstico robusta) para la inteligencia. Y complementa con una capa de ejecución, ya sea scripts propios, API estándar o una plataforma que integre ambos mundos.

Si quieres ver cómo se ve esa integración en la práctica, con datos en vivo y acciones ejecutables, prueba la plataforma de Epinium. No te prometo que va a sustituir a tu equipo, pero sí que va a quitarte el trabajo manual repetitivo que te impide pensar en estrategia.