The Growth Stack an Agent Can Actually Drive

The read-versus-write distinction decides what is worth installing, and most of this category is read-only.

"Writes" means the server can mutate production state — create a campaign, flip a flag, send a message — not just fetch it.

Two patterns fall out immediately.

Ads and messaging write. Attribution does not. Every MMP here is read-only. That is a design choice, not an oversight — an MMP is the system of record for what happened, and vendors are not letting a language model mutate it. Plan for the agent to read attribution and write everywhere else.

The best write stories are in experimentation and paywalls, not in ads. PostHog, Amplitude, Superwall and Statsig will genuinely take "run a 50/50 test on the annual price point" and set it up. That is where the leverage is. The broader MCP picture is in the Claude MCP marketing stack.

Before installing anything that spends money, settle who holds the credentials and what they can authorise.

Nearly every server here bills you per call, on a meter you are not used to watching. PostHog's AI tools incur PostHog AI spend. Mixpanel caps you at 600 requests per hour per user, AppsFlyer at 20 analytics requests per minute. AppFollow charges API credits for every method it exposes.

An agent exploring a question does not batch. A single "why did CPI go up last week" investigation can be twenty calls before it says anything useful. Three habits stop that becoming a problem:

• Scope the server at install time. Firebase's MCP supports --only to restrict which tool groups load. Every tool you load costs context whether or not you call it.
• Put the date range in the prompt. Left alone the agent pulls three years, because the API allows three years.
• Read-only by default, write on purpose. Customer.io's separated read/write/delete tools are the model.

There is also a context budget, separate from the money: every server you connect loads its tool definitions into the session. Same constraint as in the skills, plugins and MCP directory, and it bites hardest here because growth vendors ship the largest tool counts in the ecosystem.

Ads platforms are the clearest case of read access being useful and write access being rare.

Meta: the one that actually writes

The Meta Ads MCP was announced in July 2026. It is remote and OAuth-based:

claude mcp add --transport http --client-id <META_APP_ID> meta-ads https://mcp.facebook.com/ads

Seven tool categories: reporting, campaign/adset/ad creation and editing, catalogs, signals and datasets, Help Center search, activity logs, and — the interesting one — A/B tests and conversion lift studies. Requested scopes include ads_mcp_management, ads_read and ads_management, which tells you plainly it is a write surface. Lift studies are the measurement most app marketers know they should run and do not, because setup is fiddly. That friction is what an agent removes.

One caveat before you rely on it for user acquisition: App Promotion campaign types are not explicitly called out in the documentation. Everything about the server suggests it handles them, but "suggests" is not "documents". If your whole UA spend is App Install campaigns, create one by hand on a small budget before building a workflow on it.

For bulk and CI work the Meta Ads CLI is better. It is officially built and explicitly designed for agents: meta ads <resource> <action>, full CRUD, insights with breakdowns, --no-input and --force for non-interactive runs, JSON output, consistent exit codes. An MCP call is a conversation; a CLI with predictable exit codes is a pipeline.

Here is the honest problem: the install command is not published on the official overview page, and every meta-ads-cli on GitHub is an unrelated third-party project — none of them is Meta's. Do not install something with that name off GitHub and assume it is official. Get the instructions from your Meta representative or the Marketing API developer docs, and verify the publisher before you authenticate it against an account with budget on it.

Google Ads: read-only, three tools, and a lot of wrong content about it

This is the correction that matters most here, because a lot of secondary writing gets it backwards. The official server is open source and runs over stdio:

pipx run --spec git+https://github.com/googleads/google-ads-mcp.git google-ads-mcp

It has three tools: list_accessible_customers, search (which runs a GAQL query), and get_resource_metadata. That is the entire surface. There are no mutation tools. It cannot create a campaign, adjust a bid, pause an ad group or upload an asset. It is a GAQL client with a customer list attached.

You will find posts and vendor content implying the Google Ads MCP manages campaigns. That is wrong, and it is the kind of wrong that costs you a day. If you want an agent to touch App campaigns — creating them, uploading creative assets, setting tCPI or tROAS targets — you call the Google Ads API directly, with your own credentials and wrapper.

TikTok: pick the smaller server

TikTok for Business ships two remote endpoints with zero-code auth:

• Flat, roughly 400 tools: https://business-api.tiktok.com/open_mcp/tt-ads-mcp-flat
• Layered, roughly 40 core tools: https://business-api.tiktok.com/open_mcp/tt-ads-mcp-layer

Both cover campaign creation, targeting, real-time bid adjustment, reporting and creative operations. TikTok's own guidance recommends Flat for Claude. Use Layered anyway.

Four hundred tool definitions is not a capability, it is a context tax you pay on every turn, including turns that have nothing to do with TikTok. It also degrades selection quality — with 400 near-neighbours the model picks the wrong tool more often, and the wrong tool in an ad account means an unintended write. Forty is already at the upper end of comfortable. If Layered genuinely blocks you, reconsider then.

Apple Search Ads: no official MCP, and be careful what you install

