Connect Google Reviews to Claude with MCP

DEV Community

Ask your Google reviews from Claude: a hosted MCP server walkthrough

If you manage Google reviews for more than one location, the day usually starts the same way: open the Business Profile for each location, scroll, find what's new, find what's still unanswered. I wanted to ask one question instead: "which of my locations has the most unanswered reviews, and what are people complaining about?" That's what the Model Context Protocol (MCP) is good at. Here's how we wired Google reviews into Claude, Claude Code and Cursor with a hosted MCP server, and the design decisions that mattered. The setup in one command For Claude Code: claude mcp add --transport http reputemap https://api.reputemap.com/mcp \
- -header "Authorization: Bearer rmk_YOUR_KEY"
Then: claude "which of my locations has the most unanswered reviews?"
For Cursor, add this to ~/.cursor/mcp.json: {
"mcpServers": {
"reputemap": {
"url": "https://api.reputemap.com/mcp",
"headers": { "Authorization": "Bearer rmk_YOUR_KEY" }
}
}
}
In claude.ai or Claude Desktop you don't need a key at all: add it as a connector and sign in through OAuth. The tools The server is Streamable HTTP and exposes seven tools: Tool What it does list_locations Every location you manage, with ids list_reviews Reviews filtered by location, rating, unanswered, last N days, with the published reply get_review_stats Counts, averages, 1–5 breakdown, unanswered, per location and in total draft_reply Reply variants, saved as a draft. Never publishes publish_reply Publishes a reply you explicitly approved send_review_request Sends a real review-request email get_usage This month's API credits Three design decisions worth copying 1. Read tools run freely, write tools always ask. Every tool carries MCP annotations: the four read tools are marked read-only, while draft_reply, send_review_request and publish_reply are not. Well-behaved clients ask before running them, and in Claude you can block the write tools entirely to keep the assistant read-only. An AI that answers customers on its own is the most common complaint about review software, so the default here is "the model drafts, a person approves". 2. Writes are idempotent where it matters. A second send_review_request for the same email at the same location returns status: "already_requested". No second email goes out and no credit is spent. Models retry; customers shouldn't get two emails because of it. 3. Surface the platform's verdict, not just "success". Google now moderates owner replies before showing them. So publish_reply returns google_state: pending while Google checks, or rejected_by_google with the policy reason. list_reviews carries the same state, and a rejected reply counts as unanswered. Without that, an agent would happily report "replied!" to a reply nobody can see. Prompts that work well "Summarize what customers complained about at the Austin location in the last 30 days." "Draft replies to every unanswered 1–3 star review this week. Don't publish anything." "Compare average rating and unanswered count across all locations, worst first." "Send a review request to [email protected] for the Round Rock location." (Claude asks first.) Costs and limits Each tool call costs one API credit (get_usage is free), and every paid ReputeMap plan, including the 14-day trial, includes 1,000 credits a month, shared with the REST API. Links Setup reference with Claude Desktop, Cursor and troubleshooting: reputemap.com/docs/mcp Copy-paste configs and scripts: github.com/reputemap-com/examples Agent skills for review triage and replies: npx skills add reputemap-com/review-skills If you build something on top of it, I'd love to hear what you ask your reviews.

Powered by Readybot.io