Meta's ads MCP server is now listed in Databricks Marketplace, which means an agent inside your Databricks workspace can read Meta campaign performance and change campaigns without anyone exporting a CSV. What matters for a mid-sized company isn't the chat interface. It's that the same agent call can see your churn score, your margin table and your Meta spend at once, under Unity Catalog permissions, with the tool call recorded.
Meta's server is Meta-hosted at https://mcp.facebook.com/ads and works with any MCP-compatible agent, according to Meta's overview. The Databricks listing is what brings it under your existing governance instead of into someone's personal Claude or ChatGPT session.
What was already possible, and what wasn't
Anyone could already pull Meta data into a lakehouse through the Marketing API, and anyone could already score customers in Databricks. What that costs is a maintained integration and a handoff. The scoring runs, somebody exports a segment, somebody else uploads it, and a week of signal evaporates in the gap.
The gap closes in two directions here. Meta's server exposes tools across seven categories: reporting, ad creation and management, catalog creation and management, signals and datasets, help and troubleshooting, A/B tests and conversion lift studies, and activity logs. The Databricks announcement counts 25+ tools across the campaign lifecycle. So the agent can both read delivery metrics and write a campaign, and it can do that while querying governed tables in the same workspace.
The second direction is the one people underrate. Gross margin per order lives in Databricks. Campaign spend and delivery live at Meta, and an agent with both can argue for moving budget toward ad sets driving profitable revenue instead of cheap conversions. That is an ordinary analytical question that is currently expensive because the two halves live in different systems with different owners.
Signal diagnostics are the other practical win. If you already send conversions through the Meta Conversions API, the ads MCP server gives agents access to event volumes, Event Match Quality and data freshness. "Did purchase events drop because sales slowed, or because something changed in our pipeline?" is a question that normally takes a pipeline engineer and a media buyer in the same room. It becomes one investigation across both sides.
Installing it and wiring the permissions
Start with the Marketplace privileges, because this is where a first attempt stalls. To install an MCP server from Databricks Marketplace you need USE CATALOG and USE SCHEMA on the target catalog and schema, plus CREATE SERVICE on the target schema, on top of the USE MARKETPLACE ASSETS privilege on the metastore and a Premium-plan account with a Unity Catalog-enabled workspace (Databricks docs).
Then the Meta side. The Databricks listing instructs you to configure the connection with a Meta user access token and the required permissions. Meta's get started page sets the floor at ads_mcp_management plus either ads_read or ads_management. More scopes open up more tools, including catalog_management, business_management, pages_show_list and instagram_basic.
Use a system user token instead of a person's. Meta supports system user access tokens for server-to-server setups, with one trap worth knowing before you generate one: only Employee-role system user tokens work. Admin-role system user tokens can't access the ads MCP server. A token tied to a named marketer is a token that dies when they change roles.
Once the service is registered, callers need EXECUTE on the MCP plus USE CATALOG and USE SCHEMA on its parents, and they need to be assigned to the workspace (governing an MCP). End users do not need USE CONNECTION, and you should not hand it out, because it permits direct use of the connection outside the MCP's tool selection and policies, which is exactly the fence you just built.
Restrict the tool surface at registration. Registered MCPs expose all server tools by default; under Tools you can select manually, or use the Advanced option to enter exact names or prefixes such as get_*. Turn off "Automatically include tools added to this server in the future" if new tools should be reviewed first. Exclusion patterns like !delete_* are not supported, so build the allowlist positively. Unselected tools don't appear in tools/list, and a call to one returns Tool not allowed by MCP service configuration.
Two sets of guardrails, and you want both
The first question about any agent with a credit card attached is what stops it doing something expensive and wrong. There are two independent answers here, enforced in different places.
On the Databricks side, Unity Gateway governs the tool calls. A service policy evaluates a call before it runs (ON CALL) and can evaluate its result (ON RESULT), and can allow, block or require approval without changing what's in the tool list. You need MANAGE on the MCP to attach one, and MCP policies require the Unity Gateway beta, which an account admin enables from the account console Previews page. There's a built-in Sensitive Data Detection policy that blocks calls or results carrying classified PII categories such as class.us_ssn and class.credit_card, applied on Input, Output or both. You can also cap volume: set Service QPM to 60 and tool calls over the limit return HTTP 429.
On the Meta side, rules deny a specific agent action on a specific ad account or catalog, server-side, regardless of which model is pointed at it. Meta's rules documentation lists the actions an ad account rule can govern: create_campaign, create_ad_set, create_ad, edit_budget, edit_targeting, edit_creative, edit_status, and all. The budget action takes three trigger types, percentage_change with max_percentage, absolute_change with max_amount_cents, and absolute_max with max_value_cents, each optionally scoped by budget_dimension of daily, lifetime or both.
The canonical rule, capping any budget increase at 20 percent, is one form POST:
curl -sS -X POST \
"https://ads-api.facebook.com/v25.0/marketing-api/businesses/<BUSINESS_ID>/accounts/act_<AD_ACCOUNT_ID>/ads_mcp_rules" \
-d "action=edit_budget" \
-d "trigger_type=percentage_change" \
-d "status=active" \
-d 'metadata={"max_percentage":20,"budget_dimension":"both"}' \
-d "access_token=<ACCESS_TOKEN>"
Call ads-api.facebook.com instead of graph.facebook.com, and use v25.0; v22.0 is deprecated and auto-upgrades. Writes are keyed on the (action, trigger_type) pair, so posting the same pair again updates the rule instead of creating a duplicate. That makes a nightly reconcile job safe to run without tracking rule IDs. There is no batch endpoint and no DELETE verb, so budget one call per rule per asset, watch the x-business-use-case-usage header, and turn a rule off by posting it again with status=paused.
One asymmetry will bite a reconcile loop. On an ad account, a paused rule is kept and a later read still returns it with status of paused. On a catalog, posting paused removes the rule entirely and a later read does not return it. If you diff against a desired-state config, do not treat a missing catalog rule as drift; absent and paused are the same state there. The two endpoints also return different error shapes, Graph-style {"error":{...}} for ad accounts and RFC 7807 problem details for catalogs, so a client written for one will silently fail to parse the other.
What it costs and what it requires
Meta does not charge for the server; you pay the ad spend and whatever Databricks compute the agent's queries consume. The real bill is in prerequisites. A Premium Databricks account and a Unity Catalog-enabled workspace are non-negotiable for Marketplace consumption. Policies need the Unity Gateway beta turned on at account level. And Meta's rules are in limited availability, so if your business is not enrolled, the ad account endpoint returns error code 10 and the catalog endpoint returns HTTP 403.
Read that last constraint carefully before you plan a rollout. The programmatic guardrails are the part that makes agent write access defensible at scale, and they are gated. The same controls appear on the ads MCP server page in Meta Business Suite settings, so a small team with three ad accounts can click through them. A hundred accounts without API enrolment is a different proposition.
Where the fit gets thin
If your first-party data is thin, this changes nothing. The whole argument is that an agent reasoning over an LTV score, a propensity model and a margin table makes a better call than one reasoning over Ads Manager alone. No models, no advantage; you have bought a chat interface for Ads Manager.
The fit is also poor for teams that have not decided who owns a bad campaign. Meta's rules can deny a budget increase above a threshold, though they cannot tell you the threshold, and Unity Gateway can require approval for a call without telling you who approves. Those are operating decisions, and an agent surfaces them faster than a weekly sync does.
Single-channel teams should also be honest about scope. This governs Meta. Google, TikTok and the rest stay where they are, so a cross-channel budget conversation is still partly manual.
If you are setting this up
Install it into a dedicated catalog and schema so the CREATE SERVICE grant stays narrow. Register with manual tool selection, starting read-only: ads_get_ad_entities and the reporting tools give you the Monday-morning question ("which campaigns underperformed last week, and how does that square with internal revenue?") with nothing at risk. Write Meta rules before you grant a single write tool, including edit_budget with percentage_change, and verify by trying a blocked call and reading the structured error. Then turn on tracing and query system.ai_gateway.usage with service_type = 'MCP_SERVICE' to see which tools your team actually calls, grouped by mcp_metadata.tool_name.
The pattern generalises past advertising. Any external system with an MCP server can be registered as a Unity Catalog securable and fenced the same way, which is the argument we made about agent identity in Unity Catalog for AI agents in practice. Meta's listing is a well-documented instance of it, with the unusual property that the vendor enforces its own limits server-side too. More of that, please.
If you want help sizing this against your own data estate, that's the kind of work we do on Databricks.
Frequently asked questions
What is Meta's ads MCP server?
It's a Meta-hosted Model Context Protocol server at https://mcp.facebook.com/ads that lets an AI agent manage Meta ads through structured, permission-scoped tools instead of Ads Manager or direct Marketing API calls. Meta groups the tools into seven categories covering reporting, campaign creation and editing, catalogs, signal health, Business Help Center search, A/B tests and lift studies, and activity logs.
What permissions does the Meta connection need?
At minimum the access token must carry ads_mcp_management and either ads_read or ads_management. Adding catalog_management, business_management, pages_show_list or instagram_basic opens up more tools, and only Employee-role system user tokens work for server-to-server setups.
How do you stop an agent from overspending?
Two layers. Meta rules deny specific actions server-side, such as an edit_budget rule with trigger_type=percentage_change and max_percentage of 20, while Unity Gateway service policies evaluate each tool call ON CALL and ON RESULT to allow, block or require approval. Meta's rules API is in limited availability, so unenrolled businesses get error code 10 on the ad account endpoint and must use Business Suite settings instead.
What do you need in Databricks to install it?
A Premium-plan account, a Unity Catalog-enabled workspace, USE MARKETPLACE ASSETS on the metastore, and USE CATALOG plus USE SCHEMA on the target catalog and schema with CREATE SERVICE on the target schema. MCP service policies also require the Unity Gateway beta, enabled by an account admin from the account console Previews page.