Camberstack: Google Ads

Keyword volume and bids (Keyword Planner)

keyword_metrics

Read-only

Google Keyword Planner numbers for an exact list of keywords: average monthly searches, the last 12 months, competition and the top-of-page bid range in the account's currency. Use it to size keywords before adding them or to check a trend. Send the whole list in one call, not one per keyword: Keyword Planner rate-limits bursts. Up to 100 come back as objects; over 100, as a compact table (columns, months, rows). Changes nothing.

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

Input Schema

Name	Required	Description	Default
`keywords`	Yes	Keywords to look up, up to 500
`customer_id`	Yes	Google Ads customer ID, with or without dashes (from list_accounts)
`language_id`	No	Google language ID. 1000 English, 1003 Spanish, 1002 French, 1001 German, 1014 Portuguese	1000
`location_ids`	No	Google geo target IDs. 2840 United States, 2826 United Kingdom, 2124 Canada, 2036 Australia, 2356 India. For a state, city or other country, look the ID up with run_gaql: SELECT geo_target_constant.id, geo_target_constant.canonical_name FROM geo_target_constant WHERE geo_target_constant.name = 'Denver'

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

removedInput schema / properties / confirm_switch

Removed value: -{
-  "description": "Only after the user has agreed to spend their plan's account switch (a call answered \"Account switch:\"). Leave out otherwise",
-  "type": "boolean"
-}

Changed2 schema fields changedOct 16, 2026
- changedInput schema / properties / keywords / description
```
Previous value: -"Keywords to look up"New value: +"Keywords to look up, up to 500"
```
- changedInput schema / properties / keywords / maxItems
```
Previous value: -100New value: +500
```

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / confirm_switch

Added value: +{
+  "description": "Only after the user has agreed to spend their plan's account switch (a call answered \"Account switch:\"). Leave out otherwise",
+  "type": "boolean"
+}

Changed1 schema field changedOct 9, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

AddedOct 8, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, making the closing 'Changes nothing' largely redundant. The genuinely additive content is the rate-limit warning about bursting and the disclosure that responses switch shape at 100 keywords (objects versus a compact columns/months/rows table) - useful because no output schema exists. It still says nothing about latency, cost, or failure behavior for invalid keywords.

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

Conciseness5/5

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

Front-loaded with what the tool returns, then use cases, then the batching constraint, then the response-shape caveat. Roughly four short sentences and every one carries information an agent could not get from the structured fields.

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?

No output schema exists, yet the description covers the return shape at both size bands and the currency of bid values. Combined with a fully documented 4-parameter schema and read-only annotations, an agent has everything needed to call it correctly and interpret the result.

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

Parameters3/5

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

Schema coverage is 100%, and the schema itself supplies the language and geo ID mappings plus the run_gaql lookup recipe. The description adds only 'an exact list of keywords' and the account-currency note. That is honest added meaning but thin against a schema already doing the heavy lifting, so baseline 3 is right.

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 and resource (Google Keyword Planner numbers for an exact keyword list) and enumerates the returned metrics: average monthly searches, 12-month history, competition, top-of-page bid range in account currency. This is clearly distinct from the sibling keyword_ideas tool, which generates rather than measures.

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 usage contexts: 'size keywords before adding them' or 'check a trend'. It also gives a strong procedural rule: send the whole list in one call rather than one per keyword, because Keyword Planner rate-limits bursts. It never names keyword_ideas as the alternative, so it stops just short of full when/when-not routing.

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

All Camberstack: Google Ads tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.