Skip to main content
Glama

Camberstack: Google Ads

by io.camberstack
OverviewDiscussionsAdmin

Run a read-only GAQL query

run_gaql
Read-only

Runs any read-only Google Ads Query Language SELECT for questions the other tools don't cover. Returns up to 500 rows. Google rejects queries that break these rules: selecting or segmenting by segments.date needs a finite range in WHERE (segments.date DURING LAST_30_DAYS, or BETWEEN 'YYYY-MM-DD' AND 'YYYY-MM-DD'); click_view needs a single day (segments.date = 'YYYY-MM-DD'); every field used in WHERE or ORDER BY must also be in SELECT. Maximize clicks is target_spend in the API: campaign.target_spend.cpc_bid_ceiling_micros (there is no campaign.maximize_clicks). Unsure of a field's name or whether it fits this FROM? Look it up first with a query that has no FROM, which reads Google's field catalog instead of the account (any customer_id): SELECT name, category, selectable WHERE name LIKE '%search_term%', or SELECT attribute_resources, metrics, segments WHERE name = 'campaign' for what can be used FROM campaign.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesA GAQL SELECT statement
customer_idYesGoogle Ads customer ID, with or without dashes (from list_accounts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
-}
  2. Changed1 schema field changed
    • 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"
+}
  3. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, and openWorldHint, so the safety profile is covered. The description adds real behavioral value beyond that: a 500-row result cap and the server-side rejection rules (date segmentation, click_view, WHERE/ORDER BY fields must appear in SELECT). It leaves error/pagination behavior unspecified, so 4 rather than 5.

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 description is long but every sentence is substantive domain knowledge, and the core purpose is front-loaded in the first clause. It could be tightened slightly (the rule list runs on inline), but there is no filler to cut.

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, yet the description covers the return cap (500 rows) and supplies the query-validity rules an agent needs to avoid server-side rejection, plus the field-catalog trick and the maximize-clicks/target_spend mapping. Nothing essential for a correct invocation is missing.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that for the catalog lookup any customer_id works, and by framing the query parameter's expected shape as a GAQL SELECT with enumerated semantic rules rather than just a string type.

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 (run a read-only GAQL SELECT) and constrains scope to 'questions the other tools don't cover', which distinguishes it from the many sibling report tools. An agent can identify the intended use without opening any schema.

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 a clear routing rule (fallback for questions other tools don't cover) and even describes a second usage mode: use a FROM-less query to inspect Google's field catalog before committing to a real query. It does not name specific sibling tools to prefer or spell out hard exclusions, so it stops short of a full 5.

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 toolsInspect
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.

Resources