Which integrations are available for this server?

Provides tools for reading Meta (Facebook) Ads campaign, ad-set, and ad performance data, including listing ad accounts, retrieving campaigns/ad sets/ads, fetching insights, and generating a performance summary with heuristic flags for review.

How do I use Meta Ads MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Meta Ads MCP show me a performance summary for my ad account" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Meta Ads MCP

by anhnguyen0905

Overview Schema Related Servers Score Discussions

Python

Local

Meta Ads MCP

Meta Ads MCP is a minimal, read-only Python MCP server that pulls Meta (Facebook) Ads campaign, ad-set, and ad performance so a human can spot problems and adjust them in Ads Manager earlier. It never changes budgets, statuses, or creatives.

Tools

Tool	Purpose
`list_ad_accounts`	List the Meta ad accounts available to the configured access token.
`get_campaigns`	Get campaigns for an explicit or configured default ad account.
`get_adsets`	Get ad sets beneath an account or campaign parent.
`get_ads`	Get ads beneath an account, campaign, or ad-set parent.
`get_insights`	Get raw Meta performance metrics for an object and reporting period.
`performance_summary`	Rank campaigns by spend and flag performance symptoms for review.

The flags from performance_summary are HEURISTIC signals, not diagnoses. Conversions and ROAS are platform-reported (Meta attribution), not incremental; a holdout or lift test is required to claim incrementality.

Related MCP server: TikTok Ads MCP

Prerequisites

Python 3.10 or newer

Meta credentials

Create a Meta app at Meta for Developers.
Add the Marketing API to the app.
Generate a long-lived User access token with the ads_read permission and access to the required ad account.
Find the ad account ID in Ads Manager. It must use the act_<digits> form, such as act_123456789.

Meta's screens and access-token options can change. Follow the official Marketing API Get Started documentation for the current screens. Treat the access token as a secret.

Quick setup

One command does the whole setup:

python -m meta_ads_mcp setup

For the full walkthrough - creating the Meta app, redirect URI rules, giving teammates access, and a troubleshooting table - see docs/SETUP.md.

It asks for the app id and app secret (the secret is never echoed), writes .env with owner-only permissions, runs the browser login, lists the ad accounts the token can read so you pick one from a numbered menu, and registers the server in claude_desktop_config.json (backing up any existing file). Restart Claude Desktop afterwards.

If META_ACCESS_TOKEN is already set in .env, setup offers to keep it and skips the login entirely. Useful options:

Option	Purpose
`--client-config PATH`	Patch a different MCP client config.
`--command-path PATH`	Command the client should launch.
`--env-file PATH`	Write to a different dotenv file.

The manual route below is still supported if you would rather set each piece yourself.

Environment setup

Copy the template and fill in your credentials:

Copy-Item .env.example .env

There are two ways to supply the token. Pick one.

Route A - paste a token

META_ACCESS_TOKEN=your-long-lived-user-access-token
META_AD_ACCOUNT_ID=act_123456789
META_GRAPH_API_VERSION=v23.0

A system user token from Business Manager (Business Settings > Users > System Users) never expires and needs no login flow. A manually generated user token expires in about 60 days.

Put the app credentials in .env and leave META_ACCESS_TOKEN blank:

META_APP_ID=your-app-id
META_APP_SECRET=your-app-secret
META_AD_ACCOUNT_ID=act_123456789

Then authorize in a browser:

python -m meta_ads_mcp login

The command opens the Facebook Login dialog, receives the redirect on http://localhost:8721/callback, exchanges the code for a long-lived token, and caches it at ~/.local/share/meta-ads-mcp/token.json (%LOCALAPPDATA% equivalent via XDG_DATA_HOME) with owner-only permissions. The server picks that cached token up automatically, so no token ever needs to sit in a config file.

http://localhost:8721/callback must be listed under Facebook Login > Settings > Valid OAuth Redirect URIs on the app. Change the port or scheme with META_OAUTH_REDIRECT_URI if needed.

If Meta rejects a localhost redirect URI, use the paste flow instead - it uses Meta's own desktop redirect page and needs no registered URI:

python -m meta_ads_mcp login --paste

Related commands:

Command	Purpose
`python -m meta_ads_mcp status`	Show the cached token's expiry.
`python -m meta_ads_mcp logout`	Delete the cached token.

Meta issues no refresh tokens, so a long-lived user token lasts about 60 days; rerun login when status shows it near expiry. Only a system user token (route A) avoids re-authorizing entirely.

META_ACCESS_TOKEN always wins over the cached token when both are present. META_GRAPH_API_VERSION is optional and defaults to v23.0. The .env file is git-ignored; never commit it.

Install

Create a virtual environment and install the package with its development dependencies:

python -m venv .venv
.venv\Scripts\python.exe -m pip install -e ".[dev]"

