Meta Ads MCP for Clinics: A Read-Only Setup Guide

The safest way for a clinic to connect Meta's ads MCP server is read-only: authorize it with a dedicated view-only identity, set Meta's ads MCP server rules to read-only, block the write tools in your AI client, and clean clinical names out of audiences and events before the first prompt. Read-only stops the assistant from spending or editing; it does not change what it reads. Curve handles that part upstream, sending conversions to Meta under neutral event aliases, so the event names Meta records, and the AI reads back, are neutral instead of naming a service line, with a signed BAA on every plan.

What you are locking

Meta's ads MCP server is a Meta-hosted endpoint at https://mcp.facebook.com/ads, in beta since April 29, 2026. It writes as well as reads, in five groups:

• Campaign lifecycle: the ads_create_* tools, ads_update_entity, ads_boost_ig_post and ads_activate_entity.
• Audiences: custom audience create, update and delete, including ads_update_custom_audience_users, which uploads hashed personal data to a customer list.
• Pixel rules: create, update and delete for pixel event rules and parameter extractors.
• Catalogs: catalog, product, product set and feed writes, plus ads_catalog_event_source_connect, which links a pixel or other event source to a catalog.
• Experiments: ads_experiment_abtest_create_test and ads_experiment_lift_create_test create A/B tests and conversion lift studies; ads_experiment_abtest_update_test edits or cancels an A/B test.

Meta creates new campaigns, ad sets and ads paused, and the client asks for confirmation before ads_activate_entity, which "starts spending budget." That protects the budget from new entities only: ads_update_entity edits existing campaigns, ad sets and ads, and Meta's tool page describes no paused step for an edit to something already live. Audience uploads and pixel rule changes spend nothing and still change who Meta matches and what your pixel records.

Meta signs no BAA for ads, and Anthropic's BAA does not cover data sent to third parties through MCP connectors, so no PHI should cross this connection in either direction. For why each write tool matters for a clinic, see Is the Meta Ads MCP HIPAA Compliant?

Step 1: Give the connector its own view-only identity

Never authorize the MCP server with your media buyer's everyday login; the authorizing identity caps what the assistant can do.

Option A: a dedicated business user

This is the path Meta documents. Pick one person to run AI reporting and scope their access to that job:

• No business admin rights.
• Only the ad accounts they analyze, with view-only reporting access (the permission many teams still call the Analyst role). No campaign management, no billing.
• No pixel or dataset admin. If you want the signals reports below, give the identity the lowest dataset access that returns them, and confirm it cannot create an event rule.
• No catalogs, no Page publishing.

That person authorizes the server through Facebook Login for Business. If they cannot build a campaign in Ads Manager, the assistant acting as them should not be able to either; Step 2 proves it.

Option B: a system user

A system user is a non-human identity for software making API calls. It is a candidate only if you run your own Meta app and pass a pre-obtained token. Meta's MCP getting-started page documents OAuth and user access tokens and does not mention system users, so send the system user token with a tools/list call and confirm it works before you build on it. If it does, two choices matter:

• Create a regular system user, not an admin one, and assign it only the ad account with view-only access. Regular system users "can only access the assets they have permission for"; admin ones can create users and assign permissions.
• Make the token expire. Meta offers system user tokens that never expire or that last 60 days, and calls expiring tokens "a security best practice." A non-expiring token is a standing key to your ad account sitting in a config file.

Why the token scope is not your lock

Meta's getting-started page lists ads_management next to ads_read among the permissions to grant, so a narrow token will not make the connection read-only. The locks that hold are the identity's asset permissions and Meta's MCP rules (see MCP access tokens for health data).

Step 2: Lock read-only in three places

Each lock fails differently; set all three.

1. Meta's ads MCP server rules. Anyone with full control of a business portfolio can set what AI agents may do on an ad account, "from budget changes to catalog updates." Choose read-only, not approval-required, per asset in Meta Business Suite settings or in bulk through the Marketing API (useful for one ad account per location). Meta says its rules cover an ad account or a catalog, not datasets, so the pixel tools depend on the other locks: an identity with no dataset admin rights and the client block.
2. Your AI client. In Claude Code, a deny rule removes a matching tool from Claude's context, deny beats allow at every settings level, and globs work if they match the full tool name (deny list below). If Meta is added as a claude.ai connector, an organization admin can set individual tools to blocked, which hides them in chat, the desktop app and Claude Code alike. In a client with no per-tool block, the Meta rule and the identity are your only locks.
3. A human on every remaining call. Keep per-call approval on. The MCP specification says a human should always be able to deny a tool call.

