Gloriads — Amazon Ads

Performance over time

get_timeline

Read-onlyIdempotent

Get the same metrics as get_summary day by day or month by month (the dashboard's chart). granularity "auto" picks days for up to 92 days and months beyond; "day" is refused on longer periods. Only days or months that have data are listed. With compare, the compared period's points too, at the same granularity. Amounts are in USD (Amazon converts each marketplace). meta.data_last_date says up to which day the figures go.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_timeline"
  }
}

Input Schema

Name	Required	Description
`range`	No	Relative period, resolved in `timezone`, e.g. "last_30_days", "this_month", "last_year", or "all_time" (from the oldest data held, through today). Ranges cover complete days like the dashboard: "last_30_days" is the 30 days ending yesterday, "this_month" stops at yesterday, "today" is today. Defaults to "last_30_days". Do not combine with start_date/end_date.
`compare`	No	"previous_period" (the same number of days just before; "this_month" against the same days of last month) or "same_period_last_year" (the same dates a year earlier). Adds the compared period's figures and how each changed (the dashboard's "+18 %"). Both periods then end yesterday. Absent: no comparison.
`end_date`	No	Last day, inclusive (YYYY-MM-DD). A date after today is treated as today.
`timezone`	No	IANA time zone deciding which day "today" is for `range`, e.g. "Europe/Paris". Defaults to UTC.
`start_date`	No	First day, inclusive (YYYY-MM-DD). Send together with end_date.
`ad_products`	No	Keep only these ad types: SPONSORED_BRANDS, SPONSORED_DISPLAY, SPONSORED_PRODUCTS. Absent: all of them.
`granularity`	No	"auto" (default), "day" or "month".
`marketplaces`	No	Keep only these marketplaces, by country code: US, CA, MX, BR, UK, DE, FR, ES, IT, NL, SE, PL, BE, TR, AE, SA, EG, IN, ZA, JP, AU, SG. Absent: every marketplace.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare this a read-only, idempotent, non-destructive operation, and the description layers on real behavioral detail: only buckets with data are listed (sparse series, not zero-filled), compared points appear at the same granularity, amounts are USD-converted per marketplace, and `meta.data_last_date` bounds the figures. These are non-obvious traits an agent would otherwise have to discover by calling.

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?

Front-loaded with the core identity and the get_summary relationship, then the granularity rules, then output-shape notes. Dense but every clause carries information; the telegraphic style (semicolon-chained clauses) costs a little readability but nothing is redundant.

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 8 optional parameters and no output schema, the description does the necessary work: it characterizes the returned series (sparse, USD, compared points) and the recency field. The metric set itself is delegated to get_summary rather than enumerated, which is reasonable but leaves a small gap for an agent that has not read that 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 genuine meaning the schema does not: the "auto" heuristic threshold of 92 days, the fact that "day" is rejected past that, and that compare forces both periods to end yesterday. It leaves date-range precedence to the schema rather than restating it.

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?

"Get the same metrics as get_summary day by day or month by month (the dashboard's chart)" names a specific verb and resource and explicitly distinguishes itself from the sibling get_summary by time granularity. An agent can route between the aggregate and the time-series tool without opening either schema.

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?

The description gives concrete selection rules for granularity: "auto" picks days up to 92 days and months beyond, while "day" is refused on longer periods. It also explains when compare adds a second series. It stops short of an explicit "use get_summary instead when you only need a total," relying on the reader to infer the split from the opening sentence.

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

All Gloriads — Amazon Ads tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?