If you already use uv, the install step can instead be:

uv pip install -e ".[dev]"

uv is optional and is not required.

Run

From an activated virtual environment, start the stdio server with:

python -m meta_ads_mcp

The installed console entry point is also meta-ads-mcp. A stdio MCP server waits on standard input, so it is normally launched by an MCP client rather than run interactively.

MCP client configuration

For Claude Desktop, add a server entry under mcpServers in claude_desktop_config.json. Replace the example path and credentials:

{
  "mcpServers": {
    "meta-ads": {
      "command": "C:\\Users\\your-name\\path\\to\\meta-ads-mcp\\.venv\\Scripts\\python.exe",
      "args": ["-m", "meta_ads_mcp"],
      "env": {
        "META_ACCESS_TOKEN": "your-long-lived-user-access-token",
        "META_AD_ACCOUNT_ID": "act_123456789"
      }
    }
  }
}

For Claude Code, put the equivalent configuration in the project-level .mcp.json; it mirrors the Desktop configuration:

{
  "mcpServers": {
    "meta-ads": {
      "command": "C:\\Users\\your-name\\path\\to\\meta-ads-mcp\\.venv\\Scripts\\python.exe",
      "args": ["-m", "meta_ads_mcp"],
      "env": {
        "META_ACCESS_TOKEN": "your-long-lived-user-access-token",
        "META_AD_ACCOUNT_ID": "act_123456789"
      }
    }
  }
}

The token and account ID can live in the client's env block instead of .env. Keep client configuration containing a real token private.

If you used browser login (route B), omit META_ACCESS_TOKEN from the env block entirely - the server reads the cached token from ~/.local/share/meta-ads-mcp/token.json. Leaving a placeholder string there would override the cached token and every call would fail with an auth error.

Graph API version

The server pins Graph API v23.0 by default. If Meta deprecates that version, set META_GRAPH_API_VERSION to a current supported version.

Smoke test

After filling .env, run the manual real-network check:

python scripts/smoke_test.py

It lists up to five accessible ad accounts and up to five campaigns from the configured default account.

Security

Never commit .env or paste the access token into logs, issues, or chat. The server and all six tools are read-only.

The app secret is used only for the server-side code exchange and is never put in a URL sent to the browser. The cached token file is written with 0600 permissions inside a 0700 directory, and the login flow validates the OAuth state value with a constant-time comparison before exchanging any code.

Development

Run the test suite with:

pytest

Available Tools

6 tools

get_adsA

Read-onlyIdempotent

Get ads beneath an account, campaign, or ad-set parent.

Args: params: Parent object ID, maximum result count, and JSON or Markdown response format.

Returns: A rendered {"success": bool, "data": list[object] | null, "error": string | null} envelope containing ad identifiers, names, statuses, ad-set IDs, and campaign IDs.

Use this to inspect ads for a known hierarchy parent. Do not use it for performance metrics or to create, edit, pause, or delete ads.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context about the return envelope structure and the fields returned, which goes beyond the annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise paragraphs plus a usage note. It front-loads the core purpose and includes only essential information. No redundant or unnecessary sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and rich annotations, the description covers the tool's purpose, usage boundaries, and basic parameters. It explains the return envelope and fields. However, it does not mention pagination behavior beyond the limit parameter, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema includes descriptions for all three parameters (parent_id, limit, response_format), so the schema already covers parameter semantics. The description summarizes them briefly ('Parent object ID, maximum result count, and JSON or Markdown response format') but adds no additional meaning beyond what is in the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('get') and resource ('ads beneath an account, campaign, or ad-set parent'), clearly distinguishing it from sibling tools like get_campaigns and get_insights. It explicitly states the scope ('beneath a parent'), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states when to use the tool ('inspect ads for a known hierarchy parent') and when not to ('Do not use it for performance metrics or to create, edit, pause, or delete ads'). However, it does not explicitly name alternative tools for those uses, though siblings like get_insights are implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_adsetsA

Read-onlyIdempotent

Get ad sets beneath an account or campaign parent.

Args: params: Parent account or campaign ID, maximum result count, and JSON or Markdown response format.

Returns: A rendered {"success": bool, "data": list[object] | null, "error": string | null} envelope containing ad set identifiers, names, statuses, campaign IDs, and daily budgets.

