MCP Apple Ads

Apple Ads: Get Campaign

apple_ads_get_campaign

Read-only

Retrieve a single campaign's full targeting, budget, and bid strategy before updating it, so changes are applied to the actual configured settings.

Instructions

Get one campaign in full, including its targeting, budget and bid strategy. Use this before updating one, so the change is made against what is actually configured.

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": {
      "campaignId": "<campaignId>"
    },
    "name": "apple_ads_get_campaign"
  }
}

Input Schema

Name	Required	Description
`savePath`	No	Absolute path to also write this result to, as pretty-printed JSON. Use it rather than copying values out of the response into a file by hand. Parent directories are created.
`campaignId`	Yes	The numeric id of the entity, as returned by the matching list tool.
`adAccountId`	No	The ad account to act on. Omit it when you have exactly one or APPLE_ADS_AD_ACCOUNT_ID is set — it is resolved automatically. List them with apple_ads_list_accounts.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A3.8/5.0

Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context beyond that. It contributes the read-before-write workflow rationale and a partial account of returned content, but says nothing further about response shape, error behavior, or account resolution beyond what the schema states.

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

Conciseness5/5

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

Two sentences, no filler. The capability statement comes first and the workflow guidance second, so the agent gets purpose before procedure.

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 single-entity read with annotations covering safety and a fully documented three-parameter schema, the definition covers purpose and usage well. The only gap is that no output schema exists, so the returned structure is only sketched by naming target, budget, and bid strategy rather than described.

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 description coverage is 100%, so campaignId, adAccountId, and savePath are already fully documented in structured fields. The description adds no parameter-level meaning, which is acceptable given the schema does the heavy lifting, but no extra value is provided.

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 gives a specific verb and resource ("Get one campaign") plus the scope of what comes back ("targeting, budget and bid strategy"), which separates it from the list-style siblings such as apple_ads_list_campaigns. It stops short of naming a sibling explicitly, so it is clear but not fully differentiated.

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 states a concrete when-to-use condition: call this before an update so the change is made against actual configuration. There is no explicit when-not guidance or named alternative for enumeration, but the context it gives is actionable.

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