ShortsIntel

Get a tracker's stored Ads

get_tracker_ads

Read-onlyIdempotent

Use when you need every Ad stored for a tracked Advertiser, stopped and removed Ads included. Not for an untracked Advertiser: search_ads. Not for what changed: get_changes. Price: Free. Advertiser Trackers only, paused too. Each Ad has a compact analysis or null; a filter on hook_type, angle, offer_type or format skips Ads with none. include=intelligence adds the full payload. next_cursor pages.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tracker_id": "<tracker_id>"
    },
    "name": "get_tracker_ads"
  }
}

Input Schema

Name	Required	Description
`angle`	No
`limit`	No
`cursor`	No
`format`	No
`status`	No	inactive includes removed Ads; only all keeps unknown state.
`country`	No	ISO-2 code.
`include`	No	Adds each Ad's full analysis.
`hook_type`	No	Image Ads have none, so they never match.
`media_type`	No
`offer_type`	No	NONE: no offer found.
`tracker_id`	Yes	The Advertiser Tracker's id.
`started_after`	No	ISO date, inclusive.
`stopped_after`	No	ISO date, inclusive.
`started_before`	No	ISO date, exclusive.
`stopped_before`	No	ISO date, exclusive.
`min_days_running`	No

Output Schema

Name	Required	Description	Default
`items`	No
`next_cursor`	No	Pass back as `cursor`.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover the read-only/idempotent/closed-world profile, and the description adds genuine behavior beyond them: cost ("Price: Free"), that paused/stopped/removed ads are still returned, that each Ad carries a compact analysis or null, that analysis-based filters silently skip Ads with null analysis, that include=intelligence expands the payload, and that paging uses a cursor. The silent-skip rule is exactly the kind of non-obvious 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?

Front-loaded with the use case, then exclusions, then behavioral notes; nearly every clause carries information and the telegraphic style keeps it short. A few fragments ("Advertiser Trackers only, paused too") trade grammar for density, and the cursor naming slip costs a bit of polish, but there is no filler.

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 16-parameter, filter-heavy list tool this covers the essentials: scope, prerequisite, exclusion semantics, analysis presence/absence, payload expansion, and pagination. An output schema exists so return values need not be described. The remaining gaps (default limit, media_type, date-range and min_days_running semantics) are all documented in the schema itself.

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 63%, and the description compensates well for the highest-risk parameters by explaining that hook_type/angle/offer_type/format filters exclude Ads with no analysis and that include=intelligence changes payload size. It leaves media_type, limit, and the four date-range parameters entirely to the schema, and "next_cursor pages" uses a different name than the actual input parameter "cursor", a small avoidable ambiguity.

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?

"Every Ad stored for a tracked Advertiser, stopped and removed Ads included" gives a specific verb (retrieve) plus resource (stored Ads on a tracker) and states the inclusion scope up front. It also names the two nearest siblings it is not (search_ads for untracked advertisers, get_changes for diffs), so the agent can discriminate without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use (need every stored Ad for a tracked advertiser, including stopped/removed) and explicit when-not-to-use with the alternative named for each case: search_ads for untracked advertisers, get_changes for what changed. Prerequisite (advertiser must be tracked) is stated as "Advertiser Trackers only".

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

All ShortsIntel 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?