Included as a mobile marketing measurement surface whose official MCP can interrogate campaign and SKAN performance, OneLink routing, app attribution settings, audience delivery health, cost and ad-revenue integrations, and account roles without issuing platform mutations.
Concrete capability record
A field-by-field summary of what the reviewed first-party references actually support. Publisher update dates and BYO-UI review dates are shown separately below.
Apps and app configuration; media sources, campaigns, channels, countries, installs, retention, revenue, LTV, ROAS and SKAN metrics; OneLink templates and links; audiences, partners, split tests and upload status; cost and ad-revenue integrations; users, roles, app access, and documentation resources.
Analyze aggregated campaign and SKAN performance; compare retention and ROI; audit OneLink parameters and routing; inspect attribution windows, session timeouts, app status, audience ownership and delivery health, cost or ad-revenue integration status, and user-role assignments; retrieve AppsFlyer setup documentation.
AppsFlyer MCP is read and query only and does not take action in AppsFlyer. The wider developer platform has separate write APIs, including app management and creative upload or publishing, but those API mutations are not MCP capabilities and have their own token, entitlement, and asynchronous-processing contracts.
Interactive clients connect through browser-based AppsFlyer authentication. Third-party or self-hosted systems use an account-level MCP bearer token from Security Center; that token inherits the permissions of the admin who created it. MCP otherwise applies existing app and data permissions with no separate MCP permission layer.
Record the connected account, user or token principal, app scope, requested date and geography, attribution and SKAN context, and whether data is being passed to an external AI provider. For bearer-token automation, inventory the creating admin and each separate account connection; revoke and replace tokens when access changes.
The MCP is beta and AppsFlyer validates reliability only for its listed supported use cases. It connects to one account at a time; multiple accounts require separate bearer-token connections. Only enabled client platforms work by default, with other platforms requiring AppsFlyer approval. The MCP is read-only, and the selected AI tool may store or process returned data under its own terms.
Agent access
Support: Official MCP server
Read scope: Read aggregated performance and SKAN metrics; app configuration and attribution settings; OneLink templates and links; audiences, connections, tests, and upload health; cost and ad-revenue integration health; account users and roles; and AppsFlyer documentation, subject to the principal's existing app and data access.
Write scope: No AppsFlyer platform write scope: the beta MCP is explicitly read and query only. Its feedback tool can send product feedback to the MCP team, but it does not authorize audience, OneLink, app, campaign, user, or integration changes.
Authentication: Browser-capable clients use the AppsFlyer sign-in flow at `https://mcp.appsflyer.com/auth/mcp`. Automation and self-hosted agents send an account-level MCP token as a bearer credential to the same HTTP endpoint; browser OAuth selects one primary account per connection.
Approval boundary: Because the MCP itself is read-only, approval focuses on connection and disclosure: an administrator should approve each account, token principal, client platform, and category of marketing or user-role data exposed to the selected AI provider. Any recommended operational change must move to the relevant AppsFlyer or downstream system for separate review.
Confirm the current tool catalog, plan, region, scopes, rate limits, terms, and write behavior before implementation.
Editorial assessment
A comparative architecture lens—not a quality score, market ranking, or buying recommendation. Scale: 1–5.
Proposed customer-shaped experiences
The output could be an export, report, graph, artifact, application, agent, workflow, or downstream feed. These proposals are derived from documented access—not claims that AppsFlyer ships them.
Evidence and dates
“Publisher updated” is shown only when the page exposes an update date. “BYO-UI reviewed” records when this research checked the reference. A missing publisher date is reported as missing—not replaced with the review date.
AppsFlyer materials confirm an official MCP for unified marketing data, attribution, analytics, audiences, and OneLink-related workflows.
Targeted first-party MCP and platform-access review
First-party API reference.
Inventory source: structurally normalized; content was not individually reopened in this pass.
First-party developer guidance.
Inventory source: structurally normalized; content was not individually reopened in this pass.
Product overview.
Inventory source: structurally normalized; content was not individually reopened in this pass.
Tied to cited first-party evidence reviewed for this profile.
Official links recorded for deeper research but not necessarily reopened endpoint by endpoint.
System role, maturity interpretation, and architectural boundary.
Interface patterns and compositions—not vendor product claims.
