Meta Ads MCP: a hosted remote MCP server for running Facebook and Instagram campaigns from an AI assistant

The problem: Meta Ads operations need a developer app before an assistant can touch them

Running Meta advertising from a conversational assistant normally means clearing a setup barrier first. You register a Meta app, obtain a developer token, work through OAuth scopes for the ad account, and then host something that speaks the Model Context Protocol so Claude, ChatGPT, Perplexity or Cursor can call it. That is a reasonable afternoon for a platform engineer and a dead end for a media buyer. The README positions this project against exactly that barrier: it is available as a hosted remote MCP, with the claim of no developer token and no self-hosting required. The intended user is not the person who enjoys wiring OAuth callbacks. It is the marketer or growth operator who wants to say something like "which channel had the cheapest signups last week?" and get an answer grounded in live ad account data. The repository also ships a local installation path, which the README explicitly labels as being for technical users only. That split is the honest shape of the project: the hosted endpoint is the product, and the local path is the escape hatch.

How the hosted server works: one URL, one OAuth, one token across five platforms

The architecture is a remote MCP server reachable at https://meta-ads.mcp.pipeboard.co/. You paste that URL into an MCP-compatible client, and the client performs tool discovery through the standard tools/list call. Authentication happens once at pipeboard.co rather than per client, and the README states that all five Pipeboard servers share the same OAuth, the same tools/list discovery, the same write-confirmation safety model and the same Pipeboard API token. That last detail matters more than it reads. A single token means one credential to store in your client configuration, one rate-limit ceiling, and one place to revoke access if a client is compromised. It also means the blast radius of a leaked token is five ad platforms, not one. The safety model is described as explicit confirmation on every write, with new campaigns starting paused where the platform supports it. That is a sensible default for an agent that can move budget, and it is the kind of guardrail self-hosted servers leave to the operator to build. The README also notes the underlying hosted service is a badged Meta Business Partner and an approved Meta app, while the repository itself is described as an independent open-source project using Meta's public APIs.

The 42-tool surface: what an agent can actually do to a Meta ad account

The README enumerates the Meta node's coverage rather than listing individual tool names in the excerpt available. The stated scope is campaigns, ad sets, ads, creatives including dynamic creative testing, image upload, insights, interest, behavior, demographic and geo targeting, and page management. Read that list as three tiers of risk. Insights and targeting lookups are read-mostly and cheap to experiment with. Image upload and creative creation write assets into the account. Campaign, ad set and budget operations spend money. The write-confirmation model and the paused-by-default behavior for new campaigns are the two mechanisms that keep the third tier from being reckless, and both are described as consistent across all five servers. The 42-tool count is the smallest of the five platforms in the family, against 59 for Google Ads, 59 for TikTok Ads, 37 for Snap Ads and 33 for Reddit Ads, for a stated total above 230 tools. If your work is Meta-only, that comparison is noise. If your reporting spans channels, it is the reason the family exists.

Getting it running: the remote URL, the CLI, and the local install you probably do not need

The recommended path is the remote server. Point your MCP client at https://meta-ads.mcp.pipeboard.co/, complete the connection at pipeboard.co, and the client discovers the tool list. There is no developer token step and no server to run. If your agent is a coding agent or a script that prefers subprocess calls over JSON-RPC, the README points to the Pipeboard CLI as an alternative, installed with brew install pipeboard-co/tap/pipeboard, then export PIPEBOARD_API_TOKEN=<your-token>. The documented invocation shape is pipeboard meta-ads get-campaigns --account-id act_123, with sibling commands for the other platforms such as pipeboard google-ads execute-gaql-query --customer-id 1234567890 --query "..." and pipeboard tiktok-ads get-campaigns --advertiser-id 7605685552884596737. The README claims sub-50ms startup for the CLI and notes it avoids an MCP handshake per call. That is a claim from the documentation, not something verified here. The third path, local installation, is flagged in the README as being for technical users only, and the excerpt does not include its configuration keys. If you need the local path, read the Configuration and Local Installation sections of the README directly rather than assuming the remote URL applies.

