Skip to main content
Glama

Get Google Keyword Planner forecasts from seeds and/or a landing page

fetch_keyword_forecasts
Read-only

Returns Google Keyword Planner forecasts (search volume, competition level, top-of-page CPC bid range in micros) for the given country/language. Use this to design ad-group themes and select keywords with good unit economics BEFORE drafting the campaign.

Two input sources, use either or both: • seeds — 0-20 seed keywords you derived from the brand's value-prop doc or the user's brief. • landingPageUrl — a target landing page; Keyword Planner extracts page-relevant ideas. If you have a landing page in the campaign brief, pass it here too — it produces ideas the seeds alone would miss (page copy and product names).

At least one of seeds or landingPageUrl is required. Returns up to 200 forecasts per call.

This is the preferred way to plan campaigns — call fetch_keyword_forecasts to see real search data, then design ad groups + write RSA copy yourself, then call save_campaign_draft to persist the structure.

Note: bid values are in micros (1_000_000 = 1.00 in the account's currency). Competition is LOW/MEDIUM/HIGH/UNKNOWN.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seedsNo0-20 seed keywords. Optional if landingPageUrl is provided.
countryYesTarget geography — any granularity Google Ads accepts: city, state, region, country, or postal code. Disambiguate non-unique names with the country (e.g. 'London, United Kingdom' not just 'London' — London, Ontario exists; 'Paris, France' not 'Paris' — Paris, Texas exists). For local-service brands push for city-level. Field name is 'country' for legacy reasons but free-text location resolves correctly via Google's geoTargetConstants:suggest API.
languageYesISO-639-1 language code: en, fr, es, de, pt, it, etc.
landingPageUrlNoOptional landing-page URL. KP extracts page-relevant ideas and blends with seeds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly/openWorld/idempotent=false) by disclosing the 200-forecast cap, the micros unit convention (1_000_000 = 1.00), the competition value set (LOW/MEDIUM/HIGH/UNKNOWN), and what landingPageUrl contributes. These are operational details an agent cannot get from the annotations.

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 with the return payload, then structured bullets for the two input sources, then the workflow note and units caveat. Slightly long with a mildly redundant restatement of the landing-page advice, but every block carries information.

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?

There is no output schema, so the description must carry the return contract — and it does: fields returned, micros conversion, competition enum values, and the 200-row limit. Combined with the required-input rule and the workflow handoff to save_campaign_draft, an agent can call this correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine semantics: seeds should be derived from the brand's value-prop doc or brief, landingPageUrl yields ideas seeds alone would miss, and bid values are micros. That is meaningful meaning beyond the schema text.

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?

States a specific verb+resource ('Returns Google Keyword Planner forecasts') and enumerates the returned fields (search volume, competition, top-of-page CPC in micros). It is clearly distinguishable from siblings like get_keyword_suggestions and get_campaign_report because it names the data source and the output.

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?

Gives explicit workflow positioning: use BEFORE drafting the campaign, then design ad groups and call save_campaign_draft to persist. It also states the at-least-one-input rule. It stops short of explicitly contrasting with the closest alternative, get_keyword_suggestions, so it is strong but not complete.

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