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: 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>",
      "fields": "<fields>",
      "resource": "<resource>"
    },
    "name": "search"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
fieldsYes
end_dateNo
resourceYes
orderingsNo
conditionsNo
start_dateNo
customer_idYes

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 read-only and idempotent annotations, it discloses AND-joined conditions, rejection of unlisted parameters, automatic quoted date filters, resource-specific date behavior, 30/90-day retention windows, the 10000-row limit for change resources, and unsupported date literals. The keyword/search-term attribution and privacy explanation also prevents agents from misreading expected reporting differences as data errors.

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 purpose and query template are front-loaded, while headings and examples make the long definition navigable. It is somewhat repetitive—date behavior appears in both Args and Dates—and the trailing revision identifier and loosely connected conversions note add bulk without helping most invocations.

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 an eight-parameter GAQL generator, it covers query construction, metadata discovery, valid syntax, worked examples, date handling, special resources, and important reporting caveats. Because an output schema is present, the lack of return-value documentation is not a meaningful gap.

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?

With 0% schema description coverage, the Args section fully compensates by explaining all eight parameters, including digits-only customer IDs, fully qualified field names, condition and ordering syntax, and YYYY-MM-DD dates. It further documents interactions between start_date and end_date, their change-resource exceptions, and the role of limit.

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 statement, 'Reads rows from one Google Ads resource,' together with the explicit SELECT/FROM/WHERE/ORDER BY/LIMIT construction, makes the operation and scope clear. It does not explicitly distinguish this general GAQL interface from sibling reporting tools such as performance_report or change_history.

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?

Concrete report examples, directions to get_resource_metadata for resource and field discovery, and special instructions for dates and change_event/change_status provide strong usage context. However, the description does not explain when this general-purpose tool should be preferred over, or avoided in favor of, higher-level reporting siblings.

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