Use this to inspect the ad-set hierarchy for a known parent. Do not use it for performance metrics or to create, edit, pause, or delete ad sets.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making the safety profile clear. The description adds value by specifying the return envelope structure and included fields (identifiers, names, statuses, campaign IDs, daily budgets), and confirming it's for hierarchy inspection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concisely written with key information front-loaded. It is a single paragraph that efficiently covers purpose, parameters, return format, and usage guidance without extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description sufficiently explains return envelope and data fields. Combined with usage guidelines and parameter descriptions, it provides complete context for using the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description explains parameters at a high level ('parent account or campaign ID, maximum result count, and JSON or Markdown response format'), adding context about response format options. However, the input schema already provides detailed descriptions, default values, and constraints, so the description's incremental contribution is limited.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool retrieves ad sets beneath an account or campaign parent. It uses specific verb 'get' and resource 'ad sets', distinguishing it from sibling tools like get_campaigns and get_ads.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description explicitly says 'Use this to inspect the ad-set hierarchy for a known parent' and 'Do not use it for performance metrics or to create, edit, pause, or delete ad sets.' This provides clear when-to-use and when-not-to-use guidance, implicitly directing to sibling tools for other purposes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_campaignsA

Read-onlyIdempotent

Get campaigns for an explicit or configured default ad account.

Args: params: Optional account ID, maximum result count, and JSON or Markdown response format.

Returns: A rendered {"success": bool, "data": list[object] | null, "error": string | null} envelope containing campaign identifiers, names, statuses, objectives, and budgets.

Use this for an account-level campaign inventory. Do not use it for performance metrics or for campaign creation, edits, or status changes.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is clear. The description adds value by describing the return envelope structure and fields, but does not contradict annotations. A 4 reflects adequate behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs: the first covers purpose and parameters, the second explains use case and limitations. No redundancy, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description still usefully summarizes the return envelope and data fields. It covers response format options and default account behavior. Complete for a read-only listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions already cover parameters with examples and defaults, so schema_description_coverage is high (0% context likely erroneous). The description only rephrases parameter types without adding new meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair ('Get campaigns') and clarifies scope ('explicit or configured default ad account'). It lists return fields (identifiers, names, statuses, objectives, budgets), distinguishing it from siblings like get_ads or get_insights.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('account-level campaign inventory') and when not to use ('Do not use it for performance metrics or for campaign creation, edits, or status changes'), implicitly steering to sibling tools like get_insights or other mutation tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_insightsA

Read-onlyIdempotent

Get raw Meta performance metrics for an object and reporting period.

Args: params: Object ID, aggregation level, either a date preset or custom since/until range, maximum row count, and response format.

Returns: A rendered {"success": bool, "data": list[object] | null, "error": string | null} envelope containing raw Meta insight rows with spend, delivery, click, action, and purchase ROAS fields.

Use this for flexible read-only metric retrieval at account, campaign, ad-set, or ad level. Do not use it to modify delivery or to infer causal lift from platform-attributed results.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. Description reinforces read-only use and adds details on returned fields (spend, delivery, click, etc.), without contradicting annotations. Adds moderate value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear structure: single-sentence summary, then Args, Returns, and usage guidance. No redundant sentences; every part adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, return format, and usage boundaries. The output schema exists and is described in the Returns section. Sibling tools are listed but not explicitly contrasted, though usage guidelines imply differentiation. Overall complete for a flexible read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage at the top-level, the description lists all key parameters (Object ID, level, date preset/range, limit, format) and summarizes their roles. The nested schema provides individual descriptions, so the description adds a helpful high-level view.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get raw Meta performance metrics for an object and reporting period', specifying the verb, resource, and context. It also mentions the available levels (account, campaign, ad-set, ad), which helps distinguish it from sibling list tools like get_campaigns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this for flexible read-only metric retrieval' and warns 'Do not use it to modify delivery or to infer causal lift', providing clear when-to-use and when-not-to-use guidance that differentiates from siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_ad_accountsA

Read-onlyIdempotent

List Meta ad accounts available to the configured access token.

Args: params: Maximum result count and JSON or Markdown response format.

Returns: A rendered {"success": bool, "data": list[object] | null, "error": string | null} envelope containing account identifiers, names, statuses, and currencies.

Use this to discover an account ID before account-scoped reads. Do not use it to inspect campaigns or to create, update, or delete ad accounts.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, giving the agent confidence it's a safe read operation. The description adds context about the return envelope structure and that it lists accounts available to the configured token. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three short sentences covering purpose, parameters, and return value. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, annotations, and output schema, the description is complete. It explains the use case, input parameters, and return structure (envelope with specific fields), leaving no gaps for an agent to interpret.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description summarizes the params argument as 'Maximum result count and JSON or Markdown response format,' which adds clarity over the raw schema. However, the schema already includes descriptions for limit and response_format, so the description's contribution is marginal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists Meta ad accounts and specifies its role in discovering an account ID for subsequent reads. It uses a specific verb ('list') and resource ('ad accounts'), distinguishing it from sibling tools like get_campaigns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use ('to discover an account ID before account-scoped reads') and when not to use ('do not use it to inspect campaigns or to create, update, or delete ad accounts'). This provides clear guidance and differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

