Skip to main content
Glama

Google Ads: add location targets

set_geo_targets
Destructive

ADDS location criteria to a campaign; its existing locations stay.

On a campaign that already targets locations, each added target widens
where its ads show at once, which can raise what a running campaign
spends.

This never replaces targeting: the locations and exclusions the campaign
already has are left as they are. Moving a campaign from country A to
country B is two changes: add B here, then take A out with
remove_geo_targets. A campaign with no location criteria serves
everywhere; the first location added narrows it.

Add locations to TARGET with `location_ids`, locations to EXCLUDE with
`excluded_location_ids` (e.g. target India but exclude one city), and/or
a radius around a point or an address with `radius_targets` (e.g. 10 km
around a shop). Provide at least one of the three. A radius can only be
targeted, not excluded. With radius_targets the campaign is read first,
and a Video campaign is refused before anything is sent: the Google Ads
API cannot change Video campaigns, so its locations are set in Google
Ads.

Common location IDs (Google Ads geo target constants):
    US=2840, UK=2826, Canada=2124, Australia=2036,
    India=2356, Singapore=2702, UAE=2784,
    Germany=2276, France=2250

Find more IDs at:
https://developers.google.com/google-ads/api/data/geotargets

Args:
    customer_id: The Google Ads customer ID.
    campaign_id: The ID of the campaign.
    location_ids: Geo target constant IDs to TARGET. Optional.
    excluded_location_ids: Geo target constant IDs to EXCLUDE. Optional.
    radius_targets: Radius targets to add, each an object with:
        - radius: The distance, a number greater than zero.
        - radius_units: KILOMETERS or MILES. Default: KILOMETERS.
        - latitude and longitude: The centre in degrees (both together).
        - street_address, city_name, postal_code, province_code,
          province_name, country_code: The centre as an address, which
          Google turns into a point. With latitude and longitude the
          address is only a label.
        Each needs latitude and longitude, or an address. Optional.

Returns:
    Dictionary with created location criteria.

Tools revision: d80f65c0.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "customer_id": "<customer_id>",
      "campaign_id": "<campaign_id>"
    },
    "name": "set_geo_targets"
  }
}

Input Schema

NameRequiredDescriptionDefault
campaign_idYes
customer_idYes
location_idsNo
radius_targetsNo
excluded_location_idsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / radius_targets
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "additionalProperties": true,
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Radius Targets"
      +}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag the write/mutation profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true), and the description adds materially more: adding targets widens serving and can raise spend on a running campaign, existing locations/exclusions are never removed, a campaign with no criteria serves everywhere until the first location narrows it, and radius targeting cannot be excluded. That is exactly the consequence-level context annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and well-sectioned: behavior and the spend warning come first, then semantics, then per-argument detail. It is long, and the inline list of nine country IDs plus the docs URL is bulk that could be trimmed, but nearly every sentence prevents a real misuse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation with an output schema already declaring the return shape, the description covers everything an agent needs: what is added, what is preserved, the failure mode for Video campaigns, the at-least-one-argument constraint, and how to reverse the change. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden and does: it maps each parameter to intent (TARGET via location_ids, EXCLUDE via excluded_location_ids, radius via radius_targets), documents the nested radius object field-by-field including KILOMETERS/MILES with a stated default, the latitude/longitude-vs-address rule and that address becomes a label when coordinates are given, and supplies common geo target IDs with a lookup URL.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: "ADDS location criteria to a campaign; its existing locations stay." It also names the sibling that handles the opposite operation (remove_geo_targets), so an agent can distinguish it from the rest of the geo/negative-targeting family without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use and when-not: it never replaces targeting, moving from country A to B is "add B here, then take A out with remove_geo_targets", and at least one of the three argument groups must be supplied. It also states the precondition that radius_targets reads the campaign first and refuses Video campaigns before sending anything.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources