Skip to main content
Glama

Google Ads: run a report (GAQL)

search
Read-onlyIdempotent

Reads rows from one Google Ads resource.

The tool writes the GAQL query from these parameters:
SELECT `fields` FROM `resource` WHERE `conditions` (joined with AND)
ORDER BY `orderings` LIMIT `limit`.

Args:
    customer_id: The customer ID, digits only (123-456-7890 is
        1234567890).
    fields: The fields to return, each written in full, e.g.
        "campaign.id".
    resource: The one resource the rows come from, e.g. "campaign".
    conditions: Filters, one GAQL condition each, e.g.
        "campaign.id = 123"; every one must hold.
    orderings: Sort order, e.g. "metrics.clicks DESC".
    limit: The maximum number of rows to return.
    start_date: Report start date (YYYY-MM-DD). Adds a quoted `segments.date`
        filter — use this instead of hand-writing dates into `conditions`.
        On change_event/change_status it filters their own date-time.
    end_date: Report end date (YYYY-MM-DD). Combined with start_date this
        produces a finite `segments.date BETWEEN 'start' AND 'end'` filter
        (on change_event/change_status, a range on their own date-time
        instead).

There is no parameter for a whole query string, and a parameter not listed above is refused rather than ignored.

Example

The enabled ads of one campaign, by ad group:
    resource="ad_group_ad"
    fields=["ad_group.name", "ad_group_ad.ad.id", "ad_group_ad.status"]
    conditions=["campaign.id = 12345678901",
                "ad_group_ad.status = 'ENABLED'"]
    orderings=["ad_group.name"]
Clicks and cost by campaign for August:
    resource="campaign"
    fields=["campaign.name", "metrics.clicks", "metrics.cost_micros"]
    start_date="2026-08-01", end_date="2026-08-31"

GAQL reference, for writing fields and conditions

Overview: https://developers.google.com/google-ads/api/docs/query/overview
Language Grammar: https://developers.google.com/google-ads/api/docs/query/grammar
Resources and fields: https://developers.google.com/google-ads/api/fields/v23/overview
get_resource_metadata returns the fields a resource can select, filter
and sort by, and the list of valid resources when the name given is not
one. Field names are written in full ('campaign.id', not 'id'); wildcards
and partial field names are not accepted. Common resources: campaign,
ad_group, ad_group_ad, ad_group_criterion, keyword_view,
search_term_view, campaign_budget, customer, asset, change_event.

Dates

start_date and end_date (YYYY-MM-DD) add a correctly quoted
`segments.date` filter (change_event and change_status are the
exception, see below), which avoids the most common query error. A date
written into `conditions` is a quoted string, e.g.
segments.date BETWEEN '2026-08-01' AND '2026-08-28' (an unquoted date is
a GAQL syntax error). Date literals from the Grammar (e.g. DURING
LAST_7_DAYS) are not supported here.

Keyword and search-term reporting

Metrics on keyword_view and search_term_view are attributed only to the
matched keyword/term, so they will NOT sum to the campaign or ad_group
totals. The remainder is traffic with no single matched keyword, plus
low-volume search terms Google withholds below a privacy threshold. This
is expected Google attribution, NOT a data error; top-line numbers
reconcile at the campaign or ad level.

change_event and change_status

Pass start_date AND end_date plus a limit of at most 10000. The dates
filter change_event.change_date_time / change_status.last_change_date_time
(these resources forbid segments.date). Google keeps change_event for the
last 30 days and change_status for the last 90 days.

Conversions

Upload issues: offline_conversion_upload_conversion_action_summary
(https://developers.google.com/google-ads/api/docs/conversions/upload-summaries).

Tools revision: 5c9bea8f.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
fieldsYes
end_dateNo
resourceYes
orderingsNo
conditionsNo
start_dateNo
customer_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: unknown parameters are 'refused rather than ignored', there is no whole-query-string parameter, unquoted dates are a syntax error, GAQL date literals are unsupported, and change_event/change_status retain data for only 30/90 days. The keyword_view/search_term_view attribution caveat preempts a likely false 'data error' conclusion.

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 query template and an Args block, then clearly headed sections and two worked examples, so length is largely earned. The cost is duplication: the start_date/end_date filter behavior and the change_event/change_status exception are each stated in the Args block and again in the 'Dates' and 'change_event' sections.

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 complex, low-level query tool with an output schema (so return values need no explanation), nothing an agent needs is missing: query construction, field-naming rules, date handling, per-resource constraints, and interpretation caveats for keyword/search-term metrics. The get_resource_metadata handoff covers field discovery.

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 carries the full burden and does: customer_id format rules, fields must be written in full (no wildcards), resource is exactly one, conditions are AND-joined, orderings syntax, and limit semantics. start_date/end_date get the richest treatment, including the exception that they filter the resource's own date-time on change_event/change_status.

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: 'Reads rows from one Google Ads resource', then shows the exact GAQL shape it constructs from the parameters. An agent can immediately distinguish this general report runner from siblings like get_resource_metadata, analyze_search_terms or rsa_asset_report.

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 concrete routing rules: use start_date/end_date 'instead of hand-writing dates into conditions', and consult get_resource_metadata for valid fields and the resource list. It also states resource-specific preconditions (change_event/change_status require both dates and limit <= 10000). It stops short of saying when to prefer this over the many purpose-built report tools, e.g. analyze_search_terms or keyword_opportunities.

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