Your agent needs to read insights, reply to reviews, and push hours updates to Google Business Profile. You go looking for the MCP server the way you would for Notion or GitHub, and the search results are a wall of third-party gateways. That is not a discovery failure. Google genuinely has not published one, which means the usual comparison collapses into a different question: not MCP or API, but whose MCP wrapper, over an API that only issues one all-or-nothing scope. Here is how to pick.
These two paths are not peers the way they are for other connectors. One is a protocol layer that anyone can build; the other is the only real capability surface underneath it. Getting that relationship right is what makes the rest of the decision tractable.
Google ships official MCP servers for some products. The Google Ads MCP server is documented on Google's developer portal, and the Google Analytics MCP server has its own guide. Business Profile has neither.
The Business Profile latest updates page tracks shipped changes through mid-2026: review reply URLs, policy violation visibility, recurring post scheduling. No MCP server. So when you evaluate "Google Business Profile MCP," you are evaluating a wrapper, and the operative question is who maintains it and whose credentials it holds.
The Business Profile APIs are not one API. They are a federated set of separately enabled Google services, plus a legacy endpoint that still carries a lot of the interesting surface.
Location data, categories, and attributes live on the Business Information API. Account and admin management lives on the Account Management API. Metrics live on the Business Profile Performance API at businessprofileperformance.googleapis.com. Verifications, Notifications, Place Actions, and Lodging each have their own service.
Reviews, local posts, and media did not migrate. They still resolve against mybusiness.googleapis.com/v4, the legacy Google My Business API. A review-reply agent is therefore a legacy-endpoint agent, whatever the rest of your integration looks like.
Neither path starts working when you enable the API. Google's prerequisites documentation requires a verified Business Profile active for 60 or more days, a website representing that business, and a submitted application for Basic API Access.
Approval is granted per Google Cloud project and reviewed within 14 days. Until then, quota reads 0, and Google's guidance is explicit: a 0 quota means you were never approved, so do not file a quota increase.
Plan the approval window into your roadmap. It is the longest lead time in the whole build, and no protocol choice shortens it.
Because both paths terminate at the same REST services, capability differences do not come from the protocol. They come from which endpoints the wrapper author bothered to implement, and from how much of Google's field-mask semantics survive the translation into an LLM-callable schema.
The table below compares Scalekit's Google Business Profile connector, which ships 56 prebuilt tools, against writing your own HTTP calls to Google directly. Any other MCP wrapper should be evaluated on the same rows.
The last two rows are the honest gap. A wrapper is a snapshot of the API at the moment it was written. Google added recurring post scheduling in April 2026 and review reply URLs in July 2026; each of those reached wrapper users later than it reached direct API callers.
Lodging and Place Actions matter less to most builders, but if you serve hotels or booking-heavy verticals, that gap is your whole product. Check the tool list against your vertical before you commit.
The Business Profile APIs are unusually hostile to naive LLM tool generation. Resource names are nested strings like accounts/{account_id}/locations/{location_id}/questions/{question_id}. Performance metrics take year, month, and day as separate integer fields rather than a date string. Categories resolve through opaque identifiers such as categories/gcid:restaurant.
Writing the schema is the hard part. Not the API call. Every one of those shapes has to be described well enough that a model fills it correctly, and every one of them is a place a hand-rolled schema produces hallucinated parameters.
This is where Google Business Profile diverges sharply from the other connectors in this series. For Notion or GitHub, the direct API path buys you auth options that MCP does not offer. Here it buys you nothing, because there is only one door.
Google's OAuth implementation guide states the requirement plainly: requests require https://www.googleapis.com/auth/business.manage, or the deprecated plus.business.manage retained for backward compatibility. That is the entire scope vocabulary.
There is no business.readonly. There is no reviews-only scope. A merchant who authorizes your read-only insights dashboard has, at the OAuth layer, also authorized deleting locations, transferring them to another account, and removing administrators.
For a human-driven SaaS product that is uncomfortable. For an autonomous agent choosing its own tool calls, it is a design problem you have to solve above OAuth, because OAuth will not solve it for you. This is the same structural challenge covered in OAuth vs API keys for AI agents — static, overly broad credentials become liabilities at scale.
An MCP endpoint does not widen or narrow that scope. The token underneath is the same business.manage grant, obtained through the same Authorization Code flow (RFC 6749) with the same merchant consent dialog.
What MCP can change is the tool surface the model sees. If the endpoint exposes only googlebusinessprofile_get_insights and googlebusinessprofile_search_keywords, the destructive operations are not in context to be selected, even though the token would permit them.
That is enforcement at the tool layer standing in for enforcement Google does not offer at the scope layer. It is the single strongest argument for routing this connector through MCP rather than raw HTTP. Understanding tool calling authentication for AI agents makes this tradeoff clearer — the protocol you choose shapes what enforcement mechanisms are available.
Both paths give you one token per merchant. An agency platform managing 400 client profiles holds 400 refresh tokens, each revocable independently from the merchant's Google Account permissions page.
Google documents no push signal for OAuth revocation. Pub/Sub notifications cover NEW_REVIEW, GOOGLE_UPDATE, and LOSS_OF_VOICE_OF_MERCHANT, not "this merchant just disconnected you." You discover revocation when a call fails.
Cross-tenant tool calling requires per-tenant authorization. There is no shortcut, and the protocol you picked does not change the arithmetic. The patterns that emerge here are the same ones explored in how tool calling auth changes when you move from single-tenant to multi-tenant.
Staging hides all of this. In staging you have one approved project, one merchant, one location, and fresh tokens. Production has 400 merchants, thousands of locations, and a quota ceiling you will find by hitting it.
Google publishes default quota limits of 300 queries per minute for Business Information, Account Management, Performance, Verifications, Lodging, Place Actions, and Notifications. Exceeding them returns 429 Too Many Requests.
300 QPM is 5 requests per second, and Google explicitly discourages spiky traffic. Its own guidance recommends pacing with a delay between calls and retrying with exponential backoff plus jitter.
Here is the trap specific to agents. The v1 Performance API dropped the v4 batch pattern that let one request span multiple listings, so a nightly metrics sweep across 400 locations is 400 sequential calls, not one. An agent that fans those out in parallel because parallelism is faster will produce exactly the burst pattern Google penalizes.
Read quota is generous. Write quota is not, and the numbers are asymmetric in a way that catches teams late.
Create Location is capped at 300 per day. SearchGoogleLocation is 300 per day. Update Location is 10,000 per day. Then the one that actually breaks agents: edits are limited to 10 per minute per Business Profile, and Google states that this ceiling cannot be increased.
An agent doing an iterative correction loop on one location, updating hours, then the phone number, then the category, will hit that ceiling inside a single reasoning cycle. Design for batched writes, not conversational ones.
googlebusinessprofile_update_listing takes an update_mask naming which fields to change. Google clears any field named in the mask that arrives blank in the request body.
Read that again in the context of an LLM composing the arguments. A model that names title,phoneNumbers,regularHours in the mask but only supplies title does not partially update the listing. It wipes the phone number and the opening hours from Google Search and Maps.
This is the highest-severity failure mode in the entire connector, and it is a schema-quality problem, not a model-quality problem. Constrain the mask, or accept that a bad tool call is a live customer-facing outage.
Reviews, posts, media, and Q&A route to the legacy v4 API. Scalekit's connector documentation flags that these tools can return 403 when the OAuth client has not been allow-listed for those legacy endpoints.
That matters operationally because a 403 there is a configuration state, not a code defect. Teams lose days treating it as a bug in their request construction. Check allow-list status first, then debug the payload.
A location can be authorized, quota-approved, and still silently reject edits. Google gates whether your changes surface on Search and Maps behind a state called Voice of Merchant: verified, not suspended, and eligible.
Call googlebusinessprofile_get_voice_of_merchant_state before any write path and surface the blocking condition. An agent that reports "updated successfully" for a location that lacks Voice of Merchant is lying to your customer, and the API will not tell you unless you ask.
Because both paths hit identical endpoints, this is not a capability decision. It is a decision about where you want scope enforcement, schema maintenance, and credential handling to live.
Most production builds end up doing both, and that is fine. Scalekit's request method exists precisely so the escape hatch runs through the same vaulted credential as the prebuilt tools.
Both paths hand you a refresh token per merchant. Neither hands you a vault, a rotation policy, or a revocation flow. That gap is identical whether you chose MCP or raw HTTP, because the gap is not in the protocol.
An agency platform with 400 client profiles stores 400 refresh tokens, encrypted at rest, isolated per tenant, never written to a log. Access tokens expire hourly. Refresh must be proactive rather than triggered by a 401, because reactive refresh across concurrent agent threads produces exactly the race conditions that make background execution unstable. The right approach to this is covered in detail in how to handle token refresh for AI agents.
Merchants revoke from their Google Account whenever a business relationship ends, with no callback to you. Every one of those becomes a silently failing scheduled agent until someone notices the dashboard stopped updating.
Scalekit's Google Business Profile connector handles the Authorization Code flow, per-tenant token storage, and refresh orchestration for both paths, so the MCP-versus-API decision does not change your auth infrastructure. Credentials never touch the agent runtime.
The connector-level detail that matters here: because business.manage cannot be narrowed at the scope layer, Scalekit's per-user scoped tool surface is doing the least-privilege work Google's OAuth implementation leaves undone.
The flow is the same in Python and TypeScript: configure the connection once, authorize each merchant once, retrieve the tools that merchant's connected account authorizes, then run the agent loop. Full setup steps are in the connector documentation.
Register your Google OAuth client in the Scalekit dashboard under AgentKit, then Connections. You supply the client ID and secret from your approved Google Cloud project along with the business.manage scope, and Scalekit supplies the redirect URI to paste into Google Cloud Console.
One detail costs people an afternoon: the connection name Scalekit generates is not googlebusinessprofile. It may be something like local-seo-agent-googlebusinessprofile. Copy the exact value from the dashboard and use it as connection_name everywhere.
Each merchant authorizes once. Scalekit creates a connected account holding that merchant's tokens and tracking their auth state, keyed by whatever identifier your application already uses.
This is the step that compensates for the single-scope problem. The agent does not load a connector catalog; it loads the tools this merchant's connected account is authorized to call, filtered to the subset this agent role needs.
The arithmetic is worth stating. On Scalekit's own estimate of roughly 200 tokens per tool definition, all 56 Google Business Profile tools cost about 11,000 tokens of context before the agent does any work. Scoping to six read tools removes most of that and removes googlebusinessprofile_delete_location from the decision space entirely.
Scalekit returns schemas with input_schema, the exact shape Anthropic's tool use API expects, so no conversion layer sits between the two. The loop below is complete: message construction, the messages.create call, the stop_reason check, tool result construction, and the message append.
Note what the model never receives: the merchant's access token, the refresh token, or the Google client secret. execute_tool resolves the credential server-side at request time.
The Node SDK mirrors the Python surface with camelCase naming. This variant scopes to the review-response tools, which is the other common Google Business Profile agent shape.
A production version of this agent should gate googlebusinessprofile_reply_to_review behind human approval. Replying overwrites any existing reply, and the write is immediately public on Google Maps.
When you need Lodging, Place Actions, or an endpoint Google shipped last week, request proxies raw HTTP through the same connected account. Scalekit injects the merchant's token; you write the path.
The escape hatch runs through the vault, so bypassing the prebuilt tool list does not mean bypassing tenant isolation or the audit trail.
A standard MCP server exposes everything it has. For a connector whose OAuth scope already grants destructive access, that default is the wrong one. Virtual MCP servers invert it: you declare which tools an agent can see and whose credentials it acts with, with no MCP server to deploy, host, or maintain.
Setup happens once per agent role, not once per merchant. The response carries a static mcp_server_url you reuse for every merchant and every session.
Four Google Business Profile tools and one Slack tool. googlebusinessprofile_delete_location and googlebusinessprofile_update_listing are not reachable from this endpoint regardless of what the underlying business.manage token permits.
The endpoint is static; the identity is not. Before each run, confirm the merchant's connections are still active, then mint a short-lived token bound to that merchant.
That active-connection check is how you catch a merchant who revoked access from their Google Account. You find out before the run starts rather than three tool calls in.
With the URL and token in hand, any MCP-capable framework connects over bearer auth. LangChain reaches it through langchain-mcp-adapters.
One server definition serves every merchant on the platform. Each run gets a token scoped to one merchant's connected accounts, so no credential is shared across tenants and no per-merchant server configuration exists to drift.
Google's own logs will show the merchant's OAuth identity replying to a review. They will not show which of your users triggered the agent, which agent role executed it, or which tenant it ran under. That distinction is the entire compliance question.
A single review reply touches the triggering user inside your product, the agent process that executed it, the merchant's OAuth grant that authorized the API call, and the tenant the run belonged to. Standard application logging captures one of those four.
When an agency's account manager asks why a reply went out under the wrong client's brand voice, "the Google API shows the merchant token replied" is not an answer. It is the absence of one.
Scalekit logs every execute_tool call with an execution ID, tied to the identifier that authorized it. Authorization events, token lifecycle events, and revocation state are captured at the connection layer; your application adds the agent-side events that link a user request to an execution.
The connection_id is the join key. It is what ties an action taken on Google Search and Maps back to the specific merchant consent that permitted it, which is what SOC 2 CC6.1 evidence actually requires. There is more on this pattern in audit trails for agent auth and agent tool observability.
If your agent is interactive, read-heavy, or multi-tool, run it through a scoped MCP endpoint. Google issues one all-or-nothing scope, so restricting what the model can see is the only least-privilege control you get, and MCP is where it lives.
If your agent is a nightly sync, a Pub/Sub consumer, or reaches into Lodging and Place Actions, call the API directly and own the pacing and retry envelope.
Either way: 400 merchants means 400 refresh tokens, an unnotified revocation path, and an audit trail Google will not assemble for you. Pick the protocol for the ergonomics. Solve the credentials at the infrastructure layer, because that is what decides whether this survives its second tenant.
Browse the Google Business Profile connector or the full agent connector catalog. Tool calling and audit logs start free; see pricing.
Building something in this space and want to compare notes on the 10-edits-per-minute ceiling or the update_mask hazard? Join the Scalekit Slack community, or talk to an engineer if you need an answer today.
Recommended reading: Google Ads MCP vs Google Ads API for AI Agents covers the connector where Google did ship an official server, and the read-only tradeoff that came with it.
Related agent templates: Competitive intelligence briefing agent and support triage agent are the closest patterns to a local-visibility briefing and a review triage loop respectively.
