Skip to main content
Glama

Revenue by campaign

revenue_report
Read-onlyIdempotent

What the ads actually earned: spend from the ad account against the payments the business sent in, per campaign, ad set, ad or creative. Spend of the window against the payments this account sent to POST /v1/revenue, matched by the tags in the ad link, precise first: ad, then ad set, then campaign — by id or by name alike; when no tag names one object alone, the tags together (ad name and ad set name) may — and matched_by says which route carried how many. A name several objects share is never guessed: that money stays in unattributed with the tags it carried. level "creative" puts together the ads that share a name — one creative reused across ad sets — so money tagged with that name lands on it: the way to compare creatives by money. by "payment_date" (default) counts money that arrived; by "lead_date" what the leads of the window have paid. Ratios only in the ad account currency. Each row carries a verdict against target_roas (default 1.0) and against how long THIS account's leads take to pay, measured from its own payments: a cohort that has not had time to pay is never called a loss. If no payments of its own have ever been sent in (not only none in this window) and Meta counted purchases, the money is what Meta counted — purchases within 7 days of a click, with their value — and money_source says so: a shop whose pixel records every purchase gets its revenue and ROAS without sending anything. Without connection, when several ad accounts are connected, each is read and summarised — totals and the campaigns that spent most; call with connection for the full report of one. Read-only and free: changes nothing and does not count toward the monthly change limit. An identical read within 30 seconds may return the same data (see data_age_seconds).

Input Schema

NameRequiredDescriptionDefault
byNopayment_date (default): money that arrived in the window. lead_date: money earned by the leads of this window, whenever it was paid — needs lead_at on the events.
levelNoRows per campaign (default), ad set, ad, or creative — the ads that share one name, as one creative reused across ad sets.
end_dateNoLast day of an explicit window, YYYY-MM-DD, in the ad account time zone. Needs start_date.
raw_dataNotrue returns the measured numbers only: no severity, scores, recommendations or quick_actions.
connectionNoWhich connected ad account to use: the connection id from start_here or the ad account number (act_123 or 123). Needed only when several ad accounts are connected.
date_rangeNoWindow as a named range. Ignored when start_date and end_date are given.
start_dateNoFirst day of an explicit window, YYYY-MM-DD, in the ad account time zone. Needs end_date.
target_roasNoWhat this account expects back per unit of spend. Default 1.0.
lookback_daysNoWindow in days: 7, 14, 30, 60 or 90. Default 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint/idempotentHint/destructiveHint=false), the description adds cost and caching behavior ('free', does not count toward the monthly change limit, identical reads within 30s may return cached data via data_age_seconds), plus the full attribution fallback chain (tag matching, unattributed bucket, money_source/Meta-counted purchases, cohort that has not had time to pay never called a loss). This is genuinely useful context the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the body is a single dense run-on block of em-dashes and semicolons that is hard to parse. Much of it earns its place, yet the size and lack of structure impose a real reading cost for a 9-parameter tool.

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?

With no output schema and nine optional parameters, the description does substantial work: it explains return-relevant fields (matched_by, money_source, data_age_seconds), the multi-account summarise-vs-full-report behavior, and the attribution rules. It stops short of enumerating the row shape, so it is strong but not fully exhaustive.

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 prose adds real meaning: it explains the payment_date vs lead_date semantics, why level 'creative' exists (ads sharing a name = one reused creative), that target_roas drives a per-row verdict, and that raw_data strips severity/scores/recommendations. These enrich parameters beyond their schema text.

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 sentence names a concrete verb and resource — spend from the ad account matched against payments, broken down per campaign/ad set/ad/creative. It is far more specific than the title alone, but it never names or differentiates itself from siblings like get_insights, performance_dashboard or google_campaign_performance, so an agent must infer when this report is the right one.

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

Usage Guidelines3/5

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

Usage is only implied. The description explains mode switching ('call with connection for the full report of one') and defaults, but gives no explicit 'use this when you need X rather than Y' and names no alternative tool. An agent can infer the purpose but gets no routing guidance.

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.