Agencies that manage Google Business Profiles do a lot of repetitive work: replying to reviews, scheduling posts, fixing hours before holidays, pulling monthly numbers for clients. It is exactly the kind of work you would like an AI agent to draft. It is also work where one bad reply or a wrong holiday hour goes live in front of customers.
We run an SEO agency, and this is the pattern we ended up with for our own clients: the agent can do almost everything, but it cannot publish. A person approves every reply, post and profile edit before Google sees it. We open-sourced the tool we built around that idea, OpenGMB. This post walks through how the setup works and why the permission model matters more than the prompts.
The shape of the setup
OpenGMB is a Google Business Profile manager (reviews, review replies, posts, profile edits, performance, reports and Maps rank tracking) that also runs an MCP server. Every action in the app is also an MCP tool — around 250 of them — so Claude, Cursor or any MCP client can call the same actions a person would click.
All surfaces go through one executor. The web app, the MCP server, the REST API and the background worker run the same actions, so permissions, guardrail rules and the audit log apply the same way no matter who or what makes the change.
Step 1: give the agent a token that cannot publish
In the app you create a token under Settings → API tokens, either read-only or read-and-write. The key part: a human-in-the-loop token can draft and submit, but it cannot approve or publish.
Then add the server to your client. For Claude Code:
claude mcp add --transport http opengmb https://your-mcp-host/mcp \
--header "Authorization: Bearer sgmb_your_token"
Step 2: ask for work in plain words
Prompts like these work well because the result lands in a queue, not on Google:
Draft replies for this week's 1- and 2-star reviews at every location, and put them in the approval queue.
Which locations lost the most calls last month compared with the month before?
Schedule a holiday hours post for all dental clients for Friday, and send it for approval.
The second one is read-only and just answers. The first and third create drafts.
Step 3: rules run before a person even sees the draft
Every reply, post and edit is checked by guardrail rules first: links, emails, phone numbers, offers, bad hours and banned words. Blocks cannot be overridden; warnings must be acknowledged. For healthcare and law-firm clients there are extra rule packs (HIPAA-style checks for names, clinical terms and dates, and legal ethics).
Then the approval rules apply:
- Posts and profile edits always need a person's approval.
- Replies to 1 to 3 star reviews always need a person and are never published automatically.
- Replies to 4 and 5 star reviews need a person, unless the owner turns on auto-approve for that client.
And the rules run again just before anything is sent to Google, so a draft that was fine on Monday but edited on Tuesday is checked again.
Step 4: keep a record
Every change is written to an append-only, hash-chained audit log. When a client asks "who changed our Sunday hours?", the answer is there, whether it was a teammate, a script or the agent.
Why this beats "just be careful with the prompt"
Prompt instructions like "never mention prices" or "don't promise results" are suggestions to a model. A token that cannot publish, rules that block before sending, and an approval queue are guarantees. For anything customer-facing — and especially for clinics and law firms — you want the guarantees, and the prompts become a way to make the drafts better rather than the only safety net.
Trying it
The community edition is MIT licensed and self-hosted with Docker Compose. You bring your own keys, and it talks to Google only through the official Business Profile API, so going live needs Google's approval of Business Profile API access for your own Google Cloud project. Until then it starts in a mock mode with sample locations, so you can click through everything (and point an MCP client at it) without any Google keys.
The full MCP setup, including every tool with its inputs and the permission it needs, is in the OpenGMB MCP docs. The code is on GitHub at synectus/OpenGMB.
If you are building something similar for another API, the pattern carries over: give the agent draft-only credentials, put deterministic rules between the draft and the real system, and make a human approval the only path to production.
Written by the OpenGMB team at Synectus.
Top comments (0)