A side-by-side look at the Google Business Profile MCP and Health Export MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Google Business Profile MCP for monitoring work as a local process; choose Health Export MCP for monitoring as a local process. You can also run both side by side in one mcpServers block.
GOOGLE_BUSINESS_CLIENT_ID, GOOGLE_BUSINESS_CLIENT_SECRET, GOOGLE_BUSINESS_REFRESH_TOKEN.auth_status, setup_instructions, set_client.HEALTH_DATA_DIR.get_mcp_status, list_metrics, get_health_metrics.Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Monitoring | Monitoring |
| Quality signal | 63/100 · Good | 65/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | GOOGLE_BUSINESS_CLIENT_IDGOOGLE_BUSINESS_CLIENT_SECRETGOOGLE_BUSINESS_REFRESH_TOKEN | HEALTH_DATA_DIR |
| Verified owner | Community listing | Community listing |
| GitHub stars | 4 | 6 |
| Directory activity | 2 views 0 installs 0 upvotes | 4 views 0 installs 0 upvotes |
| Tools | 26 | 14 |
| Full listing | View Google Business Profile MCP | View Health Export MCP |
auth_statusShows whether this server is connected to Google: token presence and source (env variables or a stored in-chat login), expiry, the Google account email, granted vs missing OAuth scopes, where the credentials file lives and where the OAuth client comes from. Makes no network calls and never returns the token itself. Call it first when other tools report the server is not connected.setup_instructionsStep-by-step checklist for connecting this server to Google: creating a Google Cloud project and a Desktop-app OAuth client, publishing the consent screen (mandatory — Testing-mode refresh tokens die after 7 days), downloading the client JSON and handing its PATH to set_client. Works without any credentials; the checklist shortens to 'enable the API + log in' when an OAuth client is already configured (one client serves the whole mcp-google-* line). Never asks the user to paste secrets into the chat.set_clientSaves the OAuth client credentials from the JSON file downloaded from Google Cloud Console ('Download JSON' on a Desktop-app client). Pass the file PATH — the secret must never be pasted into the chat. The client is stored once in the shared ~/.config/mcp-google-auth/client.json (owner-only) and reused by every mcp-google-* server; tokens stay per-server. After this, call start_login.start_loginFirst step of connecting from the chat, without editing config files or restarting the client. Returns authorizeUrl — show it to the user as a clickable link and ask them to open it in the browser ON THIS MACHINE, pick the Google account and approve access. A one-shot listener on 127.0.0.1 catches Google's redirect; the code is exchanged locally and never passes through the chat. Does not open the browser itself. The attempt lives 10 minutes; when the browser shows the success page, call finish_login.finish_loginSecond step: confirms the browser consent finished, saves the tokens to an owner-only file and verifies the login with a read-only identity call, returning the account email and the granted scopes. After success every tool works immediately — no client restart. If the user granted only part of the requested permissions, the login is still saved and missingScopes lists what will not work. Logging in under a different Google account replaces the previous login (its refresh token is revoked best-effort) and the response carries previousAccountEmail so the change never goes unnoticed.logoutRevokes the stored token at Google (oauth2.googleapis.com/revoke) and deletes the local credentials file. Tokens supplied via env variables are NOT touched — remove them from the MCP client config manually; envTokenStillSet in the response says whether any are still in effect.list_accountsLists all Google Business Profile accounts the authenticated user can access (the personal account first). Each account has name (accounts/{id} — the id feeds the accountId of other tools), accountName, type (PERSONAL / LOCATION_GROUP / USER_GROUP / ORGANIZATION), role, and verificationState. The API caps pageSize at 20 (unusually small), so follow nextPageToken to see every account.list_locationsLists the business locations under an account (Business Information API). Each location's name is locations/{id} — that id feeds locationId everywhere else (including the Performance API and, together with the account id, the v4 reviews/posts tools). totalSize is only present when filter is set. Fields are limited by readMask; ask for metadata to get mapsUri/placeId/newReviewUri.get_locationReturns one location by id (Business Information API; v1 uses the bare locations/{id} name, no account prefix). The readMask picks which fields come back: title, categories, storefrontAddress, phoneNumbers, websiteUri, regularHours, specialHours, openInfo, profile (description), storeCode, latlng, metadata (mapsUri, newReviewUri, placeId).update_locationUpdates fields of a location (PATCH with a required updateMask — only masked fields change). Pass the new values in `location`, e.g. {"title": "New name"} with updateMask "title". Set validateOnly to check the change without applying it. Note: every profile has a hard cap of 10 edits per minute (not raisable) — batch your changes into one call where possible. Returns the updated Location.list_categoriesLists/searches the reference taxonomy of business categories (e.g. gcid:restaurant). Category names (categories/gcid:...) feed location.categories on update_location and categoryName on list_attribute_metadata. view=FULL also returns serviceTypes and moreHoursTypes per category; filter narrows by display name, e.g. "displayName=coffee".list_attribute_metadataLists which attributes (e.g. wheelchair accessibility, wi-fi, payment options) are legal for a location or for a category+region. Pass locationId for a concrete location, OR categoryName+regionCode to explore. Each entry has parent (the attribute id for update_location_attributes), valueType (BOOL / ENUM / REPEATED_ENUM / URL), displayName, repeatable and valueMetadata (legal values).get_mcp_statusHealth check: data source, how many metrics/workouts are available, which optional context files exist, and the most recent data date. Call this first to confirm the bridge is connected.list_metricsList every available Apple Health metric with its unit, day count, and date range. Use this to discover metric names before querying.get_health_metricsGet values for a metric (or all metrics) over an optional date range, with an aggregate (avg/sum/min/max/latest). The core data-retrieval tool. Every result carries a `coverage` block giving the metric's real firstDate/lastDate/days: check it before trusting a long window, and note that `aggregate` is always computed over the full range even when `points` are rolled up. Single-metric answers also list any logged point events inside the window as segmentBoundaries.get_trendsCompare the most recent N-day window against the prior N days for a metric: change, percent change and direction (up/down/flat). Also returns `daysAvailable` and `windowSatisfied`: if windowSatisfied is false the file does not hold enough history for the window you asked for, and the comparison is over less data than requested. Logged point events inside the compared span are listed as segmentBoundaries.compare_periodsCompare a metric between two arbitrary date periods (A vs B): each aggregate plus the change and percent change. Pass periodA/periodB explicitly, or pass anchor {eventId, days} to build both periods around a logged event (the before/after question, with the event day excluded from both sides).get_structured_exportReturn clean structured JSON for the chosen metrics/date range. Paginated: the result carries `nextCursor` when more metrics remain; pass it back as `cursor` for the next page. Prefer naming the metrics you need and a date range; calling it bare over a full history is a lot of data.get_intradayThe current hour-by-hour window from the iOS app's HOURLY automations (health-intraday.json, app 1.4+): each metric's hourly points plus its latest value. The file is REPLACED on every hourly run, so this is a live within-day view, not history; use get_health_metrics for day-level questions. Returns available:false with setup guidance when no hourly automation has delivered yet.query_health_dataNatural-language convenience: pass a question and get routed structured results. Prefer the specific tools above when you can, and call list_metrics first to see how much history exists, since this tool answers over whatever the file holds.list_eventsLogged context events from health-events.json: medication starts, habit changes, doctor visits, life events, shift blocks, episodes, travel, and any type a newer app adds. Optional {type, tag, start, end} filters; a range event matches a window it overlaps. Sorted ascending by date. Returns available:false when the file was never exported; absence means nothing was exported, not that nothing happened.get_profileThe context fields the user explicitly opted in to sharing (health-profile.json): conditions, medications, goals, allergies, notes. Returns the fields plus a presentFields list. An absent field was withheld by the user or never enabled; absence must never be read as "none".get_workoutsQuery the workouts cache with {activityType (a name like Running, or a raw HealthKit id like 37), start, end} filters and pagination ({limit} default 50 max 200, {cursor} from a previous nextCursor). Records are returned exactly as stored, including the newer optional keys (avgHeartRate, maxHeartRate, running dynamics, cycling power, intervals, hasRoute) when the app exported them; older caches simply lack those keys and nothing is fabricated. Also returns summary {count, byActivityType} over everything that matched.get_sleep_sessionsClustered sleep sessions from health-sessions.json with {start, end, day} filters. Sessions are attributed to the WAKING day, matching the daily cache's sleep_analysis, so the two surfaces never disagree; a split night appears as multiple sessions with the same day, returned as-is. Timestamps carry the local UTC offset at the time of the sample.Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
{
"mcpServers": {
"google-business-profile-mcp": {
"command": "npx",
"args": [
"-y",
"mcp-google-business@latest"
],
"env": {
"GOOGLE_BUSINESS_CLIENT_ID": "YOUR_GOOGLE_BUSINESS_CLIENT_ID_HERE",
"GOOGLE_BUSINESS_CLIENT_SECRET": "YOUR_GOOGLE_BUSINESS_CLIENT_SECRET_HERE",
"GOOGLE_BUSINESS_REFRESH_TOKEN": "YOUR_GOOGLE_BUSINESS_REFRESH_TOKEN_HERE"
}
}
}
}
{
"mcpServers": {
"io-github-philipad-health-export-mcp": {
"command": "npx",
"args": [
"-y",
"health-export-mcp"
],
"env": {
"HEALTH_DATA_DIR": "YOUR_HEALTH_DATA_DIR_HERE"
}
}
}
}