# Meta Ads MCP: Running Facebook and Instagram Campaigns From Claude, ChatGPT or Cursor

> Pipeboard's Meta Ads MCP server exposes 42 Meta advertising tools over the Model Context Protocol as a hosted remote endpoint, so you connect an AI client instead of self-hosting. Here is how the remote setup works, where it stops, and what to check before you point it at a live ad account.

**pipeboard-co/meta-ads-mcp** — Meta Ads (Facebook/Instagram) MCP server for Claude, ChatGPT, Perplexity & Cursor — the Meta node of Pipeboard’s 5-platform family (+ Google, TikTok, Snap, Reddit). Hosted remote MCP, badged Meta Business Partner, free plan — no self-hosting required.

- Repository: https://github.com/pipeboard-co/meta-ads-mcp
- Website: https://pipeboard.co
- Stars: 1,284 · Forks: 278
- Language: Python
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/pipeboard-co-meta-ads-mcp

## What the Meta Ads MCP server actually solves

Meta's ad platform is operated through Ads Manager, a browser UI, and through the Marketing API, which requires an app, a developer token and a review process. Neither is convenient for an AI assistant that is already in your terminal or chat window. The Meta Ads MCP server fills that gap by exposing Meta advertising operations as Model Context Protocol tools, so an MCP client can call them the same way it calls a file reader or a shell.

The README lists 42 tools on the Meta node: campaigns, ad sets, ads, creatives including dynamic creative testing, image upload, insights, interest, behavior, demographic and geo targeting, and page management. That covers both sides of the job. Reading is the obvious use ("which campaign had the cheapest signups last week?"), but the server also writes: launch campaigns, upload creatives, update budgets. That write capability is what separates it from a reporting connector, and it is also what makes the safety model matter.

The intended user is a marketer or a performance engineer who already has a Meta ad account and an MCP-capable assistant, and who would rather describe an operation in conversation than click through Ads Manager. It is not aimed at someone who wants to build a bespoke Meta integration; the repository is a server, not a library you embed.

## Hosted remote MCP versus the self-hosted path in this repo

The README pushes the hosted route and treats local installation as a fallback: the section is titled "Local Installation (Technical Users Only)". The hosted endpoint is `https://meta-ads.mcp.pipeboard.co/`, and the pitch is that you need no developer token and no self-hosting. Authentication happens once at pipeboard.co, and every MCP client you connect then gets access. There is a free plan, and the hosted service behind the project is described as a badged Meta Business Partner and an approved Meta app.

The repository still contains everything for a local run: a `Dockerfile` based on `python:3.11-slim` that installs `uv`, installs `requirements.txt` with `uv pip install --system -r requirements.txt`, and starts the server with `python -m meta_ads_mcp`. There is a `pyproject.toml` with a console script entry point named `meta-ads-mcp`, and the Python requirement is `>=3.10`. So the code is not a thin client stub; it is a runnable server you can inspect, which matters if you are the kind of team that reads the code before granting access to an ad account.

One detail in `requirements.txt` is worth noting because it is unusual to see spelled out: the dependency list pins `starlette>=1.0.1` with a comment about CVE-2026-48710, a Host-header auth bypass said to be vulnerable in starlette <= 1.0.0. A dependency floor pinned to a specific advisory is a sign someone is tracking the transitive surface of `mcp[cli]==1.28.1`, which is itself pinned to an exact version. Pinning `mcp` exactly means upgrades are deliberate rather than automatic.

## The 5-platform family and why it changes the comparison

The README is explicit that this repository is one node of a network. Pipeboard ships remote MCP servers for Meta, Google, TikTok, Snap and Reddit, at `https://google-ads.mcp.pipeboard.co/`, `https://tiktok-ads.mcp.pipeboard.co/`, `https://snap-ads.mcp.pipeboard.co/` and `https://reddit-ads.mcp.pipeboard.co/` respectively, with tool counts of 59, 59, 37 and 33 alongside Meta's 42. The README states that all five share the same OAuth, the same `tools/list` discovery, the same write-confirmation safety model and the same Pipeboard API token, for 230+ tools in total.

