Skip to main content
Glama

Get report

get_report
Read-onlyIdempotent

Drill-down report: group by one or more dimensions; rows come back for the dimension at level (0-based), path carries the parent row keys when drilling deeper. Every row has key, label and the full metric set. compare=true adds the previous period (same length right before; the previous calendar month for this_month/last_month): each row gets prev (its metrics then, null = no traffic then) — date/week/month rows are matched to the same position in the previous window (22 Sep vs 15 Sep for 7days), drill-down paths are translated the same way — plus prev_totals and prev_range. The basis for "what changed / what dropped vs last week" questions.

Input Schema

NameRequiredDescriptionDefault
osNo
ispNo
cityNo
pathNoParent row keys for levels above `level`
siteNoPlacement / zone id as passed by the ad network
sub1NoFilter by sub1
sub2NoFilter by sub2
sub3NoFilter by sub3
sub4NoFilter by sub4
sub5NoFilter by sub5
sub6NoFilter by sub6
sub7NoFilter by sub7
sub8NoFilter by sub8
sub9NoFilter by sub9
userNoWorkspace member id(s), comma-separated — the campaign owner at click time (needs the "See statistics per team member" permission; ignored otherwise)
levelNoWhich group_by level to return rows for (default 0)
offerNoOffer id
sub10NoFilter by sub10
sub11NoFilter by sub11
sub12NoFilter by sub12
sub13NoFilter by sub13
sub14NoFilter by sub14
sub15NoFilter by sub15
deviceNomobile / tablet / desktop
periodNoReporting period (default 7days). Use 'custom' with date_from/date_to.
sourceNoTraffic source id
browserNo
compareNoAlso return the previous period per row (`prev`) and in total (prev_totals)
countryNoCountry ISO alpha-2 code, e.g. ES
date_toNoYYYY-MM-DD (with period=custom)
landingNoLanding id
campaignNoCampaign ALIAS (the short code, not the numeric id)
creativeNoCreative id from the click URL
group_byYesDimension per drill-down level (`user` = the workspace member owning the campaign; needs the "See statistics per team member" permission)
languageNo
pwa_tagsNoComma-separated tag ids — pwas carrying any of them
referrerNo
utm_termNoExact utm_term value from the click URL
date_fromNoYYYY-MM-DD (with period=custom)
date_modeNoDate attribution: 'conversion' (default) counts each conversion on the day its postback arrived; 'click' books it on the date of the click it belongs to
pwa_groupNoPwa group id
smartlinkNoSmartlink id
source_idNoSource id as passed by the ad network
offer_tagsNoComma-separated tag ids — offers carrying any of them
utm_mediumNoExact utm_medium value from the click URL
utm_sourceNoExact utm_source value from the click URL
ad_campaignNoThe ad network's own campaign id (external_campaign_id)
aff_networkNoAffiliate network id
offer_groupNoOffer group id
source_tagsNoComma-separated tag ids — sources carrying any of them
unique_onlyNoCount unique clicks only
utm_contentNoExact utm_content value from the click URL
exclude_botsNoExclude bot traffic (bots are counted by default)
landing_tagsNoComma-separated tag ids — landings carrying any of them
source_groupNoSource group id
utm_campaignNoExact utm_campaign value from the click URL
campaign_tagsNoComma-separated tag ids — campaigns carrying any of them
landing_groupNoLanding group id
campaign_groupNoCampaign group id
smartlink_tagsNoComma-separated tag ids — smartlinks carrying any of them
connection_typeNo
smartlink_groupNoSmartlink group id

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial context: row shape, level/path drill-down semantics, compare previous-period matching, prev null meaning, and prev_totals/prev_range. This is especially valuable because no output schema exists.

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?

The description is front-loaded with core drill-down behavior and compare semantics, and it contains no filler. The long parenthetical about date matching is useful but makes the paragraph somewhat dense and run-on.

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 62-parameter report tool with no output schema, the description covers the essential return structure and comparison behavior. It leaves metric definitions, sorting/limits, and some filter semantics to the schema, which is acceptable given 89% coverage.

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 high at 89%, so the baseline is 3. The description adds meaning for group_by, level, path, and compare beyond the schema, especially the 0-based level and parent-key path relationship.

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 description states a specific resource and operation: a drill-down report grouped by one or more dimensions, with rows at a chosen level and parent path keys. It distinguishes itself from generic statistics by emphasizing drill-down and comparison, though it does not name a sibling alternative.

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 a clear use case ('what changed / what dropped vs last week') and explains compare=true. It does not state when to prefer get_statistics or other report tools, nor any exclusions.

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.

Resources