Skip to main content
Glama

Google Ads: find keyword ideas

get_keyword_ideas
Read-onlyIdempotent

Finds keyword ideas with Google's search volume, competition and top-of-page bid range.

page_url and site can be any public web page or website, not only the
customer's own; Google reads it to suggest ideas.

Ideas grow from keywords, a landing page or a whole site: pass keywords
(1 to 20), page_url, keywords with page_url, or site alone. Figures are
Google's estimates from the last 12 months; avg_monthly_searches is null
where Google reports too few searches to show. A new account, or one
that has never spent, can get ranges or no ideas. It reads only and
saves nothing.

Each call is one request to Google and returns one page of at most
`limit` ideas; next_page_token asks for the next page. Google accepts
about one keyword planning request per second per account, so a request
within a second of the last one for the same account waits for the rest
of that second.

Args:
    customer_id: The Google Ads customer ID (numbers only, no hyphens).
    keywords: Seed keywords or phrases, 1 to 20.
    page_url: A page whose content seeds the ideas (http:// or https://).
    site: A domain whose pages seed the ideas, e.g. "example.com". Not
        combined with keywords or page_url.
    geo_target_ids: Location ids (geo target constants, e.g. 2356 for
        India; search geo_target_constant to find one), at most 10.
        Default: every location.
    language_id: Language id (language constant). Default 1000, English.
    network: GOOGLE_SEARCH (default) or GOOGLE_SEARCH_AND_PARTNERS.
    include_adult_keywords: Include adult ideas. Default false.
    include_monthly_trend: Add each idea's searches for the last 12
        months.
    include_average_cpc: Add the average cost per click. Default true.
    limit: Ideas on this page, 1 to 200. Default 50.
    page_token: next_page_token from the call before, for the next page
        of the same request.

Returns:
    ideas (text, avg_monthly_searches, competition LOW/MEDIUM/HIGH,
    competition_index 0-100, low_top_of_page_bid and high_top_of_page_bid
    in the account's currency, average_cpc, close_variants), returned,
    total_size, truncated, next_page_token, query and notes.

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>"
    },
    "name": "get_keyword_ideas"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNo
limitNo
networkNoGOOGLE_SEARCH
keywordsNo
page_urlNo
page_tokenNo
customer_idYes
language_idNo
geo_target_idsNo
include_average_cpcNo
include_monthly_trendNo
include_adult_keywordsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), it discloses the rate-limit behavior (about one request per second per account, and a call inside that window waits), pagination semantics via next_page_token, and data caveats: 12-month estimates, null avg_monthly_searches where volume is too low, and ranges or no ideas for new or never-spent accounts. It also confirms 'reads only and saves nothing,' which is consistent with readOnlyHint.

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?

The definition is front-loaded with purpose, then constraints, then a structured Args/Returns block, and nearly every sentence adds operational detail. The Returns section restates fields already exposed by the existing output schema, which is some redundancy. It is long but justified for a 12-parameter tool.

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?

Given 12 parameters, an open-world external API call, and a mutation-free but rate-limited operation, the description covers seeding rules, defaults, throttling, pagination, empty/partial-result cases, and bid currency. Nothing an agent needs to invoke it correctly or interpret thin results 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 all parameter meaning, and it does: customer_id as numbers only/no hyphens, keywords 1-20, page_url requiring http(s)://, site as a bare domain with an example, geo_target_ids capped at 10 with a concrete id and a pointer to geo_target_constant, language_id default 1000, the two network values, and limit 1-200 default 50. Every one of the 12 parameters receives meaning the bare schema lacks.

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

Purpose4/5

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

The opening sentence names a specific verb and resource ('Finds keyword ideas') plus the three returned figures (search volume, competition, top-of-page bid range), so the agent knows exactly what it gets. The seed-mode sentence clarifies that ideas are generated from keywords, a page, or a site, which implicitly separates it from metrics/forecast siblings. It stops short of naming get_keyword_metrics, get_keyword_forecast, or keyword_opportunities, which is the only missing piece for a 5.

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

Usage Guidelines4/5

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

The description gives concrete usage modes: keywords alone (1-20), page_url alone, keywords with page_url, or site alone, and explicitly excludes combining site with keywords or page_url. That is strong 'how to call it' guidance. It never states when to choose this over the sibling keyword tools, so it earns a 4 rather than a 5.

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