That claim is the main structural argument in the document. If it holds, an agent that learns the Meta tool surface transfers to the other four, and a question that spans channels ("which channel had the cheapest signups last week?") becomes answerable in one session. If you only ever run Meta, the family is irrelevant to you and the 42 tools are the whole story.

The README also draws its own comparison table against Meta's official connector and against generic open-source servers. Its honest summary: Meta's official connector is the safest single-platform option, Pipeboard is the cross-platform choice, and open-source servers give full control if you are willing to self-host and maintain them. That framing is fair, and it also tells you where the project expects to lose: anyone who wants first-party trust or total control.

## Installing and connecting the Meta Ads MCP server

The recommended path is the hosted remote server, which means there is nothing to install. You take the URL and give it to an MCP client. The README lists Claude, ChatGPT, Perplexity, Cursor and any MCP-compatible client as supported, and says setup takes roughly two minutes because there is no developer token to create.

The endpoint to register is:

```bash
https://meta-ads.mcp.pipeboard.co/
```

In a client that stores remote MCP servers in a JSON config, the entry looks like this. The URL is the one from the README; the surrounding shape depends on your client, so check its own documentation for the exact key names.

```json
{
  "mcpServers": {
    "meta-ads": {
      "url": "https://meta-ads.mcp.pipeboard.co/"
    }
  }
}
```

After the client reconnects, the tool list should populate with the Meta tools described in the README. You then authenticate against pipeboard.co once; that single login is what grants the client access to your ad accounts, and it is also the place to revoke access later.

If you prefer a shell to JSON-RPC, the README points at the Pipeboard CLI, a single Go binary that exposes the same tools as typed commands. The example given for Meta is:

```bash
brew install pipeboard-co/tap/pipeboard
export PIPEBOARD_API_TOKEN=<your-token>

pipeboard meta-ads get-campaigns --account-id act_123
```

The README cites sub-50ms startup and no MCP handshake per call as the reason to prefer this for automation scripts and coding agents. Note the account ID format in the example: `act_123`. That prefix is Meta's own convention, not something the project invented.

The repository also documents a local route for technical users, including a `Dockerfile` whose final command is `python -m meta_ads_mcp`. The README does not present local installation as the default, and it does not promise the same zero-token experience there.

## Where the hosted design costs you something

The first limitation is structural, not a bug: on the hosted path your ad account operations flow through Pipeboard's service. That is the trade you make for skipping the developer token, and it is the reason the README leans so hard on the Meta Business Partner badge and the approved-app status. If your organisation requires that ad-platform credentials never leave infrastructure you control, the hosted endpoint is the wrong choice regardless of how good the tool list is, and the local installation path is the one to evaluate instead.

The second is pricing and quota. The README mentions a free plan and paid tiers but does not document the limits of the free plan in what it publishes. The family page adds "one token, one rate-limit ceiling, one place to revoke", which cuts both ways: consolidating five platforms behind one token also means one ceiling for all of them. If you are running heavy reporting across Meta and Google in the same session, the ceiling is shared.

The third is the write surface. The README states that writes are explicit and that new campaigns start paused where the platform supports it, with confirmation prompts that look identical across all five servers. That is a sensible design, but it is also a description of behaviour you should confirm in your own client before trusting it, because the confirmation UI lives in the client, not in the server. A client that auto-approves tool calls removes the guardrail the README describes.

Finally, this is the Meta node. If your spend is on Google, TikTok, Snap or Reddit, installing this server gives you nothing; you want the corresponding node or the CLI.

## How it differs from Meta's official connector and from self-hosted servers

Meta ships its own connector, and the README describes it as first-party and free during open beta, with Meta-defined safety behaviour. The difference is scope. Meta's connector covers Meta. Pipeboard's argument is that the same conversational control should work across five ad networks under one authentication and one safety contract, and that an agent which learns one server's tool discovery learns the rest.

Against open-source, self-hosted Meta servers the difference is operational. A self-hosted server gives you the code, the tokens and the upgrade schedule, and you build the write guardrails yourself. The README says as much in its comparison table: "You build the guardrails." This project hands you a hosted endpoint and a documented safety model, in exchange for running through someone else's infrastructure and accepting their plan limits. Neither position is universally right. A team with a security review process will prefer owning the server. A two-person growth team that wants to ask Claude about yesterday's CPA will prefer the URL.

