An agent that can write a holiday post for one café can also change the phone number on forty of them in a single prompt. Once you connect Claude or ChatGPT to the listings of a business with several locations, the interesting question stops being whether it can make the edit. It becomes which edits should wait for a person.
I work at Pluspoint, and we run an MCP server that lets assistants read and change local business data: profiles, reviews, posts, review requests. The rules below apply whether you use our server, build your own on the Google Business Profile API, or connect an agent to another listings tool.
TL;DR
- Gate identity fields. Name, address, phone, primary category and website should wait for a human, because a mistake there spreads to every app that copies your data.
- Let routine fields through. Regular hours, descriptions, services and links are safe to automate if every change is logged.
- Draft by default. Posts the agent writes should land in a calendar, not go live.
- Keep review replies human for now. They're public, they stay up for years, and tone mistakes there cost the most.
- Scope the connection like a staff login. One account, a named client, short-lived tokens, one-click revoke.
- Put most of the effort into reads. "Which locations slipped this month, and why?" is where agents earn their keep.
Which profile fields are risky to automate?
The fields that identify a business are the risky ones. A wrong phone number doesn't stay on the profile you edited. Directories, map apps and AI assistants copy the source record: in our audit of ChatGPT's business cards, 45 of 56 carried a Yelp URL tagged as an OpenAI data feed rather than anything the business published itself. Fix the error later and you're chasing it across every copy.
Edits to these fields are also the ones Google is most likely to hold for review or re-verification, which for a chain means a location that looks unreliable at exactly the wrong moment. The other two belong in the same group for simpler reasons: a new primary category changes which searches a location appears in, and a typo in the website breaks every "Website" button at once.
Regular hours, descriptions, services and links are different. A wrong value there gets noticed quickly and takes seconds to revert, so an agent can change them as long as every edit is logged. In our server the five identity fields wait in a confirmation queue before anything reaches Google, and holiday hours are set in the app rather than through the agent.
Should the agent publish posts directly?
No. Have it draft. A prompt like "write a post about the autumn menu for every location and schedule it for Friday" should produce scheduled drafts that someone can read, edit or cancel before they go out. Placeholders such as [city] let one prompt produce forty posts that each name the right place, which is also how one wrong placeholder ends up in forty posts.
The review step costs little. The agent did the writing and the fan-out across networks, and a person spends a minute scanning the calendar.
Why keep review replies out of the agent's hands?
A reply sits under a customer's review for years, and future customers judge the business by it. A cheerful template under a complaint about a missed allergy order is a screenshot waiting to travel.
So our server reads every review, with rating, source and themes, and has no tool to publish a reply. Replies go out from the Pluspoint app, where AI drafts them and a person sends them. I'd recommend the same split to anyone building this: let the agent find the reviews that need attention, and let a person answer them.
How should the connection be scoped?
Treat it like a login you'd give a new hire:
- One account per connection. An agency connects each client separately. The sign-in screen asks which account to connect and names the app asking for access.
- Short-lived tokens. Ours expire after an hour, and revoking a connection in settings cuts it off within that hour.
- No secrets in prompts. With OAuth the assistant never sees a password or an API key.
One limit to plan around: access is per account, not per location. A franchise that wants each franchisee to run an agent on their own store can't scope it that finely yet, so the connection belongs at head office or agency level.
Where agents actually help
Most of the value we see comes from reads. An agent with access to every location's reviews, survey answers and posts can answer in seconds what used to take a spreadsheet afternoon. This question comes back as a short table a manager can act on:
Which three locations got the most 1- and 2-star reviews this month,
and what do those customers mention?
Two more that work well:
Which locations have survey answers that mention wait times
in the last 30 days?
Which scheduled posts failed to publish this week, and on which networks?
The answers point a person at the three locations that need attention instead of the forty that don't. That's worth having even if the agent never writes anything.
Trying it
If you'd rather build it yourself, Google has to approve your project for Business Profile API access before you can make calls. Budget time for that request.
To try the setup described here, Pluspoint's MCP server is at https://app.pluspoint.io/mcp. In Claude, add it as a custom connector under Settings → Connectors; in ChatGPT, Gemini or Cursor, add it wherever the client accepts a custom MCP server, then sign in and approve. It exposes 26 tools, 15 that read and 11 that write, and needs a Pluspoint account with the locations already connected.
Whichever route you take, the rules fit on a sticky note: confirm identity fields, draft posts, keep replies human, scope the token, and let the agent read everything.
Top comments (0)