There is no official Apple Search Ads MCP. What exists is the Campaign Management API v5, authenticated with OAuth2 and a JWT you sign yourself. It is complete — campaigns, ad groups, keywords, negative keywords, custom product page creatives, ad-level reporting — and usable from an agent through a thin wrapper you write.

Community MCP servers do exist, and here is the thing about them: ASA authentication requires a private signing key. A server offering to handle Apple Search Ads for you is asking for that key, and that key signs requests against an account that spends money. That trust requirement is categorically different from an OAuth flow you can revoke from a settings page, and several App Store Connect and Apple Search Ads MCPs found only on aggregator listings request exactly this. Read the source before installing; if you cannot read the source, do not install it. This is one of the few places in this series where I would tell you to write the wrapper yourself. Same reasoning as mobile security for people who don't do security.

The primary reference for this is Google Ads MCP server (official, open source) — worth reading in full rather than taking a summary of it, because the details here change more often than the shape of the advice does.

Attribution servers are read-only with meaningful limits, and knowing them prevents a false sense of coverage.

All four MMP servers are read-only. What separates them is documentation quality and how much data you can actually extract.

AppsFlyer is the best documented, and it is in beta:

claude mcp add-json appsflyer '{"type":"http","url":"https://mcp.appsflyer.com/auth/mcp","headers":{"Authorization":"Bearer YOUR_TOKEN"}}'

It covers dashboard analytics, incrementality experiments, SKAN performance, OneLink, audiences, and cost and ad-revenue integrations. The limits are specific, and you will hit them:

• Analytics: 20 requests per minute, 10 apps per request, 4 groupings, 3-year window
• SKAN: capped at 10,000 rows, 90 days, and a single iOS app per request

That SKAN cap shapes your prompts. Across three apps you cannot ask one question that spans them — you are looping, and each loop spends against a 20-per-minute budget.

Adjust is gated twice. The endpoint is npx mcp-remote https://automate.adjust.com/ai-assistant-service/mcp/, but you need Growth Copilot enabled and Early Access, which means contacting sales. The data is aggregated only — no cohort or device level. Fine for trend questions, useless for the "which cohort churned" investigations that make attribution data worth having.

Singular is OAuth at https://mcp.singular.net/mcp-server/mcp, giving aggregate tracker data, network cost and main-report metrics, with a 100,000 character response cap for Claude. SKAN support is listed as coming soon. Narrow the grouping before you ask, or the cap truncates you.

Branch is at https://ai.branch.io/mcp, a closed, invite-only beta where access is granted per individual user, not per organisation. It reads clicks, installs, opens, reinstalls, revenue events and impressions. In beta it has no link creation and no multi-app support — which removes the one thing most people would want an agent doing with Branch: generating campaign links at scale.

SKAdNetwork is not dead, and saying otherwise dates your writing

You will read that SKAdNetwork is deprecated. It is not. Apple maintains an explicit AdAttributionKit-to-SKAdNetwork interoperability document. Anyone declaring SKAN dead in 2026 is ahead of Apple. Plan for both frameworks running side by side.

The AdAttributionKit specifics your agent needs in context:

• Requires iOS or macCatalyst 17.4 or later
• Three conversion windows
• The winning network and the developer get postbacks with did-win: true
• Up to five runner-up networks get one non-winning postback — for installs only. There are no runner-up postbacks for re-engagements
• Apple applies a postback data tier for crowd anonymity, so granularity depends on volume
• It does not require ATT consent

Newer additions include conversion tags, which identify which postback belongs to which campaign when conversion windows overlap, plus documented rules for configuring attribution for your app.

None of this is agent-drivable — it is client-side framework work plus network coordination. But it is what your agent needs in order to interpret the SKAN reports it pulls from AppsFlyer, and models trained a year ago will confidently tell you SKAN is deprecated. Put the correction in your project instructions.

The documentation worth reading before you act on this is Apple Search Ads Campaign Management API v5 — worth reading in full rather than taking a summary of it, because the details here change more often than the shape of the advice does.

PostHog has the strongest read-plus-write experimentation story here. Install with npx @posthog/wizard mcp add, pointing at https://mcp.posthog.com/mcp. It runs HogQL, reads error tracking, manages CDP destinations and governed metrics, and creates and manages feature flags and experiments from a prompt — "put the new onboarding behind a flag at 10% and set up an experiment on day-7 retention" is a thing you can say. Two conditions: AI tool usage incurs PostHog AI spend, and your organisation must enable AI data processing first.

Amplitude is comparable, at https://mcp.amplitude.com/mcp with an EU variant, over OAuth. It reads and writes charts, dashboards, experiments, cohorts and feature flags, plus taxonomy and tracking plans. It is explicitly not for event ingestion.

Mixpanel has the biggest surface: 60+ tools at https://mcp.mixpanel.com/mcp covering queries, reports, dashboards, cohorts, metrics and session replays, with experiments and flags in beta. Two gates: an org admin must enable MCP before it works for anyone, and you get 600 requests per hour per user.

Statsig covers experiments, gates, dynamic configs, layers, segments, metrics, audit logs and autotunes, with writes requiring API permissions, and their docs include a Claude Code guide. The use case they highlight is the one I would reach for: bulk stale-flag cleanup across a codebase — read the flag list from the API, find every reference in the repo, delete the dead branch. Exactly the shape of work an agent is good at and a human puts off for two years.

