Apple's Campaign Management API stops working on January 26, 2027. Its replacement, the Apple Ads Platform API, launched in August 2026, and nearly every Apple Ads MCP server we could find predates it.
We ran into this while looking for a server that could pull our Apple Ads reports and change keyword bids. The tidiest listing on npm was apple-ads-mcp: 54 tools, a few ready-made workflow prompts, MIT license. Then we opened its client and found https://api.searchads.apple.com/api/v5 hard-coded. That endpoint answers today and won't in January.
So we compared everything we could find, built our own, and wrote down where ours is still weaker than the alternatives. The short version: it wraps every one of the 99 operations in Apple's official Node SDK, it registers 102 tools, and loading all of them costs real context.
What changed at Apple
Apple is retiring v5 on January 26, 2027, according to PPC Land's coverage of the Platform API launch. The replacement is a single REST interface for App Store and Apple Maps campaigns, covering campaigns, ad groups, keywords, creatives, budgets, reporting, impression share, recommendations and a change history. Apple also published a Node client, @apple/apple-ads-platform, which handles the OAuth exchange for you: an ES256-signed client secret traded for a one-hour access token.
That client is the reason we built anything. A server on top of it doesn't have to reimplement auth or guess at request shapes.
What was already out there
Here's what we found, as of October 10, 2026:
| Server | API | Tools | Writes |
|---|---|---|---|
apple-ads-mcp (npm 1.0.3, March 2026) |
v5 | 54 | yes |
apple-search-ads-mcp (a second repo, AppVisionOS, lists the same surface) |
v5 | 74 | yes |
aapl-ads-mcp |
v5 | 8 or 9 | no |
Newticus/apple-ads-mcp |
Platform v1 | 5 | separate tool, removable |
zelentsov-dev/apple-ads-mcp |
Platform v1 | 19 listed | off by default, gated |
| ours | Platform v1 | 102 | yes, with a read-only switch |
The v5 servers are fine for reporting this quarter. None of them touches the new API, and each needs a rewrite before January.
The two aimed at v1 are more interesting. Newticus's server exposes five tools: a docs search, a docs reader, an account check, one read tool and one write tool. The catalog behind the docs search comes from crawling Apple's developer pages, and the auth code is hand-rolled. Its README admits it hasn't run against a real ad account yet, and the repo had a single commit when we looked. That's a young project, not a bad design. Five tools means almost no context overhead, and splitting reads from writes lets a client auto-approve one and prompt for the other. If context cost is your main worry, it's a better trade than ours.
The Go server from zelentsov-dev is the careful one. It starts read-only; writes need a flag, a preview and a single-use receipt, and deletes need more gates still. You can install it with Homebrew or a container image. If you're handing an agent a live ad budget and feeling nervous about it, start there.
Why we built our own
Two reasons, and neither is that the others are bad.
We wanted an agent that can change things. Adjusting a keyword bid, applying a budget recommendation, pausing a campaign, dismissing a suggestion: those are the jobs, and a five-tool surface asks the model to assemble each raw request from documentation on every call. We preferred one typed tool per operation, with a schema the model can read before it acts.
And we wanted Apple's SDK doing the plumbing. When the SDK adds an operation next quarter, we'd like to find out from a failing test rather than from a user.
What's in it
Every SDK operation became exactly one tool, named apple_ads_ plus a verb and a noun: apple_ads_create_campaign, apple_ads_query_keywords, apple_ads_apply_daily_budget_recommendations, apple_ads_report_apps_campaigns, apple_ads_query_change_history. The 99 operations break down as 63 reads and 36 writes (12 creates, 11 updates, 9 deletes and 4 actions). Three more tools are ours: a raw request escape hatch, an operations lister, and a status check that can verify your credentials against Apple.
They fall into 22 groups. Some map to what you'd expect: campaigns, ad groups, ads, creatives, keywords, negative keywords, bulk keyword operations, budget orders. Others are easier to miss. There are separate report families for App Store campaigns and for Apple Maps brands, impression share and search term popularity queries, daily budget and target CPA recommendations you can query, apply or dismiss, keyword suggestions, and a change history that returns field-level detail.
A generator reads the installed SDK and fails if any operation lacks a tool, or if a tool points at an operation that no longer exists. A test asserts the same thing. All 99 operations also run against a local mock of Apple's API in the suite, which has 197 tests in total.
Each tool carries MCP annotations (read-only, destructive, idempotent), so a client that cares can prompt before anything that deletes. Two environment variables shape the surface. APPLE_ADS_READ_ONLY=true removes every write tool, and APPLE_ADS_ENABLED_GROUPS=campaigns,reports_apps trims the list to what you name.
Apple scopes most Platform API calls to an ad account through an X-AP-Context header. Every tool takes an optional adAccountId, falls back to APPLE_ADS_AD_ACCOUNT_ID, and when neither is set it checks which accounts your credentials can reach and uses the only one if there's exactly one.
Where it's weaker
The listing for all 102 tools weighs about 214 KB, which we estimate at roughly 55k tokens. That's a lot to spend before you've asked anything. The group filter exists for that reason, and a client that loads tools on demand copes better than one that doesn't.
We also found a dependency problem while testing a fresh npx install under npm 12: npm audit flagged three high-severity advisories, all traced to axios. Apple's SDK pins axios to exactly 1.18.1, and an overrides entry in our package.json only applies when you install from our repo, not when you install our package. A skim suggests several of the advisories concern adapters and proxy options this server never configures, but we haven't audited each one. Fixing it properly means bundling the dependency or waiting for Apple to bump it.
Smaller things. Writes are on by default, because that was the point. It needs Node 20 or newer and speaks stdio only. Apple lists bulk delete endpoints as coming soon, so there are none yet; the escape hatch will reach them when they exist. And the test suite runs against a mock. As we write this, we haven't pointed the server at a live ad account, so expect rough edges in the first releases.
Try it
You need an API user and a key pair, which Apple's OAuth guide walks through. Then there's nothing to clone or build; the client launches it with npx:
{
"mcpServers": {
"apple-ads": {
"command": "npx",
"args": ["-y", "@nerdsnipe-inc/apple-ads-mcp-server"],
"env": {
"APPLE_ADS_CLIENT_ID": "SEARCHADS.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"APPLE_ADS_TEAM_ID": "SEARCHADS.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"APPLE_ADS_KEY_ID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"APPLE_ADS_PRIVATE_KEY_PATH": "/Users/you/.appleads/private_keys/private-key.pem"
}
}
}
}
Run npx -y @nerdsnipe-inc/apple-ads-mcp-server --list-tools first if you'd like to see what you're getting without credentials.
The code is available Apple Ads MCP Server on GitHub and the package is on npm, both MIT.
Read more on the latest version of our Apple Ads MCP Server on my website.
If something breaks against a real account, an issue with the failing call is the most useful thing you can send.
Top comments (0)