A Reach by Locus executa um servidor MCP remoto do Google Business Profile. Um assistente como Claude, ChatGPT ou Cursor inicia sessão com OAuth, lê o perfil, avaliações, classificações e leads de uma empresa, e faz uma alteração pública apenas após o proprietário a aprovar no chat. Este post explica como é construído.
A configuração do proprietário está na página MCP e nos seus guias por cliente. Este post é para programadores e construtores de AI: o que o servidor expõe, como uma escrita chega ao Google e as decisões por detrás disso. Segue a especificação Model Context Protocol.
O que o servidor expõe
O servidor usa o transporte HTTP streamable da especificação MCP (transports), por isso não há nada para instalar ou executar localmente. As suas ferramentas dividem-se em três classes, e cada ferramenta inclui as anotações da especificação, para que um cliente saiba antes de chamar se uma ferramenta apenas lê, altera dados próprios da Reach ou altera uma listagem pública do Google (tool annotations).
| Classe | O que abrange | Público no Google? |
|---|---|---|
| Ler | O que abrangeA conta e as suas localizações, conteúdo do perfil, avaliações com estado de resposta, posts e multimédia, análises de desempenho, classificações de palavras-chave rastreadas e concorrentes próximos, leads e pedidos de reserva, e uma lista do que falta a cada perfil | Público no Google?Não |
| Alteração dentro da Reach | O que abrangeRascunhos de respostas a avaliações, iniciar ou parar o rastreio de palavras-chave, marcar uma recomendação como concluída ou ignorada, e enviar um pedido de funcionalidade à equipa da Reach | Público no Google?Não |
| Escrita no Google | O que abrangeEdições de campos do perfil e área de serviço, carregamento e eliminação de fotos e vídeos, publicação de posts e publicação de respostas a avaliações | Público no Google?Sim |
O servidor também oferece prompts MCP, as instruções iniciais reutilizáveis da especificação (prompts): um otimiza um perfil uma alteração confirmada de cada vez, um analisa a visibilidade na pesquisa e um trabalha através de avaliações sem resposta. Um cliente mostra-os como pedidos prontos a usar.
Cada ferramenta chama os mesmos procedimentos do servidor que o painel da Reach chama, através de um chamador em processo. As verificações de acesso à localização, limites do plano e verificações de ligação ao Google são, portanto, executadas exatamente como para um proprietário com sessão iniciada; a camada MCP não tem caminho alternativo para as contornar.
Uma sessão de exemplo, chamada a chamada
Sessão ilustrativa: um proprietário de clínica dentária no Claude
O proprietário escreve: «Encontre as avaliações do mês passado a que ainda não respondi e ajude-me a responder às reclamações.»
- O assistente lê primeiro a conta. O resultado lista as localizações da clínica com os seus IDs, se cada ligação Google está ativa, o plano e os créditos restantes.
- Lê as avaliações da localização, filtradas para as não respondidas dos últimos 30 dias. Cada avaliação volta com a sua classificação, texto, data e estado de resposta.
- Para uma avaliação de 2 estrelas sobre o tempo de espera, pede ao Reach sugestões de resposta. Esboçar usa créditos e não altera nada público. O assistente mostra as opções e o proprietário edita uma.
- Antes de publicar, o assistente mostra o texto exato e pede uma confirmação. O proprietário concorda, a resposta vai para o Google e o resultado devolve a resposta que substituiu, se existiu alguma.
- O assistente lê as avaliações novamente para confirmar que a resposta aparece e depois relata o que alterou.
Cinco chamadas de ferramenta, uma alteração pública, uma aprovação explícita. O esboço só chega ao Google na redação que o proprietário aprovou.
Como uma alteração chega ao Google
Uma alteração a uma listagem pública passa pelo proprietário duas vezes. Primeiro, as ferramentas de escrita trazem destructiveHint, que permite ao cliente mostrar o seu próprio pedido de aprovação. Segundo, a descrição de cada ferramenta diz ao modelo para mostrar a alteração exata e obter um sim explícito na conversa. Edições de perfil e alterações de multimédia vão mais longe e, por predefinição, usam uma pré-visualização que não escreve nada.
Uma edição de perfil requer duas chamadas. A primeira, com preview: true (a predefinição), devolve o antes e depois de cada campo alterado, qualquer campo que seria rejeitado com a correção necessária e uma impressão digital basedOn do perfil que leu. A segunda chamada só escreve se trouxer essa impressão digital e o perfil não tiver mudado entretanto. Se alguém editou a listagem entretanto, no painel ou através de uma sincronização Google, a escrita é recusada e o assistente tem de pré-visualizar novamente.
A própria API do Google aplica os campos que lhe são enviados sob uma máscara de atualização (locations.patch). Não consegue saber se uma pessoa viu a alteração. A pré-visualização e a impressão digital colocam essa verificação à sua frente, para que um modelo não possa aplicar uma edição desatualizada ou não vista, mesmo numa repetição.
Publicações e respostas a avaliações não têm passo de pré-visualização, porque o texto que o proprietário aprova é a própria alteração. As suas descrições exigem que o assistente mostre primeiro a publicação ou resposta exata. Uma resposta publicada substitui qualquer resposta anterior e nenhuma ferramenta a remove (reviews.updateReply), e a descrição diz isso, para que o modelo possa informar o proprietário antes de concordar.
A Reach escolheu a confirmação na conversa em vez de uma fila de proposta e aprovação dentro da Reach. O proprietário já está no chat, uma segunda caixa de entrada adiciona um passo fácil de ignorar, e a especificação MCP já espera um humano que possa negar uma chamada de ferramenta (considerações de segurança).
Proteções que não dependem do modelo
A especificação diz que os clientes devem tratar as anotações de ferramentas como não confiáveis, a menos que venham de um servidor confiável (anotações de ferramentas), e um modelo pode ignorar uma descrição. Por isso, o servidor impõe as suas próprias regras:
- Um orçamento de escrita no Google. Cada empresa pode fazer até 20 alterações no Google por hora através de assistentes. Um modelo preso num ciclo atinge o limite e é informado de quanto tempo esperar, em vez de reescrever um perfil repetidamente.
- Segurança de repetição. Cada alteração aceita uma chave de idempotência. Uma repetição com a mesma chave devolve o primeiro resultado em vez de escrever novamente; sem chave, uma chamada idêntica dentro de uma janela curta conta como a mesma alteração.
- Verificações de localização em cada chamada. O ID de localização que um modelo envia é verificado em relação ao acesso Google ativo do proprietário de cada vez, com a mesma verificação que o painel usa. O servidor não mantém nenhuma sessão para um modelo reutilizar.
- Números de telefone mascarados. Leads e pedidos de reserva voltam com números de telefone mascarados para os últimos quatro dígitos, também dentro de notas. Os e-mails passam, porque o proprietário precisa deles para responder a um lead.
- Revogação que o servidor impõe. Um proprietário pode desligar um assistente do ecrã de Conectores de AI na Reach, e o servidor recusa o token desse cliente a partir desse momento.
Dizer ao modelo o que não pode ver
Um assistente que recebe uma lista vazia diz ao proprietário «não tem avaliações». Muitas vezes a verdade é que existem dados mas estão ocultos: a localização foi adicionada a partir da sua listagem pública e não tem ligação Google, o plano não inclui uma funcionalidade, ou o Google ainda não terminou a primeira sincronização. Os resultados de leitura trazem, por isso, uma lista de limitações que nomeia o motivo e a ligação que o resolve. Uma lista vazia significa que nada foi ocultado.
O resultado da conta faz o mesmo para as funcionalidades. Cada uma é marcada como disponível ou ainda não implementada, para que o modelo não descreva chamadas ou anúncios como coisas que a Reach pode fazer hoje. Quando um proprietário quer algo que a Reach não tem, o assistente pode enviar o pedido à equipa Reach nas palavras do proprietário, depois de lhe mostrar a redação.
Cada resposta também devolve a versão do esquema da ferramenta. Os clientes armazenam em cache os esquemas das ferramentas e podem falhar silenciosamente quando um muda, por isso uma alteração disruptiva aparece na resposta e nos registos da Reach em vez de apenas na taxa de erro de um cliente.
Início de sessão: OAuth 2.1, sem chaves de API
O servidor é um recurso protegido OAuth 2.1, conforme descrito na especificação de autorização MCP (autorização). Publica metadados de recurso protegido (RFC 9728), para que um cliente encontre o servidor de autorização por si próprio, se registe e abra um início de sessão no navegador. O proprietário inicia sessão com a sua conta Reach; não há nenhuma chave para colar.
O servidor verifica que cada token foi emitido para este recurso e não para outro serviço no mesmo servidor de autorização, a defesa contra o deputado confuso para a qual existem os indicadores de recurso (RFC 8707). A ligação Google nunca chega ao assistente: a Reach detém-na, e o assistente detém apenas um token Reach.
É também por isso que um proprietário não precisa de acesso à API do Google. O Google concede as APIs do Business Profile por projeto após um pedido de acesso (pré-requisitos), que a maioria das pequenas empresas nunca apresenta.
O que não pode fazer
- Não pode alterar a categoria principal ou a morada. Essas ficam com o proprietário nas próprias ferramentas do Google.
- Não pode eliminar uma publicação ou remover uma resposta a uma avaliação. Uma resposta publicada pode ser substituída, não removida.
- Sem um Google Business Profile ligado, só pode ler a listagem pública. Uma localização adicionada a partir da sua listagem pública obtém essa imagem e uma ligação para ligar.
- Não pode fazer mais de 20 alterações no Google por empresa por hora através de assistentes.
- A classificação de pesquisa cobre apenas palavras-chave monitorizadas. Uma nova palavra-chave não tem classificação até à sua primeira verificação.
Ligar no Claude, ChatGPT ou Cursor
URL do servidor
https://reach.locus-intelligence.com/api/mcpSobre o servidor MCP do Google Business Profile do Reach
Cada cliente adiciona servidores remotos de forma diferente, por isso os passos estão numa página por cliente: Claude, ChatGPT, Claude Code, Cursor e VS Code. Os fornecedores documentam o mesmo terreno: Anthropic sobre conectores personalizados, OpenAI sobre ligar a partir do ChatGPT e Cursor sobre servidores MCP.
Perguntas frequentes
- Preciso de acesso à API do Google Business Profile para usar este servidor MCP?
- Não. A Reach detém a ligação Google, e o assistente inicia sessão na Reach com OAuth. As APIs do Google precisam de um projeto Google Cloud aprovado (pré-requisitos), o que isto evita.
- Com que assistentes de AI funciona?
- Qualquer cliente que suporte servidores MCP remotos com início de sessão OAuth, incluindo Claude, ChatGPT, Claude Code, Cursor, VS Code, Codex, Windsurf e Cline.
- O assistente pode alterar a minha listagem sem pedir?
- As alterações ao Google passam pelo pedido de aprovação do cliente e por um sim explícito na conversa, e as edições de perfil precisam de uma pré-visualização recente. O servidor não pode ver a conversa, por isso as proteções que impõe por si próprio são a recusa de pré-visualização desatualizada, o limite horário de escrita no Google e a segurança de repetição.
- Tem algum custo?
- Ler não custa nada. Esboçar uma resposta a uma avaliação usa créditos Reach, e algumas funcionalidades dependem do plano. O plano Grátis cobre uma localização.
- O que acontece se a ligação Google se quebrar?
- O resultado da conta mostra o estado de ligação de cada localização. Se não estiver ativa, o assistente diz ao proprietário para religar o Google na Reach e para de trabalhar nessa localização.
Ligar um assistente ao seu próprio perfil
Comece com uma pergunta só de leitura, por exemplo, quais avaliações estão por responder, depois aprove uma pequena alteração e leia-a novamente. A página de configuração percorre cada cliente.