Reach by Locus runs a remote Google Business Profile MCP server. An assistant such as Claude, ChatGPT or Cursor signs in with OAuth, reads a business’s profile, reviews, rankings and leads, and makes a public change only after the owner approves it in the chat. This post explains how it is built.
Owner setup lives on the MCP page and its per-client guides. This post is for developers and AI builders: what the server exposes, how a write reaches Google, and the decisions behind it. It follows the Model Context Protocol specification.
What the server exposes
The server uses the streamable HTTP transport from the MCP specification (transports), so there is nothing to install or run locally. Its tools fall into three classes, and every tool carries the specification’s annotations, so a client knows before calling whether a tool only reads, changes Reach’s own data or changes a public Google listing (tool annotations).
| Class | What it covers | Public on Google? |
|---|---|---|
| Read | What it coversThe account and its locations, profile content, reviews with reply status, posts and media, performance analytics, tracked-keyword rankings and nearby competitors, leads and booking requests, and a list of what each profile is missing | Public on Google?No |
| Change inside Reach | What it coversReview-reply drafts, starting or stopping keyword tracking, marking a recommendation done or dismissed, and sending a feature request to the Reach team | Public on Google?No |
| Google write | What it coversProfile field and service-area edits, photo and video uploads and deletions, publishing posts, and posting review replies | Public on Google?Yes |
The server also offers MCP prompts, the specification’s reusable starting instructions (prompts): one optimises a profile one confirmed change at a time, one reviews search visibility, and one works through unanswered reviews. A client shows them as ready-made requests.
Each tool calls the same server procedures the Reach dashboard calls, through an in-process caller. Location access checks, plan limits and Google connection checks therefore run exactly as they do for a signed-in owner; the MCP layer has no path around them.
An example session, call by call
Illustrative session: a dental clinic owner in Claude
The owner types: “Find last month’s reviews I haven’t answered and help me reply to the complaints.”
- The assistant reads the account first. The result lists the clinic’s locations with their ids, whether each Google connection is active, the plan and the remaining credits.
- It reads the location’s reviews, filtered to unanswered ones from the last 30 days. Each review comes back with its rating, text, date and reply status.
- For a 2-star review about waiting time, it asks Reach for reply drafts. Drafting uses credits and changes nothing public. The assistant shows the options, and the owner edits one.
- Before posting, the assistant shows the exact text and asks for a yes. The owner agrees, the reply goes to Google, and the result returns the reply it replaced, if there was one.
- The assistant reads the reviews again to confirm the reply shows, then reports what it changed.
Five tool calls, one public change, one explicit approval. The draft reaches Google only in the wording the owner approved.
How a change reaches Google
A change to a public listing passes the owner twice. First, write tools carry destructiveHint, which lets the client show its own approval prompt. Second, each tool description tells the model to show the exact change and get an explicit yes in the conversation. Profile edits and media changes go further and default to a preview that writes nothing.
A profile edit takes two calls. The first, with preview: true (the default), returns each changed field’s before and after, any field that would be rejected with the fix it needs, and a basedOn fingerprint of the profile it read. The second call writes only if it carries that fingerprint and the profile has not changed since. If someone edited the listing in the meantime, in the dashboard or through a Google sync, the write is refused and the assistant must preview again.
Google’s own API applies the fields it is sent under an update mask (locations.patch). It cannot know whether a person saw the change. The preview and fingerprint put that check in front of it, so a model cannot apply a stale or unseen edit, even on a retry.
Posts and review replies have no preview step, because the text the owner approves is the change itself. Their descriptions require the assistant to show the exact post or reply first. A posted reply replaces any earlier reply and no tool removes it (reviews.updateReply), and the description says so, so the model can tell the owner before they agree.
Reach chose confirmation in the conversation over a propose-and-approve queue inside Reach. The owner is already in the chat, a second inbox adds a step that is easy to ignore, and the MCP specification already expects a human who can deny a tool call (security considerations).
Guards that do not depend on the model
The specification says clients must treat tool annotations as untrusted unless they come from a trusted server (tool annotations), and a model can ignore a description. So the server enforces its own rules:
- A Google write budget. Each business can make up to 20 Google changes per hour through assistants. A model stuck in a loop hits the limit and is told how long to wait, instead of rewriting a profile again and again.
- Retry safety. Every change accepts an idempotency key. A repeat with the same key returns the first result instead of writing again; without a key, an identical call within a short window counts as the same change.
- Location checks on every call. The location id a model sends is checked against the owner’s live Google access each time, with the same check the dashboard uses. The server keeps no session for a model to reuse.
- Masked phone numbers. Leads and booking requests come back with phone numbers masked to the last four digits, inside notes too. Emails pass through, because an owner needs them to answer a lead.
- Revocation the server enforces. An owner can disconnect an assistant from the AI Connectors screen in Reach, and the server refuses that client’s token from then on.
Telling the model what it cannot see
An assistant that receives an empty list tells the owner “you have no reviews”. Often the truth is that data exists but is hidden: the location was added from its public listing and has no Google connection, the plan does not include a feature, or Google has not finished the first sync. Read results therefore carry a limitations list that names the reason and the link that fixes it. An empty list means nothing was hidden.
The account result does the same for features. Each one is marked as available or not built yet, so the model does not describe calls or ads as things Reach can do today. When an owner wants something Reach lacks, the assistant can send the request to the Reach team in the owner’s words, after showing them the wording.
Every response also returns the tool’s schema version. Clients cache tool schemas and can fail quietly when one changes, so a breaking change shows up in the response and in Reach’s logs rather than only in a client’s error rate.
Sign-in: OAuth 2.1, no API keys
The server is an OAuth 2.1 protected resource, as the MCP authorization specification describes (authorization). It publishes protected resource metadata (RFC 9728), so a client finds the authorization server on its own, registers itself and opens a browser sign-in. The owner signs in with their Reach account; there is no key to paste.
The server checks that each token was issued for this resource and not for another service on the same authorization server, the confused-deputy defence that resource indicators exist for (RFC 8707). The Google connection never reaches the assistant: Reach holds it, and the assistant only ever holds a Reach token.
That is also why an owner does not need Google API access. Google grants the Business Profile APIs per project after an access request (prerequisites), which most small businesses never file.
What it cannot do
- It cannot change the primary category or the address. Those stay with the owner in Google’s own tools.
- It cannot delete a post or remove a review reply. A posted reply can be replaced, not removed.
- Without a connected Google Business Profile it can only read the public listing. A location added from its public listing gets that snapshot and a link to connect.
- It cannot make more than 20 Google changes per business per hour through assistants.
- Search rank covers tracked keywords only. A new keyword has no rank until its first check runs.
Connect it in Claude, ChatGPT or Cursor
Server URL
https://reach.locus-intelligence.com/api/mcpAbout the Reach Google Business Profile MCP server
Each client adds remote servers differently, so the steps live on one page per client: Claude, ChatGPT, Claude Code, Cursor and VS Code. The vendors document the same ground: Anthropic on custom connectors, OpenAI on connecting from ChatGPT and Cursor on MCP servers.
Frequently asked questions
- Do I need Google Business Profile API access to use this MCP server?
- No. Reach holds the Google connection, and the assistant signs in to Reach with OAuth. Google’s APIs need an approved Google Cloud project (prerequisites), which this avoids.
- Which AI assistants work with it?
- Any client that supports remote MCP servers with OAuth sign-in, including Claude, ChatGPT, Claude Code, Cursor, VS Code, Codex, Windsurf and Cline.
- Can the assistant change my listing without asking?
- Changes to Google pass through the client’s approval prompt and an explicit yes in the conversation, and profile edits need a fresh preview. The server cannot see the conversation, so the guards it enforces itself are the stale-preview refusal, the hourly Google write limit and retry safety.
- Does it cost anything?
- Reading costs nothing. Drafting a review reply uses Reach credits, and some features depend on the plan. The Free plan covers one location.
- What happens if the Google connection breaks?
- The account result shows each location’s connection state. If it is not active, the assistant tells the owner to reconnect Google in Reach and stops working on that location.
Connect an assistant to your own profile
Start with a read-only question, such as which reviews are unanswered, then approve one small change and read it back. The setup page walks through each client.