Per-location filtering for Google Business Profile is unusable through the MCP server. Any client with multiple GBP locations connected returns aggregated data only, with no way to scope to a single location.

The location-analytics data source exposes a location filter slot, declared as a string in filter_types, and the backend clearly validates it. Passing a non-numeric value returns the expected response:

location: "zzz-not-a-real-location" → INVALID_USER_REQUEST: Invalid location filter — the selected location is not in the connected account.

But passing an actual GBP location CID returns a completely different error:

location: "1486235012310451421" → The supplied integration_campaign_id is not a connected account for this client.

Same result for the locations/<id> prefixed form and for the value passed as an integer rather than a string.

The clearest evidence this is a routing bug and not a bad-value problem: passing location: "123" produces that same integration_campaign_id error. "123" is neither a valid location nor a valid account ID, so the request is never reaching the location filter at all — any numeric location value appears to be validated against the integration_campaign_id pre-flight check instead.

I confirmed the account ID I'm passing is correct and is the only connected GBP account for the client. It works on every call where location is absent or non-numeric, and a deliberately wrong account ID is correctly rejected. So the account ID isn't the issue — numeric location values are. Since real GBP location identifiers are always numeric CIDs, every valid input hits the broken path. No format workaround exists: bare CID, locations/ prefix, integer type, and a leading space to bypass the numeric check all fail identically.

Two related gaps worth addressing in the same fix:

There's no way to discover valid location values through MCP. location isn't an exportable field, isn't a valid group_by on location-analytics, and browse_client_data_sources returns the slot unhydrated (location: false). Even once the filter works, callers have to pull CIDs out of the UI by hand. Exposing the location list in browse_client_data_sources, or allowing location as a group_by, would make this properly usable — a single grouped call returning all locations would be far more useful than one call per location.

read_client_metrics returns "No results found" for provider google-my-business across every date range tested, including ranges where read_client_data_source returns data for those exact dates. The raw export is currently the only working path for GBP data. Possibly related.