MCP en publicidad: el media buying con agentes de IA
Los servidores MCP dan a los agentes de IA una forma estándar de consultar datos de rendimiento publicitario. Esto es lo que el acceso de solo lectura implica para el reporting y la gobernanza.
El cambio relevante no es que la IA gestione tus campañas. Es que, por primera vez, puede preguntarles cosas. De forma estándar. Sin que tu equipo construya un puente nuevo cada vez que cambia el flujo de trabajo.
Eso es lo que está empezando a pasar: las propias plataformas publicitarias están publicando servidores MCP, conectores pensados para que un agente de IA consulte datos de campaña a través de una interfaz común. No es un dashboard nuevo. Es la forma en que tareas de reporting, QA y optimización podrían dispararse desde un lenguaje natural.
Google ya ha publicado una guía de integración para un servidor MCP de Google Ads. Hablemos de qué significa para quien compra medios.
Qué es un servidor MCP de publicidad
MCP son las siglas de Model Context Protocol: un estándar abierto que permite a los modelos de lenguaje conectarse de forma segura con datos y aplicaciones externas.
Traducido: es un enchufe común. En lugar de que cada herramienta y cada flujo tengan su propia conexión a medida, el agente descubre un conjunto de “herramientas” aprobadas para una plataforma, las llama, y recibe la respuesta de vuelta ya estructurada, dentro de su contexto.
Esa capa de tool calling es la que importa. Formaliza cómo un agente se conecta a los datos de una cuenta publicitaria. Y al formalizarlo, te ahorra el patrón de siempre: un script de usar y tirar por cada tarea, mantenido a mano, que se rompe cada vez que algo cambia.
El MCP propone lo contrario: una interfaz reutilizable que cualquier host de IA compatible puede invocar.
Qué expone hoy el servidor MCP de Google Ads
En su versión actual, Google lo plantea como un puente estandarizado hacia la API de Google Ads: el agente analiza y recupera datos de campaña usando lenguaje natural, y el servidor se encarga de la autenticación, la consulta y el parseo.
La ficha técnica que conviene tener delante:
Modo: solo lectura (versión actual)
Lenguaje: Python
Transporte: entrada/salida estándar (stdio)
Autenticación: OAuth 2.0 o cuenta de servicio
Y las herramientas que expone, orientadas a descubrir cuentas y reportar:
list_accessible_customers: devuelve los IDs y nombres de las cuentas a las que tienes acceso.search: ejecuta consultas en GAQL (el lenguaje de consulta de Google Ads) para sacar métricas, presupuestos y estados.get_resource_metadata: inspecciona qué campos hay disponibles para un recurso, por ejemplo “campaign”.
La guía insiste además en la flexibilidad de despliegue: puedes alojarlo en local o llevarlo a una infraestructura como Cloud Run para compartirlo entre varios agentes o servirlo como un servicio.
Traducido: de momento, mira pero no toca.
Por qué “solo lectura” ya cambia el día a día
Aquí está la parte que casi todo el mundo se salta.
Aunque el servidor no pueda escribir (no cambia pujas, no pausa, no toca presupuestos) mueve dónde se gasta el tiempo en performance.
Piensa en la pregunta más repetida de cualquier semana: “¿Cómo va la campaña?”. Si un agente la responde consultando la API y devolviendo algo estructurado y fiable, pasan tres cosas a la vez: reduces los pulls manuales repetitivos, dejas de depender de la cola del analista para preguntas básicas, y estandarizas la forma en que todos piden los datos.
Y cambia algo más profundo: qué entendemos por “interfaz”.
La interfaz deja de ser solo la UI de la plataforma. Pasa a ser la suma de tres cosas:
Las herramientas que la plataforma expone.
El modelo de permisos que hay detrás de esas herramientas.
La gobernanza sobre quién puede preguntar qué, y sobre qué cuentas.
Lo que deberías llevarte de aquí
El acceso estandarizado es una palanca de escala, no una comodidad para developers. Cuando una plataforma expone un mismo conjunto de herramientas, puedes construir comportamientos repetibles (chequeos de pacing semanales, detección de anomalías, consolidados multicuenta, etc.) sin reimplementar el mismo conector una y otra vez.
“Solo lectura” basta para rediseñar reporting, QA y comunicación con stakeholders. La mayoría de las peticiones en una organización de medios son diagnósticas: qué ha cambiado, qué tendencia hay, qué está disparando el gasto. Buena parte del trabajo de narrar el rendimiento se puede automatizar sin tocar una sola puja.
La gobernanza entra en el stack de media ops. Si los agentes consultan cuentas vía OAuth o cuentas de servicio, toca poner foco en la gestión de credenciales, los permisos por herramienta y la auditabilidad de las consultas del agente. Crítico en entornos multimarca o de agencia, donde no da igual quién pregunta qué.
La ventaja se mueve a las preguntas y las rutinas, no al dashboard. Cuando consultar es fácil, gana quien codifica mejores preguntas de medición, define una lógica de pacing consistente y operativiza cómo un insight se convierte en decisión.
El próximo paso
Con el tiempo, esto comprime el bucle entre “pregunta” y “respuesta” en performance. Y reduce la fragilidad de los flujos que hoy dependen de scripts mantenidos por dos o tres especialistas.
Para quien compra medios, el movimiento práctico es tratar los MCP de plataforma como una capa de interfaz emergente, y luego decidir dónde vive el acceso del agente: dentro de tu entorno de analítica interno, dentro del stack de reporting de la agencia, o dentro de un asistente gobernado que usen los equipos de cuenta.
El dashboard deja de ser el producto.
La pregunta pasa a serlo.