Skip to main content
Glama
mambalabsdev

Google Ads Transparency Monitor MCP Server

Get Google ads

get_google_ads
Read-onlyIdempotent

List Google ads a company runs by domain or advertiser name, returning ad format, dates, creative links, and a summary of ad activity.

Instructions

List the Google ads a company runs, read from Google's public Ads Transparency Center. Give a company domain (for example stripe.com) or an advertiser name, or lists of either. Returns one row per ad with the advertiser, ad ID, format (text, image, or video), first and last shown dates, a creative link, and the ad's Transparency Center page, plus one company summary row per input with Google's total ad count band, formats seen, and whether the company runs Google ads at all. Rows with no ads, blocked requests, or a changed Google page come back free with a row_status saying so. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN and consumes Apify credits per ad row returned.

Input Schema

NameRequiredDescriptionDefault
regionNoWhere the ads were shown: anywhere, or a two letter country code such as US, GB, DE, or FR. Default anywhere.
domainsNoSeveral company domains. Each gets its own ad rows and summary row. Up to 500 inputs per run.
formatsNoLimit to text, image, or video ads. Omit for all formats.
max_adsNoAd rows per input, 1 to 1000. Each ad row is billed. Default 50.
skipCacheNotrue reads fresh results instead of the free 24 hour cache in your account. Default false.
proxy_modeNoauto connects directly and moves to the Apify proxy default pool if Google refuses a request; direct never uses a proxy; residential uses Apify residential proxy. Apify bills proxy traffic to your account. Default auto.
since_daysNoOnly ads last shown in this many days. 0 returns every ad Google lists. Default 90.
company_domainNoA company website domain, for example stripe.com. Returns the ads Google lists for that domain. Give this, advertiser_name, or one of the lists.
max_charge_usdNoOptional. The run stops before any row that would take its charges over this amount.
advertiser_nameNoAn advertiser name as Google verifies it, for example Stripe, Inc. Exact name matches are used, up to 5 advertisers; otherwise the closest suggestion, labeled closest.
include_summaryNoOne extra summary row per input, billed only when ads were found. Default true.
advertiser_namesNoSeveral advertiser names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, but the description adds substantially more: it requires an APIFY_TOKEN, consumes Apify credits per ad row returned, returns free rows with a row_status for no-ads/blocked/changed-page cases, and surfaces failed runs as errors with a run ID. That is exactly the partial-success and billing behavior an agent cannot infer from annotations.

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 and input modes are front-loaded, followed by return shape, then error and billing semantics in a tight sequence. It is a dense paragraph rather than a list, and a couple of clauses are long, but each sentence carries distinct information rather than repeating the schema.

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?

With 12 parameters, zero required, and no output schema, the description compensates by enumerating the returned row fields (advertiser, ad ID, format, first/last shown, creative link, Transparency Center page) and the per-input summary row plus total ad count band. Combined with the documented failure and cache behavior, an agent has everything needed to call and interpret this tool.

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, but the description adds cross-parameter routing logic the schema does not: company_domain, advertiser_name, and the list variants are stated as alternatives, and max_ads/credit tradeoffs are linked to billing. It does not add format or syntax detail for the remaining parameters, which the schema already covers.

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 (list) and resource (Google ads a company runs) and names the exact data source (Google's public Ads Transparency Center). Even without siblings, the scope is unambiguous, and the description further specifies the query modes (domain, advertiser name, or lists of either) so an agent knows precisely what the tool retrieves.

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 tells the agent how to invoke the tool usefully: 'Give a company domain ... or an advertiser name, or lists of either,' and the schema reinforces the OR relationship between company_domain, advertiser_name, and the list variants. There are no sibling tools or explicit when-not conditions to route against, so this is clear context without exclusions.

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