How to Verify an Ads MCP Server Is Safe Before You Connect
You can check most of an ads MCP server's security posture from a browser in about ten minutes, before any OAuth screen appears. Run seven checks against the server's domain: two OAuth discovery files, a security.txt, an MCP server card, a published write-gating model, a session revocation path, and a registry cross-check. This guide shows each check against PaidSync's live URLs so you can see exactly what a pass looks like, all fetched on August 1, 2026.
None of these checks require a developer. Every one of them is a URL you paste into a browser or a phrase you search for in public docs. If a server fails the first four, you have nothing to verify, and that absence is itself the answer.
Two Incidents That Explain Why This Page Exists
postmark-mcp, September 2025, the first malicious MCP server in the wild
Researchers at Koi Security found an npm package called postmark-mcp that impersonated Postmark's real email library. From version 1.0.16, it added one line of code that blind-copied every email sent through it to an attacker's address. It was downloaded 1,643 times before removal. Full report at The Hacker News.
The detail that matters for advertisers: postmark-mcp would have passed zero of the checks below, because a locally installed npm package publishes no security posture at all. No OAuth discovery, no security contact, no server card, no registry-verified domain. The attack worked through name impersonation, and there was nothing at a fixed address to compare the name against. Remote MCP servers that publish discovery documents give you something no npm install ever gives you: verifiable claims at URLs the operator cannot quietly vary per visitor.
The second incident is murkier, and honesty requires saying so. In spring 2026, ad executives claimed in online discussions that their Meta ad accounts had been restricted or banned after integrating AI tools. Digiday reported on April 29, 2026 that "no official link between the two has been confirmed," and Meta has published no statement connecting ad-account enforcement to any AI tool. Treat the ban wave as unproven. But notice the shape the claimed cases shared: raw API tokens, agents running unattended, no approval step between the model and the live account. Checks 5 and 6 below exist to rule out exactly that shape before you connect anything.
The Seven Checks at a Glance
Each check is a URL or a documented behavior. The right column is PaidSync's live result so you can see a passing state, not because passing these checks is unique to PaidSync. Any well-run ads MCP server can and should pass all seven.
| Check | Where to look | PaidSync result (Aug 1, 2026) |
|---|---|---|
| 1. OAuth server metadata | /.well-known/oauth-authorization-server | 200, JSON, PKCE S256 |
| 2. Protected resource metadata | /.well-known/oauth-protected-resource | 200, JSON, read and write scopes split |
| 3. security.txt | /.well-known/security.txt | 200, contact + Expires 2027 |
| 4. MCP server card | /.well-known/mcp/server-card.json | 200, auth required, PKCE required |
| 5. Write-gating model | Public docs, named mechanics | dry_run + confirm_destructive documented |
| 6. Session revocation | Docs or dashboard | Revoke anytime from dashboard |
| 7. Registry consistency | Official MCP registry | Active listing, domains match card |
Check 1. The OAuth Server Metadata File
Paste this pattern into a browser, swapping in the server's domain:
https://<server-domain>/.well-known/oauth-authorization-serverRFC 8414 defines this file. It is the server declaring, at a fixed address, how it does OAuth: where its authorization and token endpoints live, which grant types it supports, and whether it requires PKCE (the code-interception protection, look for S256 under code_challenge_methods_supported). A server that has this file is doing standards-track OAuth. A server that lacks it is handling your access some other way, often by asking you to paste long-lived raw tokens, which is the pattern behind most of the 2026 horror stories.
PaidSync's live file, fetched August 1, 2026:
https://paidsync.ai/.well-known/oauth-authorization-serverCheck 2. The Protected Resource Metadata File
RFC 9728 is the companion file: the resource declaring which authorization servers may issue tokens for it and which scopes exist. Two things to read here. First, whether read and write are separate scopes, because separation means the server can grant reporting access without granting mutation access. Second, whether the domains listed match the endpoint you are about to configure in Claude or ChatGPT. The current MCP authorization model builds on these two discovery documents, and the 2026-07-28 MCP specification tightened authorization further.
PaidSync's live file, fetched August 1, 2026:
https://paidsync.ai/.well-known/oauth-protected-resourceCheck 3. The security.txt File
RFC 9116 defines the file where an operator publishes how to report a vulnerability. Look for a Contact line and an Expires date in the future. An expired date means nobody is maintaining it. A missing file means a researcher who finds a hole in the server holding your ad accounts has no sanctioned way to tell anyone. This is a thirty-second check and it filters out a surprising share of hobby-grade servers.
PaidSync's live file, fetched August 1, 2026:
https://paidsync.ai/.well-known/security.txtCheck 4. The MCP Server Card
The server card is the server describing itself in machine-readable form: name, endpoint, documentation, and how authentication works. Read three fields. Does authentication.required say true? Does the OAuth method point back at the discovery files from checks 1 and 2? Does the endpoint domain match where you are actually connecting? A card that requires no authentication for an ads server is a red flag on its own, because an unauthenticated endpoint in front of ad accounts should not exist.
PaidSync's live card, fetched August 1, 2026:
https://paidsync.ai/.well-known/mcp/server-card.jsonWant to see a passing server from the inside? The free tier is 15 tool calls a month, no card required.
Get started for free How the MCP server worksCheck 5. A Published Write-Gating Model
Anyone can write "enterprise-grade security" on a landing page. What you are looking for is different: docs that name the specific mechanics gating writes, because named parameters are testable claims. Search the server's public documentation for terms like dry_run, approval, and confirmation for destructive actions. If the docs never name a gating mechanism, assume writes are ungated and behave accordingly.
PaidSync's published model, all fetched August 1, 2026: paidsync.ai/auth.md states that every write action is approval-gated. The Meta bulk operations documentation names both mechanics: a dry_run preview is available on most write tools so you can inspect the planned change before confirming, and a confirm_destructive pattern applies to any action that modifies live campaigns. Read actions never require confirmation.
Check 6. A Session Revocation Path
Before you connect, know how you disconnect. The question: can you cut this server's access in under a minute, without rotating your ad platform password? A trustworthy server gives you two layers. Tool side, a dashboard where sessions and keys can be revoked. Platform side, because the connection is OAuth-based, you can also sever it from Google's or Meta's own security settings. Servers that instead ask you to paste long-lived raw API tokens fail this check structurally: your only remedy is credential rotation, which is slower and easier to forget.
PaidSync's published path, fetched August 1, 2026: paidsync.ai/connect-mcp states that access can be revoked anytime from your PaidSync dashboard.
Check 7. Registry Listing Consistency
Look the server up in the official MCP registry and compare what the registry says against the server card from check 4:
https://registry.modelcontextprotocol.io/v0/servers?search=paidsyncSwap the search term for any server you are evaluating. What must match: the endpoint domains and the authentication method. PaidSync's registry entry, fetched August 1, 2026, is active, was published April 8, 2026, points at mcp.paidsync.ai, and marks the API key as required and secret. All of that agrees with the server card.
One honest wrinkle worth learning from: the registry entry's description still carries its April snapshot text, mentioning 200+ tools, while the live server card reflects the current catalog of 430+ tools (438 live) across 13 platforms. That is what benign drift looks like. Descriptions and counts age between registry updates. Domains do not. A stale number is cosmetic; a mismatched domain is how impersonation works, and postmark-mcp was exactly a name-impersonation attack. Match the domains, and treat any disagreement there as disqualifying.
What About Just Using the Official MCP
A fair objection: why verify third parties at all when Google ships its own MCP server? Because of what the official server is. Google announced its open-source Google Ads API MCP server on October 7, 2025 on the Google Ads Developer Blog, and the repository exposes three tools: search, resource metadata, and an accessible-customers list. All reads. No pause, no budget change, no negative keyword, no mutation of any kind.
That makes the official server genuinely safe for reporting, and genuinely incapable of execution. The moment you want an AI to act on what it finds, you are choosing a third-party server whether you planned to or not. Meta, for its part, is opening its ad ecosystem to third-party AI tools, as Digiday covered in April 2026. So "just use the official one" does not remove the verification problem. It narrows it to the exact category where verification matters most: servers that can write. Running Google's read-only server for diagnostics alongside a verified write-capable server is a reasonable pairing, not a contradiction.
What This Checklist Does Not Do
Honest limits, read before relying on this
These seven checks verify posture, not code. A passing server has done verifiable security work in public, which correlates with doing the invisible work too, but it is not proof of it. The checklist cannot audit a server's internals, cannot scan its dependencies, and cannot promise that an ad platform will never flag automated activity on your account. It also barely applies to locally installed npm-based MCP servers, which publish none of these documents; for those, your protections are package provenance and dependency scanning, a different discipline. And on PaidSync specifically, so the same standard applies here: Search Console tools are read-only, and TikTok, Microsoft, Snapchat, Reddit, and Pinterest support managing and optimizing existing campaigns but not creating new ones. A checklist this page's author passes is still a checklist you should run yourself. The URLs are all above.
Fails checks 1 through 4: do not connect an account with real spend. There is nothing to verify, and that absence is the finding.
Passes 1 through 4, silent on 5: reporting only. Do not grant write scope to a server whose docs never name their gating mechanics.
Passes all seven: a defensible setup. Keep approval gates on, start with read scope, widen deliberately.
Frequently Asked Questions
Is it safe to connect Claude to my ad account?
It depends entirely on the server in the middle, not on Claude. Claude talks to your ad account through an MCP server, and that server holds the access. Before connecting, run the seven browser checks above: the two OAuth discovery files, a security.txt, an MCP server card, docs that name their write-gating mechanics, a session revocation path, and a consistent listing in the official MCP registry. A server that passes all seven, with every write gated behind human approval, is a defensible setup. A server that fails the first four gives you nothing to verify, which is your answer.
What is an MCP server card and where do I find it?
A machine-readable JSON file a remote MCP server publishes at /.well-known/mcp/server-card.json describing what the server is: name, endpoint, documentation, and how authentication works. You read it by pasting the URL into a browser. PaidSync's card at paidsync.ai/.well-known/mcp/server-card.json declares 430+ tools across 13 platforms, marks authentication as required, and requires PKCE for its OAuth flow. If a remote ads MCP server has no card and no OAuth discovery files, you are connecting to an endpoint that tells you nothing about itself.
Can an ads MCP server change my campaigns without asking me?
Technically yes, if the server exposes ungated write tools and you granted write scope. That is why check 5 exists: the docs must name their gating mechanics. PaidSync gates every write action behind approval (stated at paidsync.ai/auth.md), supports dry_run previews on most write tools, and applies a confirm_destructive pattern to actions that modify live campaigns (documented at paidsync.ai/docs/meta-bulk-operations). If a server's docs only say "secure" and "safe" without naming a parameter you could test, assume writes are ungated.
What was the postmark-mcp incident?
In September 2025, researchers at Koi Security found the first confirmed malicious MCP server in the wild: an npm package called postmark-mcp that impersonated Postmark's real library. From version 1.0.16 it added one line of code that blind-copied every email sent through it to an attacker's address. It was downloaded 1,643 times before removal, per The Hacker News. The lesson for advertisers: the package passed zero verifiable checks because locally installed packages publish no security posture at all. Remote servers with published OAuth discovery files, a security.txt, and a registry listing give you something to verify before you connect.
Did Meta ban advertisers for connecting AI tools in 2026?
Unconfirmed. In spring 2026, some ad executives claimed in online discussions that their Meta ad accounts were restricted or banned after integrating AI tools. Digiday reported on April 29, 2026 that no official link between the two has been confirmed, and Meta has published no statement connecting ad-account enforcement to any AI tool. What the claimed cases shared was a shape: raw API tokens, unattended agents, no approval step. Approval-gated writes and revocable sessions (checks 5 and 6) are built against exactly that shape.
Is the official Google Ads MCP server safer than a third-party one?
It carries less write risk because it cannot write. Google's open-source Google Ads API MCP server, announced October 7, 2025, exposes three tools in its repository: search, resource metadata, and an accessible-customers list. All reads, no mutations. That makes it a solid reporting companion and a poor executor. The moment you want an AI to actually pause an ad, add negatives, or shift budget, you are choosing a third-party server, and that is precisely when this checklist matters most.
How do I revoke an MCP server's access to my ad accounts?
Two layers. Tool side: a trustworthy server lets you revoke sessions and keys from its own dashboard; PaidSync states at paidsync.ai/connect-mcp that access can be revoked anytime from the PaidSync dashboard. Platform side: for any OAuth-based tool you can also cut access from the ad platform itself, in Google's security settings under third-party access and in Meta's Business settings under integrations. Tools that instead ask you to paste long-lived raw API tokens leave you rotating credentials, which is slower and easier to forget.
Related Reading
Best MCP for Ads Management Category guide → Connect Your Ad Accounts to Claude Setup guide → Meta bulk operations, the dry_run and confirm_destructive docs Documentation →Run the seven checks on PaidSync yourself, then connect on the free tier. 15 tool calls a month at $0, Pro from $99/mo when you outgrow it.
Get started for free See pricing