Skip to main content
Glama

advertiser_resources_list

Read-onlyIdempotent

List App Store content-provider delegations available to a specific Apple Ads profile and ad account ID for auditing advertiser resources.

Instructions

List App Store content-provider delegations available to a profile.

Input Schema

NameRequiredDescriptionDefault
profileYeslocal Apple Ads profile name
adAccountIdYesApple Ads ad account ID

Output Schema

NameRequiredDescriptionDefault
dataNopayload
errorNo
summaryYes
rateLimitNo
paginationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety and idempotency profile is covered. The description adds only the scoping note that results are bounded by a profile; it says nothing about whether the listing hits a live Apple Ads endpoint, whether an empty result is normal, or what the delegations represent.

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?

A single front-loaded sentence with no filler or repetition. It is efficiently sized, though it is terse to the point of leaving the domain term 'content-provider delegations' unexplained.

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

Completeness3/5

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

With an output schema present and both parameters fully documented in the schema, the description needn't explain return values, so the essentials are covered. However, for a tool whose subject matter (content-provider delegations) is obscure, one clause on what it returns or when it is empty would make the definition fully self-sufficient.

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 coverage is 100% for both parameters, so the baseline of 3 applies. The description reinforces that 'profile' scopes the result set but adds no semantics for adAccountId or for how the two required parameters interact.

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 names a specific verb (List) and a specific resource (App Store content-provider delegations) scoped to a profile, which is enough to distinguish it from query-style siblings like product_pages_query or apps_search. It stops short of naming a sibling it should be preferred over.

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 call this tool, what prerequisite state it assumes, or which sibling to use instead for related advertiser/resource lookups. The only guidance is the implicit 'list available to a profile', leaving the agent to infer applicability.

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