Skip to main content
Glama
MoonEyes

google-ecommerce-mcp

OpenAI Ads insights

openai_ads_insights
Read-onlyIdempotent

Query OpenAI Ads performance over a date range, including impressions, clicks, spend, CTR, conversions, and attributed sales for an account, campaign, ad group, or ad.

Instructions

OpenAI Ads (ChatGPT ads) performance over a date range: impressions, clicks, spend, ctr, conversions and attributed sales for the ad account or one campaign, ad group or ad. Returns "rows" as reported (flat keys such as campaign_id; null kept, null_means "non calculable"), recomputed "totals" (roas = sum of sales / sum of spend), "currency" (from order_created_attributed_sales_currency, else None), "date_range" in the timezone returned by the API, "next_after" while has_more (reads up to max_rows rows over at most 5 pages), units (spend in major currency units, ctr ratio) and "attribution". No automatic retry.

Input Schema

NameRequiredDescriptionDefault
sortNoOptional sort criteria in order: [{"field": "spend", "direction": "desc"}] (at most 5)
afterNonext_after (last_id) of a previous call to read the next rows; empty to start
levelNoWhich endpoint: account = the whole ad account; campaign, ad_group or ad = one entity given by entity_idaccount
beforeNofirst_id of a previous call to read the rows before it (one page); not with after
fieldsNoCanonical field names, e.g. impressions, clicks, spend, ctr, cpc, cpm, conversions, cpa, post_click_cvr, order_created_attributed_sales, order_created_attributed_sales_currency, order_created_roas, campaign.id, campaign.name, metadata.readable_time, metadata.timezone; empty for these metrics plus metadata.timezone
filtersNoOptional filters, combined with AND: {"field": "campaign.id", "operator": "IN", "value": ["cmpn_1"]} or {"field": "ad.clicks", "operator": "GREATER_THAN" or "LESS_THAN", "value": 10} (at most 10)
segmentNoOptional single segment: product, country, device or platform (request segment fields such as country.clicks)
end_dateYesLast day, YYYY-MM-DD (inclusive)
max_rowsNoMaximum rows returned by this call (1 to 6000), over at most 5 pages
timezoneNoOptional IANA timezone of the day boundaries; empty uses the ad account timezone (keep empty for conversion or sales metrics, which require whole days in the account timezone)
client_idNoClient id from clients_list; empty uses the only client (or the environment variables without a registry)
entity_idNoId of the campaign, ad group or ad (letters, digits, _ and -); empty for level account
page_sizeNoRows per API page (1 to 2000)
start_dateYesFirst day, YYYY-MM-DD
time_granularityNonone: one row per entity for the period; daily, monthly or hourly (hourly: about 30 days of history, not with a segment)none
aggregation_levelNoRow entity inside the endpoint scope: ad_account, campaign, ad_group or ad; empty uses the endpoint level
attribution_time_basisNoad_event_time (API default) or conversion_time; empty sends nothing
attribution_window_daysNoClick attribution window in days: 7, 14 or 30
include_zero_impression_itemsNoTrue: also return entities with zero impressions (only without a segment)
view_through_attribution_window_daysNoView-through attribution window in days: 0 or 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / client_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Client id from clients_list; empty uses the only client (or the environment variables without a registry)",
      +  "title": "Client Id"
      +}
  2. Addedv0.4.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantive behavior: rows are returned flat with nulls kept and a null_means of 'non calculable', totals are recomputed (roas = sum of sales / sum of spend), currency source, date_range in the API-returned timezone, next_after pagination bounded to max_rows over at most 5 pages, units (spend in major currency units, ctr as a ratio), and the explicit 'No automatic retry' note the agent must plan around.

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?

Purpose is front-loaded in the first clause and every listed return element (rows, totals, currency, date_range, next_after, units, attribution) carries information. The second sentence is a long run-on string of comma-separated clauses, which slightly harms scannability but does not contain filler.

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 20-parameter reporting tool with no output schema, the description carries the missing return-value burden well by naming the response keys, their semantics, currency/units, pagination limits and retry behavior. Combined with 100% schema coverage on inputs, an agent has what it needs to call this correctly.

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 schema already documents all 20 parameters with their enums, defaults and ranges; that sets the baseline at 3. The description reinforces a few of these (max_rows over 5 pages, null semantics, currency units) but adds little parameter meaning the schema does not already carry.

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+resource+scope: 'OpenAI Ads (ChatGPT ads) performance over a date range: impressions, clicks, spend, ctr, conversions and attributed sales for the ad account or one campaign, ad group or ad.' The metric list and entity scope cleanly separate it from sibling entity-listing tools like openai_ads_campaigns/ad_groups/ads and from openai_ads_conversions.

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?

It gives concrete conditional constraints — timezone should stay empty for conversion/sales metrics, hourly is 'not with a segment', include_zero_impression_items works 'only without a segment', and before is 'not with after'. However, it never routes the agent to or away from sibling tools (e.g. openai_ads_conversions, meta_insights), so the when-not/alternatives bar for a 5 is not met.

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

Deploy Server

Other Tools