Skip to main content
Glama

google_ads_ad_performance_compare

Rank enabled ads in a Google Ads ad group by performance and assign WINNER/LOSER/INSUFFICIENT_DATA verdicts. Read-only analysis provides insights without pausing or rotating ads.

Instructions

Rank ENABLED ads within a single Google Ads ad group and assign WINNER / LOSER / INSUFFICIENT_DATA verdicts. Returns {ad_group_id, period, ads:[{ad_id, impressions, clicks, conversions, cost, ctr, cvr, cpa, score (ctr*cvr, or ctr when conversions=0), rank, verdict, headlines?, descriptions?}], winner, recommendation, insights:[strings]}. Ads with impressions < 100 are flagged INSUFFICIENT_DATA; all ads tied at the top score receive WINNER, the rest LOSER. Read-only — does not pause or rotate ads. For cross-ad-group per-ad reporting use google_ads_ad_performance_report; for RSA asset-level splits use google_ads_rsa_assets_analyze.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodNoReporting window for the metrics. Default 'LAST_30_DAYS'. Use a shorter window (LAST_7_DAYS / LAST_14_DAYS) when diagnosing recent changes; use LAST_90_DAYS for trend baselines. Also accepts an explicit range in GAQL spelling — "BETWEEN 'YYYY-MM-DD' AND 'YYYY-MM-DD'", both endpoints inclusive, in the account's time zone — for a window no trailing constant can reach (e.g. a single past calendar month). One asymmetry to know about: every constant except LAST_90_DAYS is resolved by Google Ads in the account's reporting time zone, whereas LAST_90_DAYS has no API constant and is expanded by mureo into the 90 days ending yesterday **on the server's date**, so its edges can differ by a day when the server and the account are in different zones. Pass an explicit range when the exact boundary matters.
ad_group_idYesAd group ID as a numeric string (e.g. '145680123456'). Required — comparison is always scoped to one ad group so the ads share targeting. Obtain via google_ads_ad_groups_list.
customer_idNoGoogle Ads customer ID as a 10-digit string without dashes (e.g. '1234567890'). Optional — falls back to GOOGLE_ADS_CUSTOMER_ID / GOOGLE_ADS_LOGIN_CUSTOMER_ID from the configured credentials when omitted.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv0.17.1
    • addedInput schema / properties / period / anyOf
      Added value: +[
      +  {
      +    "enum": [
      +      "TODAY",
      +      "YESTERDAY",
      +      "THIS_WEEK_SUN_TODAY",
      +      "THIS_WEEK_MON_TODAY",
      +      "LAST_BUSINESS_WEEK",
      +      "LAST_WEEK_SUN_SAT",
      +      "LAST_WEEK_MON_SUN",
      +      "LAST_7_DAYS",
      +      "LAST_14_DAYS",
      +      "LAST_30_DAYS",
      +      "LAST_90_DAYS",
      +      "THIS_MONTH",
      +      "LAST_MONTH"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "pattern": "\\ABETWEEN '([0-9]{4}-[0-9]{2}-[0-9]{2})' AND '([0-9]{4}-[0-9]{2}-[0-9]{2})'\\Z",
      +    "type": "string"
      +  }
      +]
    • changedInput schema / properties / period / description
      Previous value: -"Reporting window for the metrics. Default 'LAST_30_DAYS'. Use a shorter window (LAST_7_DAYS / LAST_14_DAYS) when diagnosing recent changes; use LAST_90_DAYS for trend baselines."New value: +"Reporting window for the metrics. Default 'LAST_30_DAYS'. Use a shorter window (LAST_7_DAYS / LAST_14_DAYS) when diagnosing recent changes; use LAST_90_DAYS for trend baselines. Also accepts an explicit range in GAQL spelling — \"BETWEEN 'YYYY-MM-DD' AND 'YYYY-MM-DD'\", both endpoints inclusive, in the account's time zone — for a window no trailing constant can reach (e.g. a single past calendar month). One asymmetry to know about: every constant except LAST_90_DAYS is resolved by Google Ads in the account's reporting time zone, whereas LAST_90_DAYS has no API constant and is expanded by mureo into the 90 days ending yesterday **on the server's date**, so its edges can differ by a day when the server and the account are in different zones. Pass an explicit range when the exact boundary matters."
    • removedInput schema / properties / period / enum
      Removed value: -[
      -  "TODAY",
      -  "YESTERDAY",
      -  "LAST_7_DAYS",
      -  "LAST_14_DAYS",
      -  "LAST_30_DAYS",
      -  "LAST_90_DAYS",
      -  "THIS_MONTH",
      -  "LAST_MONTH"
      -]
  2. Changed1 schema field changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv0.9.12
  4. Removedv0.9.6
  5. Addedv0.9.2
  6. Removedv0.9.1
  7. Addedv0.6.0
  8. Removedv0.3.2
  9. Addedv1.0.5

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it states the tool is read-only and does not pause or rotate ads, discloses the scoring formula (ctr*cvr, or ctr when conversions=0), defines the INSUFFICIENT_DATA threshold (impressions < 100), and explains tie handling. It even spells out the return shape in detail.

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?

The description is front-loaded with the core action, then the return shape, then verdict rules, then read-only disclosure, then sibling routing. Every sentence earns its place; the inline return-structure listing is justified because no output schema is provided.

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 read-only analysis tool with no annotations and no output schema, the description is remarkably complete: it explains the output fields, verdict criteria, edge-case handling, side-effect absence, and alternative tools. No critical decision-relevant information is left to inference.

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 description coverage is 100%, so the baseline is 3 and the schema already richly documents period, ad_group_id, and customer_id, including timezone caveats. The tool description adds contextual meaning about single-ad-group scoping but does not materially expand on parameter formats or defaults beyond what the schema provides.

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?

The description opens with a specific verb and resource: 'Rank ENABLED ads within a single Google Ads ad group' and states the exact verdict vocabulary (WINNER / LOSER / INSUFFICIENT_DATA). It also names the sibling tools it is not — google_ads_ad_performance_report and google_ads_rsa_assets_analyze — which fully distinguishes it from nearby alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: use this tool for single-ad-group ad comparison, use google_ads_ad_performance_report for cross-ad-group per-ad reporting, and use google_ads_rsa_assets_analyze for RSA asset-level splits. The scope restriction ('always scoped to one ad group') is also clearly stated.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/logly/mureo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server