Firebase is the gap. Install with claude plugin install firebase@firebase. The Remote Config tools are remoteconfig_get_template and remoteconfig_update_template. Get the template, update the template. That is the whole Remote Config surface, and it is enough to change values.

Firebase A/B Testing is entirely absent from the MCP. No experiment creation, no variant assignment, no results reading. If your experimentation platform is Firebase A/B Testing, your agent cannot drive it — you run experiments in the console, or move experimentation somewhere that exposes it. Use --only to scope the Firebase server, because the unscoped tool list is very large.

This is documented directly in AdAttributionKit documentation — worth reading in full rather than taking a summary of it, because the details here change more often than the shape of the advice does.

RevenueCat ships an AI toolkit: claude plugins marketplace add RevenueCat/ai-toolkit, then install. It handles project, app, product and offering CRUD, plus chart and experiment analysis. The wrinkle: paywall create and update route through "Rico", not through general MCP tools. "Read my paywall config and change the trial length" is not the single tool call the rest of the CRUD surface leads you to expect.

Superwall has the most complete paywall-agent story going:

claude mcp add superwall --transport http https://superwall-mcp.superwall.com/mcp

Projects, paywalls, campaigns, products, apps, store product linking, chart and cohort data, webhooks, and A/B tests and holdout groups. The limit: it does not drive the live paywall editor canvas — that needs a separate Editor MCP. The agent can create a paywall, assign it to a campaign and test it, but the visual arrangement is still a human in the editor.

Adapty has no MCP at all, and their own documentation says so plainly, which I appreciate more than a vague roadmap page. What they point you at is still a reasonable agent story: the Adapty Developer CLI, the Export Analytics API, SDK skills, and a .md docs trick where you append .md to any documentation URL to get clean markdown, plus an llms.txt. Steal that trick regardless of whether you use Adapty — it is the problem from fetchable HIG and Material docs, solved by a vendor for once.

For the authoritative version, see TikTok for Business API — worth reading in full rather than taking a summary of it, because the details here change more often than the shape of the advice does.

OneSignal connects at https://api.onesignal.com/mcp/oauth through browser OAuth, no key handling. 34 tools across 9 categories, covering apps, messaging, users, templates, segments, Live Activities, exports and analytics. Sending asks for confirmation, the right default for a tool that can push to your whole user base. It cannot run as local stdio — remote only.

Braze is at https://mcp.braze.com/mcp (US) or https://mcp.braze.eu/mcp (EU), OAuth only. Read and write: campaign analytics, Canvas management, message creation, user updates. Check this first: customers with IP allowlisting enabled cannot use it. If your security team turned that on, the conversation ends there.

Customer.io is at https://mcp.customer.io/mcp with an EU variant, plus a plugin in the Claude Code marketplace. It has the best security design of anything in this post. Instead of one monolithic surface it separates cio_read_api, cio_write_api and cio_delete_api into distinct tools you grant independently — so "read everything, write nothing" is a configuration rather than a hope. It also ships cio_prime and cio_schema for orientation, cio_skills_list and cio_skills_read, and returns 422 on unknown body fields, catching agent typos instead of silently accepting them. If you care what your agent can do by accident, this is the reference implementation.

Iterable is npx @iterable/mcp setup, with --advanced to enable writes. It defaults to read-only with no PII tools, the correct default for a marketing database, and is local stdio only — Claude Code, not claude.ai. The vendor warns the beta may change or be discontinued. Treat it as a beta, not infrastructure.

The source that settles this is AppsFlyer developer documentation — worth reading in full rather than taking a summary of it, because the details here change more often than the shape of the advice does.

A short stack covers most of the value without spending your context on tools you will not use.

You cannot run all of this at once. Pick by what you are doing this week.

Running paid UA: Meta Ads for the write path, Google Ads for read-only reporting, AppsFlyer for attribution. Skip TikTok unless you are spending there; use Layered when you do.

Optimising conversion: PostHog or Amplitude for experiments and flags, plus Superwall or RevenueCat for the paywall. The highest ratio of agent capability to human effort here.

Cleaning up: Statsig alone, for the stale-flag sweep. One server, one job, then disconnect.

Grant read-only first in every case, watch what the agent actually calls for a week, then widen. With ad accounts the failure mode is measured in money rather than a failed build.

None of it decides what to say, who to say it to, or whether the economics work.

The servers write campaigns. They do not decide what to spend. They configure experiments. They do not tell you whether the hypothesis is worth testing. They pull attribution, without knowing your iOS numbers are soft because a postback data tier collapsed your granularity — unless you told them so.

The mechanical work got cheap; the judgment did not move. What changed is that the cost of running the measurement you always meant to run has dropped to roughly the cost of asking for it. That is worth restructuring your week around, even if it does not restructure your strategy.

Start with the reads. Add one write scope at a time. Watch the credit meter. The economics this assumes are in the ROAS and CAC guide, and the build-side path is the mobile shipping pillar.