Do not trust a client's "read-only" badge: the MCP specification says tool annotations such as readOnlyHint are untrusted hints unless the server is trusted.

Prove it before you rely on it

Test the Meta side first. Ask the assistant to create a paused campaign named TEST-DELETE-ME; the call should fail on the rule or the identity's permissions. Then ask it to create a pixel event rule (Meta creates those inactive). That call should fail too.

If either object appears, you found the gap before anything spent. Delete it by hand, fix the rule or the identity, retest, then add the client block.

A deny list for Claude Code

Add these to permissions.deny in the project you use for Meta reporting. They assume the server name meta-ads from Meta's own claude mcp add command, and the verb globs also catch future tools named the same way.

• mcp__meta-ads__ads_create_*
• mcp__meta-ads__ads_update_*
• mcp__meta-ads__ads_delete_*
• mcp__meta-ads__ads_activate_entity
• mcp__meta-ads__ads_boost_ig_post
• mcp__meta-ads__ads_pixel_*_create
• mcp__meta-ads__ads_pixel_*_update
• mcp__meta-ads__ads_pixel_*_delete
• mcp__meta-ads__ads_experiment_*_create_test
• mcp__meta-ads__ads_experiment_abtest_update_test
• mcp__meta-ads__ads_catalog_*create*
• mcp__meta-ads__ads_catalog_*update*
• mcp__meta-ads__ads_catalog_*delete*
• mcp__meta-ads__ads_catalog_event_source_*connect

Strictness pays twice. ads_library_search pulls other advertisers' ad copy, untrusted text, into the conversation (see prompt injection in ad data). With Meta's write tools gone, a planted instruction cannot change the account. It can still try to push data out through anything else in the session, so run Meta reporting in a Claude Code project whose settings deny WebFetch and Bash, with no email or CRM connector attached.

Step 3: Clean the account before the assistant reads it

Read-only limits what the assistant can do, not what it reads. A campaign named for a service line describes your business, not a patient; the problems are objects that describe people.

Audiences

• List every custom audience; the assistant sees each one's name, subtype and size. A customer-file audience built from a patient list is a compliance problem before any AI touches it, because Meta's terms forbid sharing data based on health information. Take it to your privacy officer, not the assistant (see our customer list upload audit).
• Renaming does not fix an audience defined by a condition. "Past IVF patients" is either a patient list (see above) or a website audience built from IVF page visits; retire it, and use ads_get_custom_audience_adsets to see which ad sets still target it. Rename only audiences whose definition is neutral but whose name is not, such as a 180-day all-visitors audience called "IVF retargeting."
• Delete retired audiences by hand in Ads Manager.

Event names and custom conversions

The signals tools return dataset event names, pixel event rules and custom conversions. If an event is named for a treatment ("semaglutide_consult_booked"), or a custom conversion is defined on "/ivf/thank-you," the assistant sees the clinical label, and Meta already has it. Renaming hides the label from the next prompt. It does not recall a single event already sent.

The fix sits at the source. Curve forwards conversions through the Conversions API under a neutral alias, so the dataset the assistant inspects holds a generic event name, and only fields you explicitly mapped for Meta travel at all.

Campaign names and destination URLs come last: check both for condition terms and settle a naming convention; our guide to healthcare account structure in Ads Manager has one.

Which reports are safe to ask for

Ask aggregate, account-level questions. Good first prompts, with the read tool behind each:

• "Spend, impressions, CTR, CPC and conversions by campaign for the last 28 days, against the prior 28." (ads_get_ad_entities)
• "Which campaigns show unusual performance this week?" (ads_insights_anomaly_signal)
• "How have CPM and cost per result trended by week this quarter?" (ads_insights_performance_trend)
• "What is our Event Match Quality and match-key coverage, by channel?" (ads_get_dataset_quality, which needs the dataset access from Step 1), the best health check for server-side events.
• "What changed on this account in the last seven days?" (ads_account_get_activity_logs, which mirrors the Ads Manager campaign history page)

What to keep out of the chat