The third option in the repository itself is the CLI, which is not an alternative to MCP so much as an alternative transport for the same tools. If your workflow is scripts and coding agents rather than chat, the CLI avoids the MCP handshake per call, which the README frames as the reason it exists.

## Licence, maintenance and upgrade cost

The licence is the part most readers will skim past and shouldn't. `pyproject.toml` declares `license = {text = "BUSL-1.1"}`, and the classifier is "Other/Proprietary License". The repository's licence metadata is reported as NOASSERTION, which is consistent with a non-standard licence rather than an OSI-approved one. The README has a Licensing section, and that is where the actual terms live; the Business Source License is typically source-available with usage restrictions that change over time, but the specific grant, the permitted production use and the change date are not spelled out in what the project publishes here. Read the LICENSE file before you build anything on top of this, and treat the "open-source" framing in the README as a claim to verify rather than a fact to rely on. Nothing here is legal advice.

Maintenance looks current on the evidence available. The repository is not archived, the last push was on 2026-08-19, and releases have been frequent: 1.0.118 on 2026-07-13, 1.0.119 on 2026-07-30, and 1.0.120 on 2026-08-10. The version in `pyproject.toml` matches the latest release at 1.0.120. That release cadence is the upgrade cost you should plan for: the package pins `mcp[cli]==1.28.1` exactly and floors `starlette>=1.0.1` for a security advisory, so dependency bumps are deliberate and you should expect to re-pull rather than float. The `Dockerfile` builds from `requirements.txt`, so a local deployment is a rebuild away from any release, but the README does not document a rollback procedure for the hosted endpoint.

## Conclusion

Adopt it if you already run Meta campaigns and want an MCP client to read and write them without building a Meta developer app, and if you accept that the hosted path routes through Pipeboard's OAuth and free-plan limits. Do not adopt it if you need an auditable, self-contained server you can patch, or if all your spend sits on Google, TikTok, Snap or Reddit, where the Meta node buys you nothing. Before connecting a live account, verify three things: that your client accepts a remote MCP URL, that the write-confirmation prompts appear in that client, and that any campaign the agent creates starts paused as the README states, so you review targeting and budget before a single impression is served.

## FAQ

### What is the Meta Ads MCP server?

It is a Model Context Protocol server that exposes Meta advertising operations as tools an AI assistant can call. The README lists 42 tools on the Meta node, covering campaigns, ad sets, ads, creatives, image upload, insights, targeting and page management across Facebook and Instagram.

### Does Meta have an MCP server?

Meta ships its own connector, which the README describes as first-party, Meta-only and free during open beta. This project is a separate, independent server that uses Meta's public APIs and is hosted by Pipeboard, a badged Meta Business Partner.

### How do I add Meta Ads MCP to Claude?

Add the remote endpoint `https://meta-ads.mcp.pipeboard.co/` to your MCP client's server configuration and authenticate once at pipeboard.co. The README says this works with Claude, ChatGPT, Perplexity, Cursor or any MCP-compatible client, and that no developer token is needed.

### What is MCP in Facebook ads?

MCP is the Model Context Protocol, the interface this server implements so an AI assistant can invoke advertising operations as tools. In this project those tools cover Facebook and Instagram campaign management, creative upload and performance insights.

### How do I connect Meta Ads MCP?

The README recommends the hosted remote server: register the URL in your client and log in at pipeboard.co once. A Pipeboard CLI binary is offered as an alternative for shell and script use, and a local installation path exists in the repository for technical users.

## Sources

- [Issues](https://github.com/pipeboard-co/meta-ads-mcp/issues)
- [pipeboard-co/meta-ads-mcp on GitHub](https://github.com/pipeboard-co/meta-ads-mcp)
- [Project website](https://pipeboard.co)
- [README](https://github.com/pipeboard-co/meta-ads-mcp/blob/main/README.md)
- [Releases](https://github.com/pipeboard-co/meta-ads-mcp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pipeboard-co-meta-ads-mcp