Reach by Locus ejecuta un servidor MCP remoto de Google Business Profile. Un asistente como Claude, ChatGPT o Cursor inicia sesión con OAuth, lee el perfil, las reseñas, los rankings y los leads de un negocio, y hace un cambio público solo después de que el propietario lo apruebe en el chat. Esta publicación explica cómo está construido.
La configuración del propietario está en la página de MCP y en sus guías por cliente. Esta publicación es para desarrolladores y creadores de AI: qué expone el servidor, cómo llega una escritura a Google y las decisiones que hay detrás. Sigue la especificación del Model Context Protocol.
Qué expone el servidor
El servidor usa el transporte HTTP streamable de la especificación MCP (transports), así que no hay nada que instalar ni ejecutar localmente. Sus herramientas se dividen en tres clases, y cada herramienta lleva las anotaciones de la especificación, para que un cliente sepa antes de llamarla si una herramienta solo lee, cambia datos propios de Reach o cambia un listado público de Google (tool annotations).
| Clase | Qué cubre | ¿Público en Google? |
|---|---|---|
| Lectura | Qué cubreLa cuenta y sus ubicaciones, contenido del perfil, reseñas con estado de respuesta, publicaciones y medios, analíticas de rendimiento, rankings de palabras clave rastreadas y competidores cercanos, leads y solicitudes de reserva, y una lista de lo que le falta a cada perfil | ¿Público en Google?No |
| Cambio dentro de Reach | Qué cubreBorradores de respuesta a reseñas, iniciar o detener el rastreo de palabras clave, marcar una recomendación como hecha o descartada, y enviar una solicitud de función al equipo de Reach | ¿Público en Google?No |
| Escritura en Google | Qué cubreEdiciones de campos del perfil y de área de servicio, subidas y borrados de fotos y vídeos, publicación de publicaciones y envío de respuestas a reseñas | ¿Público en Google?Sí |
El servidor también ofrece prompts MCP, las instrucciones reutilizables de inicio de la especificación (prompts): uno optimiza un perfil un cambio confirmado a la vez, uno revisa la visibilidad en búsquedas y uno trabaja con reseñas sin responder. Un cliente los muestra como solicitudes listas.
Cada herramienta llama a los mismos procedimientos del servidor que llama el panel de Reach, a través de un caller en proceso. Las comprobaciones de acceso a la ubicación, los límites del plan y las comprobaciones de conexión con Google se ejecutan exactamente igual que para un propietario con sesión iniciada; la capa MCP no tiene vía para saltárselas.
Una sesión de ejemplo, llamada a llamada
Sesión ilustrativa: el propietario de una clínica dental en Claude
El propietario escribe: «Busca las reseñas del último mes que no haya respondido y ayúdame a responder a las quejas.»
- El asistente lee primero la cuenta. El resultado enumera las ubicaciones de la clínica con sus ids, si cada conexión de Google está activa, el plan y los créditos restantes.
- Lee las reseñas de la ubicación, filtradas a las no respondidas de los últimos 30 días. Cada reseña vuelve con su valoración, texto, fecha y estado de respuesta.
- Para una reseña de 2 estrellas sobre el tiempo de espera, pide a Reach borradores de respuesta. Redactar usa créditos y no cambia nada público. El asistente muestra las opciones y el propietario edita una.
- Antes de publicar, el asistente muestra el texto exacto y pide un sí. El propietario acepta, la respuesta llega a Google y el resultado devuelve la respuesta a la que sustituyó, si la había.
- El asistente vuelve a leer las reseñas para confirmar que la respuesta aparece y luego informa de lo que ha cambiado.
Cinco llamadas de herramienta, un cambio público, una aprobación explícita. El borrador llega a Google solo en la redacción que aprobó el propietario.
Cómo llega un cambio a Google
Un cambio en una ficha pública pasa dos veces por el propietario. Primero, las herramientas de escritura llevan destructiveHint, que permite al cliente mostrar su propio aviso de aprobación. Segundo, cada descripción de herramienta le dice al modelo que muestre el cambio exacto y que obtenga un sí explícito en la conversación.
Una edición de perfil requiere dos llamadas. La primera, con preview: true (el valor predeterminado), devuelve el antes y el después de cada campo modificado, cualquier campo que sería rechazado con la corrección que necesita, y una huella basada en el perfil que leyó. La segunda llamada solo escribe si lleva esa huella y el perfil no ha cambiado desde entonces. Si alguien editó la ficha mientras tanto, en el panel o mediante una sincronización de Google, se rechaza la escritura y el asistente debe obtener una vista previa nuevamente.
La propia API de Google aplica los campos que se le envían bajo una máscara de actualización (locations.patch). No puede saber si una persona vio el cambio. La vista previa y la huella ponen esa comprobación delante, para que un modelo no pueda aplicar una edición obsoleta o no vista, ni siquiera en un reintento.
Las publicaciones y las respuestas a reseñas no tienen paso de vista previa porque el cambio que el propietario aprueba es el texto exacto que se publica. Una respuesta publicada sustituye a cualquier respuesta anterior (reviews.updateReply) y la descripción lo dice, para que el modelo pueda informar al propietario antes de que acepte.
Reach optó por la confirmación en la conversación en lugar de una cola de propuesta y aprobación dentro de Reach. El propietario ya está en el chat; una segunda bandeja de entrada añade un paso fácil de ignorar, y la especificación MCP ya espera a una persona que pueda denegar una llamada de herramienta (security considerations).
Protecciones que no dependen del modelo
La especificación dice que los clientes deben tratar las anotaciones de herramientas como no fiables a menos que vengan de un servidor de confianza (tool annotations), y un modelo puede ignorar una descripción. Así que el servidor aplica sus propias reglas:
- Un presupuesto de escritura en Google. Cada negocio puede hacer hasta 20 cambios en Google por hora a través de asistentes. Un modelo atrapado en un bucle llega al límite y se le dice cuánto debe esperar, en lugar de reescribir un perfil una y otra vez.
- Seguridad ante reintentos. Cada cambio acepta una clave de idempotencia. Una repetición con la misma clave devuelve el primer resultado en lugar de escribir de nuevo; sin clave, una llamada idéntica en una ventana corta cuenta como el mismo cambio.
- Comprobaciones de ubicación en cada llamada. El id de ubicación que envía un modelo se comprueba cada vez contra el acceso de Google de la cuenta, con la misma comprobación que usa la interfaz de Reach.
- Números de teléfono enmascarados. Los clientes potenciales vuelven con el número de teléfono enmascarado a menos que la cuenta tenga un plan de pago.
- Revocación que el servidor aplica. Un propietario puede desconectar un asistente desde la pantalla de AI Connectors en Reach, y el servidor rechaza el token de ese cliente a partir de entonces.
Decirle al modelo lo que no puede ver
Un asistente que recibe una lista vacía le dice al propietario «no tienes reseñas». A menudo la verdad es que los datos existen pero están ocultos: la cuenta no tiene conexión con Google, el plan no incluye una función o Google no ha terminado la primera sincronización. Por eso cada resultado incluye una lista de funciones con su estado, para que el modelo no describa llamadas o anuncios como cosas que Reach puede hacer hoy.
El resultado de la cuenta hace lo mismo con las funciones. Cada una está marcada como disponible o aún no creada, para que el modelo no describa llamadas o anuncios como cosas que Reach puede hacer hoy. Cuando un propietario quiere algo de lo que Reach carece, el asistente puede enviar la solicitud al equipo de Reach con las palabras del propietario, después de mostrárselas.
Cada respuesta también devuelve la versión del esquema de la herramienta. Los clientes guardan en caché los esquemas de las herramientas y pueden fallar silenciosamente cuando uno cambia, así que un cambio importante aparece en la respuesta y en los registros de Reach en lugar de solo en la tasa de errores de un cliente.
Inicio de sesión: OAuth 2.1, sin claves de API
El servidor es un recurso protegido OAuth 2.1, como describe la especificación de autorización de MCP (authorization). Publica metadatos de recurso protegido (RFC 9728), para que un cliente encuentre el servidor de autorización por sí solo, se registre y abra un inicio de sesión en el navegador. El propietario inicia sesión con su cuenta de Reach; no hay ninguna clave que pegar.
El servidor comprueba que cada token se emitió para este recurso y no para otro servicio en el mismo servidor de autorización, la defensa del diputado confundido para la que existen los indicadores de recurso (RFC 8707). La conexión de Google nunca llega al asistente: Reach la mantiene, y el asistente solo tiene un token de Reach.
Por eso el propietario tampoco necesita acceso a la API de Google. Google concede las APIs de Business Profile por proyecto tras una solicitud de acceso (prerequisites), que la mayoría de las pequeñas empresas nunca presenta.
Lo que no puede hacer
- No puede cambiar la categoría principal ni la dirección. Esas quedan en manos del propietario en las propias herramientas de Google.
- No puede eliminar una publicación ni quitar una respuesta a una reseña. Una respuesta publicada puede sustituirse, pero no eliminarse.
- Sin una cuenta de Google Business Profile conectada solo puede leer la ficha pública. Una ubicación añadida desde su ficha pública recibe esa instantánea y un enlace para conectarla.
- No puede hacer más de 20 cambios en Google por negocio y por hora a través de asistentes.
- La posición en la búsqueda solo cubre las palabras clave rastreadas. Una palabra clave nueva no tiene posición hasta que se ejecuta su primera comprobación.
Conéctalo en Claude, ChatGPT o Cursor
URL del servidor
https://reach.locus-intelligence.com/api/mcpAcerca del servidor MCP de Google Business Profile de Reach
Cada cliente añade servidores remotos de forma diferente, así que los pasos están en una página por cliente: Claude, ChatGPT, Claude Code, Cursor y VS Code. Los proveedores documentan lo mismo: Anthropic sobre conectores personalizados, OpenAI sobre cómo conectarse desde ChatGPT y Cursor sobre servidores MCP.
Preguntas frecuentes
- ¿Necesito acceso a la API de Google Business Profile para usar este servidor MCP?
- No. Reach mantiene la conexión con Google, y el asistente inicia sesión en Reach con OAuth. Las API de Google necesitan un proyecto aprobado de Google Cloud (requisitos previos), lo cual esto evita.
- ¿Con qué asistentes de AI funciona?
- Cualquier cliente que admita servidores MCP remotos con inicio de sesión OAuth, incluidos Claude, ChatGPT, Claude Code, Cursor, VS Code, Codex, Windsurf y Cline.
- ¿Puede el asistente cambiar mi ficha sin preguntar?
- Los cambios en Google pasan por el aviso de aprobación del cliente y un sí explícito en la conversación, y las ediciones de perfil necesitan una vista previa nueva. El servidor no puede ver la conversación, así que las protecciones que aplica por sí mismo son el rechazo por vista previa obsoleta, el límite horario de escritura en Google y la seguridad de reintentos.
- ¿Tiene algún coste?
- Leer no cuesta nada. Redactar una respuesta a una reseña usa créditos de Reach, y algunas funciones dependen del plan. El plan gratuito cubre una ubicación.
- ¿Qué pasa si se rompe la conexión con Google?
- El resultado de la cuenta muestra el estado de conexión de cada ubicación. Si no está activa, el asistente le dice al propietario que reconecte Google en Reach y deja de trabajar en esa ubicación.
Conecta un asistente a tu propio perfil
Empieza con una pregunta de solo lectura, como qué reseñas están sin responder, luego aprueba un pequeño cambio y léelo de nuevo. La página de configuración guía a través de cada cliente.