Costruire un server MCP per Google Business Profile

Cosa espone il server

Il server utilizza il trasporto HTTP streamable della specifica MCP (trasporti), quindi non c'è nulla da installare o eseguire localmente. I suoi strumenti rientrano in tre classi, e ogni strumento porta le annotazioni della specifica, così un client sa prima di chiamare se uno strumento legge solo, modifica i dati propri di Reach o modifica un'inserzione pubblica di Google (annotazioni degli strumenti).

Il server offre anche i prompt MCP, le istruzioni iniziali riutilizzabili della specifica (prompt): uno ottimizza un profilo un cambiamento confermato alla volta, uno esamina la visibilità nella ricerca, e uno lavora attraverso le recensioni senza risposta. Un client li mostra come richieste già pronte.

Ogni strumento chiama le stesse procedure del server che chiama la dashboard di Reach, tramite un chiamante in-process. I controlli di accesso alla sede, i limiti del piano e i controlli di connessione a Google vengono quindi eseguiti esattamente come per un proprietario con accesso; il livello MCP non ha percorsi alternativi per evitarli.

Una sessione di esempio, chiamata per chiamata

Come una modifica arriva su Google

Una modifica a una scheda pubblica passa due volte dal proprietario. Primo, gli strumenti di scrittura portano destructiveHint, che permette al client di mostrare il proprio prompt di approvazione. Secondo, la descrizione di ogni strumento dice al modello di mostrare la modifica esatta e ottenere un sì esplicito nella conversazione. Le modifiche al profilo e ai media vanno oltre e prevedono per impostazione predefinita un'anteprima che non scrive nulla.

Una modifica al profilo richiede due chiamate. La prima, con preview: true (impostazione predefinita), restituisce per ogni campo modificato il prima e il dopo, eventuali campi che verrebbero rifiutati con la correzione necessaria e un fingerprint basato sul profilo letto. La seconda chiamata scrive solo se porta quel fingerprint e il profilo non è cambiato nel frattempo. Se qualcuno ha modificato la scheda nel frattempo, nella dashboard o tramite una sincronizzazione Google, la scrittura viene rifiutata e l'assistente deve fare di nuovo l'anteprima.

L'API di Google applica i campi inviati sotto una maschera di aggiornamento (locations.patch). Non può sapere se una persona ha visto la modifica. L'anteprima e il fingerprint mettono quel controllo davanti, così un modello non può applicare una modifica obsoleta o non vista, nemmeno in un nuovo tentativo.

I post e le risposte alle recensioni non hanno un passaggio di anteprima, perché il testo che il proprietario approva è la modifica stessa. Le loro descrizioni richiedono all'assistente di mostrare prima il post o la risposta esatti. Una risposta pubblicata sostituisce qualsiasi risposta precedente e nessuno strumento la rimuove (reviews.updateReply), e la descrizione lo dice, così il modello può informare il proprietario prima che accetti.

Reach ha scelto la conferma nella conversazione invece di una coda di proposta e approvazione all'interno di Reach. Il proprietario è già nella chat, una seconda casella di posta aggiunge un passaggio facile da ignorare, e la specifica MCP prevede già un umano che può negare una chiamata strumento (considerazioni sulla sicurezza).

Protezioni che non dipendono dal modello

La specifica dice che i client devono trattare le annotazioni degli strumenti come non attendibili a meno che non provengano da un server attendibile (annotazioni degli strumenti), e un modello può ignorare una descrizione. Quindi il server impone le proprie regole:

• Un budget di scrittura Google. Ogni attività può effettuare fino a 20 modifiche Google all'ora tramite assistenti. Un modello bloccato in un ciclo raggiunge il limite e gli viene detto quanto aspettare, invece di riscrivere un profilo ancora e ancora.
• Sicurezza dei tentativi. Ogni modifica accetta una chiave di idempotenza. Una ripetizione con la stessa chiave restituisce il primo risultato invece di scrivere di nuovo; senza chiave, una chiamata identica entro una breve finestra conta come la stessa modifica.
• Controlli della sede su ogni chiamata. L'ID sede inviato da un modello viene controllato rispetto all'accesso Google attivo del proprietario ogni volta, con lo stesso controllo utilizzato dalla dashboard. Il server non mantiene alcuna sessione per un modello da riutilizzare.
• Numeri di telefono mascherati. I lead e le richieste di prenotazione vengono restituiti con i numeri di telefono mascherati alle ultime quattro cifre, anche all'interno delle note. Le email passano, perché un proprietario ne ha bisogno per rispondere a un lead.
• Revoca applicata dal server. Un proprietario può disconnettere un assistente dalla schermata Connettori AI in Reach, e il server rifiuta il token di quel cliente da quel momento in poi.

Dire al modello cosa non può vedere