• Anything with a person in it. "Did Jane Doe convert from the retargeting ad?" invites the assistant to put a patient's name into a tool call to Meta. See where health data leaks in MCP tool calls.
• Pasted CRM or EHR exports. Pasting a patient list into the chat "to join with Meta data" is the most direct way PHI enters an ads conversation; no MCP setting prevents it. See why you cannot paste a patient funnel into an AI chat.
• Thin slices of condition-specific campaigns. Conversion breakdowns by age and region over three days can shrink to one or two people. Prefer weekly or longer windows and broad breakdowns.

How Curve keeps what Meta and the AI see non-clinical

The setup above controls actions. Curve's data layer controls content, before the MCP server runs a single query.

• What reaches Meta. Curve's tracking script installs in place of the Meta Pixel. Events land on Curve's US-hosted infrastructure first, and only fields you mapped for Meta are forwarded; by default, nothing goes. Identifiers are SHA-256 hashed, and each event carries a neutral alias, so the event names the MCP returns describe a conversion, not a treatment.
• What gets flagged. PHI-pattern detection flags PHI-shaped values in event data, such as SSN-like strings, MRN-style IDs, dates and long numeric sequences. It monitors rather than redacts; protection comes from field mapping and hashing.
• What the AI reads across platforms. Curve MCP reconciles your server-side campaigns: it puts each campaign's platform-reported spend, clicks and impressions next to the conversions Curve's server-side tracking recorded, with cost per conversion by completed week, and one link opens the full sent, accepted and matched view inside Curve. It works in Claude, ChatGPT, Cursor or any MCP client. It is read-only, withholds small groups, rounds counts, hides unapproved campaign names, and blocks any answer that looks like it contains an email, phone number, ID, date or name.

Every Curve plan includes a signed BAA (here is why it comes with every account). None of this makes Meta's MCP or your AI vendor HIPAA compliant. It keeps service lines out of the event names both of them see, and out of every field you leave unmapped.

A review routine that keeps it read-only

Settings drift as people join, accounts are added and Meta's tool list grows.

Weekly, about ten minutes

• Read the activity log for changes nobody made by hand. With all three locks in place, the connector's identity should never appear.
• Scan the client's tool-call history for write-tool attempts and prompts containing a name, phone number or email. The MCP specification says clients should log tool usage for audit; confirm yours does.
• Check for new custom audiences and custom conversions, and review any PHI-pattern flags Curve raised on event data.

Monthly

• Confirm every ad account, including any added since last month, carries a read-only MCP rule.
• Confirm the connector identity still has view-only access, and remove anyone who left.
• If you use a system user, rotate its token before the 60-day expiry and revoke unused ones.
• Re-list the client's tools and confirm every new write tool matches a deny pattern; one that does not arrives unblocked.

Write the configuration into your HIPAA policies. The Security Rule requires keeping that documentation for six years from creation or from when it was last in effect, whichever is later.

Frequently asked questions

Is Meta's ads MCP server read-only by default?

Do not assume so. Meta's documentation lists write tools for campaigns, audiences, pixels, catalogs and experiments, and describes read-only as a posture you choose through its ads MCP server rules.

Does a read-only setup make the Meta ads MCP HIPAA compliant?

No. Read-only governs what the assistant can do, not what data moves. Meta does not sign a BAA for its ad products, and Anthropic's BAA does not cover data sent to third parties through connectors. The defensible position is that no PHI crosses the connection at all.

Should we use a business user or a system user?

Use a dedicated business user through Facebook Login for Business; that is the path Meta documents. A regular system user with a 60-day token is an option only if you run your own Meta app and a tools/list call with that token succeeds. Either way, the identity gets view-only access and the ad account gets a read-only rule.

Should we use approval-required instead of read-only?

Not for the connector identity. Approval-required puts a click between the assistant and a write, and whoever clicks has to judge that call's arguments on the spot, so an audience upload or pixel rule change is one tired click away. Keep the connector read-only and make changes by hand in Ads Manager under a separate login.

Can an agency run this setup across client accounts?

Yes, with one identity per client business and rules set in bulk through the Marketing API. Meta requires app review for your own Meta app when you manage data for other businesses, so budget time for it.

Where to start

Start with the inventory, not the connector: fix audiences, custom conversions and event names that describe people or treatments, and run the free compliance scanner on your site as a baseline. Then scope the identity, set Meta's rule to read-only, run both test calls, and add the deny list.

If you want an assistant to answer what each campaign cost per conversion across Meta and Google, from figures built to be non-identifying, book a Curve MCP demo to see what it returns and withholds.

Reviewed September 2026. Meta's ads MCP server is in beta, so confirm current tool names in Meta's documentation before copying the deny list.