The licence is the first thing to check, and the repository will not tell you

The repository metadata reports the licence as NOASSERTION. That is not a licence. It means the automated classifier could not match the repository's licence file to a known SPDX identifier, which in practice covers everything from a slightly modified standard licence to a custom or missing one. The README has a Licensing section, but the excerpt available here does not include its contents. Before you build anything on top of this, open that section and read it. The distinction that matters is between the code in the repository and the hosted service. Even a permissive code licence will not grant you rights to the Pipeboard service, the API token, or the ad account data flowing through it. Those are governed by whatever terms pipeboard.co presents at signup. Nothing here is legal advice, and a NOASSERTION result is the specific signal that you should get an answer from the maintainers rather than infer one.

Where it is the wrong tool: hosted means you inherit someone else's uptime and data path

The central trade-off is stated plainly in the project's own comparison: Meta's official connector is the safest single-platform option, and open-source self-hosted servers give you full control if you are willing to run them. This project sits between those. Choosing it means your ad account operations depend on a third-party endpoint at meta-ads.mcp.pipeboard.co, a third-party token, and a third-party service's availability. The README does not publish a status page, an SLA, or a data retention description in the excerpt available, and those are the questions a security reviewer will ask before an agency connects a client's ad account. There is a second, subtler failure mode. A hosted remote MCP server can change its tool list between sessions. The release history shows frequent version bumps, with 1.0.118 in mid-July 2026, 1.0.119 at the end of that month, and 1.0.120 in early August. Fast iteration on a remote endpoint is convenient and it also means the tool surface your agent was tuned against may shift without a corresponding change on your side. If your workflow depends on a specific tool's exact behavior, pin what you can and test after upgrades.

The alternative that actually differs: Meta's own connector, and self-hosted servers

The README names two alternatives, and they differ from this project in approach rather than degree. Meta's official MCP connector is first-party and hosted by Meta, which means the trust boundary is the platform owner itself and the scope is Meta only. If you run Facebook and Instagram ads and nothing else, and you want the shortest path to a supported integration, that is the comparison to make. Self-hosted open-source MCP servers take the opposite position: you run the process, you hold the tokens, you build the write guardrails, and you absorb the upgrade work. In exchange you get a code path you can audit end to end and no third-party dependency in the request chain. This project's distinguishing claim is breadth under one auth. The README argues that single-platform MCP comparisons miss the point and that the value is the network, not the node. That is a fair argument only if you actually operate more than one ad platform. For a Meta-only team, the network is dead weight and the extra surface is five platforms' worth of token risk for one platform's worth of use.

Maintenance cost and who should wait

The upgrade cost here is asymmetric, and that is the least discussed part of the hosted model. You do not patch the server; Pipeboard does, and the release cadence suggests they do it often. Your cost is re-validation: confirming that the tools your agent depends on still behave as expected after a version bump, and that the write-confirmation prompts still appear where you expect them. The CLI path shifts some of that cost, since a Go binary installed through Homebrew is something you upgrade on your own schedule. The local installation path shifts the most, because then you own tokens, upgrades and guardrails, which is exactly the position the README says the hosted service exists to spare you. Teams with a strict vendor review process should treat the NOASSERTION licence and the absent retention details as open items to close before connecting a client's ad account, not as footnotes. Teams that just want to query their own campaigns from Claude on a free plan have very little to lose by trying the remote URL first and deciding afterward whether the CLI or a self-hosted server fits better.

Editorial conclusion

Adopt this if you already live in an MCP client and want Meta campaign, creative and insights operations without registering a Meta developer app or running a server. Do not adopt it if you need guaranteed uptime, a fully auditable code path, or a licence you can read before you commit, since the repository carries NOASSERTION and the hosted endpoint is a third-party service. Before connecting an account, verify three things: that the free plan covers the tool calls you intend to make, what the hosted service retains from your ad account, and whether the Pipeboard CLI is a better fit than MCP if your agent runs as a subprocess rather than a JSON-RPC client.

Official sources

1. Issues
2. pipeboard-co/meta-ads-mcp on GitHub
3. Project website
4. README
5. Releases