performance_summaryA

Read-onlyIdempotent

Rank campaign performance and flag heuristic symptoms for review.

Args: params: Optional account ID, reporting preset, CTR, ROAS, and frequency thresholds, and JSON or Markdown response format.

Returns: A rendered {"success": bool, "data": {"caveat": string, "truncated": bool, "campaigns": list[object]} | null, "error": string | null} envelope. Campaign records are sorted by spend and include metric values plus zero or more heuristic flag names.

Use this for read-only campaign triage, not as proof of causation or a verified diagnosis. Conversions and ROAS are platform-reported using Meta attribution, not incremental; a holdout or lift test is required to claim incrementality, and periods should be compared at similar spend. Do not use this tool to make delivery changes or assert causal campaign impact.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context: it is for triage, not causal analysis; results have caveats; campaign records include metric values and heuristic flags. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Args/Returns sections and usage guidance, but it is somewhat lengthy. A slightly more concise version could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple parameters, heuristic flags, return envelope), the description is complete: it explains the return format, read-only nature, caveats, and provides guidance on when to use. No gaps are evident.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has detailed descriptions for all sub-parameters, so schema_description_coverage is effectively 100%. The tool description merely lists the parameters without adding meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Rank campaign performance and flag heuristic symptoms for review.' It specifies the resource (campaigns) and differentiates from sibling tools like list/get operations, as this is a summary/analysis tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Use this for read-only campaign triage, not as proof of causation or a verified diagnosis.' It also warns against using for delivery changes or asserting causal impact, and explains limitations of platform-reported metrics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.2.0Jul 28, 2026
- First observedget_ads
- First observedget_adsets
- First observedget_campaigns
- First observedget_insights
- First observedlist_ad_accounts
- First observedperformance_summary

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource (ad accounts, campaigns, ads, ad sets, insights, performance summary) with clear boundaries and explicit 'do not use' guidance, eliminating ambiguity.

Naming Consistency4/5

Most tools follow a 'get_<resource>' pattern (get_campaigns, get_ads, get_insights, get_adsets), with one using 'list_' (list_ad_accounts) and another using a noun phrase (performance_summary), which is a minor inconsistency.

Tool Count5/5

The 6 tools are well-scoped for a read-only Meta Ads analytics server, covering account discovery, hierarchical retrieval, insights, and a summary function without being excessive.

Completeness3/5

The surface is read-only and covers listing and insights, but lacks any create, update, or delete capabilities, and misses tools for single-object retrieval or ad account details beyond listing.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Google Ads + Meta Ads + GA4 MCPOAuth
io.github.irinabuht12-oss
Google Ads, Meta Ads & GA4 MCP server - 250+ tools for campaigns, creatives, audiences & reports.
Marketing Social Media
11,434
NotFair-MetaAds AOAuth
io.github.nowork-studio
Meta Ads MCP (Facebook + Instagram) - analyze performance, manage budgets, pause campaigns.
Marketing Social Media
23,592
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
google-ads
ai.adramp
Google Ads MCP server — manage campaigns, keywords, and metrics.
Marketing E-commerce & Retail
2

Related MCP Servers

Meta Ads MCP Server
Marketing Social Media
brmh
F
license
Not graded
quality
D
maintenance
A comprehensive MCP server for managing and analyzing Meta Ads (Facebook/Instagram) with over 80 natural-language tools for AI agents like Claude Desktop.
Updated 6 months ago (2026-03-06 11:14 UTC)
-
TikTok Ads MCP
Marketing Social Media
Buer2333
A
license
B
quality
B
maintenance
A read-only MCP server that provides comprehensive access to the TikTok Business API for retrieving advertising data, including campaigns, ad groups, ads, and performance reports.
Updated 11 days ago (2026-08-27 07:47 UTC)
24
MIT
mlg-meta-mcp
Marketing Social Media
iammalego
A
license
Not graded
quality
D
maintenance
MCP server for Meta Ads providing 30 tools for account discovery, campaign management, targeting research, and insights. Designed with LLM-friendly outputs and productivity features like cloning and bulk operations.
Updated 4 months ago (2026-04-25 20:07 UTC)
1
MIT
flin-meta-ads-mcp
Marketing Social Media
flin-agency
A
license
B
quality
B
maintenance
Read-only MCP server for Meta Ads that lists and reads ad accounts, campaigns, ad sets, ads, ad images, creatives, and fetches insights at various levels.
Updated a month ago (2026-08-04 12:54 UTC)
14
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/anhnguyen0905/meta-ads-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Meta Ads MCP

Tools

Prerequisites

Meta credentials

Quick setup

Environment setup

Route A - paste a token

Route B - browser login

Install

Run

MCP client configuration

Graph API version

Smoke test

Security

Development

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API