Un assistente che riceve una lista vuota dice al proprietario “non hai recensioni”. Spesso la verità è che i dati esistono ma sono nascosti: la sede è stata aggiunta dalla sua scheda pubblica e non ha una connessione Google, il piano non include una funzionalità, o Google non ha completato la prima sincronizzazione. I risultati di lettura quindi portano un elenco di limitazioni che indica il motivo e il link che lo risolve. Una lista vuota significa che non è stato nascosto nulla.

Il risultato dell'account fa lo stesso per le funzionalità. Ognuna è contrassegnata come disponibile o non ancora costruita, così il modello non descrive chiamate o annunci come cose che Reach può fare oggi. Quando un proprietario vuole qualcosa che Reach non ha, l'assistente può inviare la richiesta al team di Reach con le parole del proprietario, dopo avergliele mostrate.

Ogni risposta restituisce anche la versione dello schema dello strumento. I client memorizzano nella cache gli schemi degli strumenti e possono fallire silenziosamente quando uno cambia, quindi una modifica sostanziale appare nella risposta e nei log di Reach piuttosto che solo nel tasso di errore di un client.

Accesso: OAuth 2.1, nessuna chiave API

Il server è una risorsa protetta OAuth 2.1, come descritto dalla specifica di autorizzazione MCP (autorizzazione). Pubblica metadati di risorsa protetta (RFC 9728), così un client trova il server di autorizzazione da solo, si registra e apre un accesso tramite browser. Il proprietario accede con il proprio account Reach; non c'è alcuna chiave da incollare.

Il server controlla che ogni token sia stato emesso per questa risorsa e non per un altro servizio sullo stesso server di autorizzazione, la difesa contro il confuso vice per cui esistono gli indicatori di risorsa (RFC 8707). La connessione Google non arriva mai all'assistente: Reach la detiene, e l'assistente ha solo un token Reach.

Questo è anche il motivo per cui un proprietario non ha bisogno dell'accesso alle API di Google. Google concede le API di Business Profile per progetto dopo una richiesta di accesso (prerequisiti), che la maggior parte delle piccole imprese non presenta mai.

Cosa non può fare

• Non può cambiare la categoria principale o l'indirizzo. Questi rimangono al proprietario negli strumenti di Google.
• Non può eliminare un post o rimuovere una risposta a una recensione. Una risposta pubblicata può essere sostituita, non rimossa.
• Senza un Google Business Profile connesso può solo leggere la scheda pubblica. Una sede aggiunta dalla sua scheda pubblica ottiene quell'istantanea e un link per connettersi.
• Non può effettuare più di 20 modifiche Google all'ora per attività tramite assistenti.
• Il posizionamento nella ricerca copre solo le parole chiave tracciate. Una nuova parola chiave non ha posizionamento fino alla sua prima verifica.

Collegalo in Claude, ChatGPT o Cursor

URL del server

Informazioni sul server MCP Reach per Google Business Profile

Ogni client aggiunge server remoti in modo diverso, quindi i passaggi sono su una pagina per client: Claude, ChatGPT, Claude Code, Cursor e VS Code. I fornitori documentano lo stesso terreno: Anthropic sui connettori personalizzati, OpenAI sulla connessione da ChatGPT e Cursor sui server MCP.

Domande frequenti

Devo avere accesso alle API di Google Business Profile per usare questo server MCP?

No. Reach detiene la connessione Google e l'assistente accede a Reach con OAuth. Le API di Google necessitano di un progetto Google Cloud approvato (prerequisiti), cosa che questo evita.

Quali assistenti AI funzionano con esso?

Qualsiasi client che supporti server MCP remoti con accesso OAuth, inclusi Claude, ChatGPT, Claude Code, Cursor, VS Code, Codex, Windsurf e Cline.

L'assistente può modificare la mia scheda senza chiedere?

Le modifiche a Google passano attraverso il prompt di approvazione del client e un sì esplicito nella conversazione, e le modifiche al profilo necessitano di un'anteprima aggiornata. Il server non può vedere la conversazione, quindi le protezioni che impone da solo sono il rifiuto per anteprima obsoleta, il limite orario di scrittura Google e la sicurezza dei tentativi.

Costa qualcosa?

Leggere non costa nulla. Scrivere una bozza di risposta a una recensione usa crediti Reach e alcune funzionalità dipendono dal piano. Il piano gratuito copre una sede.

Cosa succede se la connessione Google si interrompe?

Il risultato dell'account mostra lo stato di connessione di ogni sede. Se non è attiva, l'assistente dice al proprietario di riconnettere Google in Reach e smette di lavorare su quella sede.

Collega un assistente al tuo profilo

Inizia con una domanda di sola lettura, ad esempio quali recensioni sono senza risposta, poi approva una piccola modifica e rileggila. La pagina di configurazione guida attraverso ogni cliente.

Configura il server MCP di Google Business Profile

Apri Connettori AI in Reach