Skip to main content
Glama
MoonEyes

google-ecommerce-mcp

by MoonEyes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Meta Ads insights

meta_insights
Read-onlyIdempotent

Retrieve Meta Ads performance by account, campaign, adset, or ad, including spend, impressions, clicks, purchases, ROAS, and CTR, with date filters and audience breakdowns.

Instructions

Meta Ads performance (spend, impressions, clicks, reach, purchases, purchase value, ROAS) by level.

ctr is recomputed as a ratio 0..1, ROAS = purchase value / spend (totals: sum of values / sum of spends), Meta's own purchase_roas is kept raw in meta_reported_roas. Currency is the ad account's, never converted.

Input Schema

NameRequiredDescriptionDefault
levelNoRow level: account (one row per period), campaign, adset or adaccount
limitNoMaximum rows returned (1 to 500), highest spend first (daily rows too); totals cover up to 5 pages of 500 rows
end_dateNoYYYY-MM-DD, last day included; leave empty with start_date to use date_preset
client_idNoClient id from clients_list; empty uses the only client
account_idNoAd account id (digits or act_<digits>); empty means META_AD_ACCOUNT_ID
breakdownsNoOptional extra split of each row, from a fixed list: age, gender, country, region, publisher_platform, platform_position, device_platform, impression_device
start_dateNoYYYY-MM-DD, first day in the ad account's timezone; leave empty with end_date to use date_preset
date_presetNoMeta relative period (e.g. last_7d, last_month), exclusive with start_date/end_date; all three empty means last_28d
time_incrementNoall_days: one row for the whole period; 1: one row per dayall_days
attribution_windowsNoOptional attribution windows for purchases (e.g. 7d_click); empty means Meta's default 7-day click + 1-day view; several windows give one figure per window, no single total

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",
+  "title": "Client Id"
+}
  2. Addedv0.4.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), but the description adds non-obvious semantics an agent cannot get from structured fields: ctr is recomputed as a 0..1 ratio rather than Meta's percentage, ROAS is defined as purchase value / spend with the totals caveat, Meta's raw purchase_roas is preserved in meta_reported_roas, and currency is never converted. It does not describe result column layout or how totals/paging behave beyond the metric definitions, keeping it short of a 5.

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?

Three tight sentences: purpose and metric scope first, then the recomputation/definition rules, then the currency caveat. No filler and every clause carries information the agent would otherwise have to guess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only report tool with 10 optional parameters, no output schema, and a rich input schema, the description supplies the metric set and the computed-field semantics that would otherwise be ambiguous. What remains thin is output shape (which columns appear for each level/breakdown combination), though the schema's limit/totals notes partially cover it.

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% and the schema already documents defaults, enum values, date-vs-preset exclusivity, breakdown list, and the limit/totals behavior. The description only indirectly touches parameters via 'by level' and mentions 'totals' but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 resource (Meta Ads performance) with an explicit metric list (spend, impressions, clicks, reach, purchases, purchase value, ROAS) and the aggregation dimension ('by level'), which maps directly to the `level` enum. An agent can distinguish this reporting tool from sibling listing tools like meta_ads_list, meta_campaigns, and meta_adsets without opening the schema.

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

Usage Guidelines2/5

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

There is no statement of when to choose this tool over siblings such as meta_ads_list, openai_ads_insights, gads_performance or ads_overview, and no prerequisites or exclusions are given. Usage is only inferrable from the purpose sentence, so this matches the 'no guidance' band rather than the implied-usage band.

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