MCP Security Checklist for Marketers: 7 Questions Before You Install Any MCP Server

Why MCP security matters more in 2026

MCP (Model Context Protocol) lets AI assistants like Claude and ChatGPT connect directly to external data sources and tools. For marketers, that means an AI can now read your live Google Ads spend, edit your Meta campaigns, pull GA4 reports — without a manual export. Powerful. Also: a much wider attack surface than a static dashboard tool.

Three things changed in 2026 that raised the stakes:

• CVE-2026-30623 (April 16, 2026): The Register reported around 200,000 MCP servers were vulnerable to RCE through the STDIO transport. The Register coverage framed it as a design flaw, not a bug.
• Cloud Security Alliance MCP Security Crisis note (May 4, 2026): A research note arguing that 53% of MCP servers use hardcoded secrets and only 8.5% use OAuth.
• Anthropic's response: Updated SECURITY.md saying STDIO "should be used with care." Many security researchers read this as a non-fix.

If you're a marketer, you don't need to understand STDIO vs HTTP transport — you need a checklist that maps to questions you can actually ask the vendor.

The 7 questions to ask before installing

1. Is auth handled by OAuth 2.0, or are you pasting an API key into a config file?

OAuth lets you revoke access from Google's account settings or Meta Business Manager. API keys in config files sit on your laptop — if your machine is compromised, every connected platform is exposed. OAuth-only MCPs are materially safer. Per CSA, only 8.5% of MCPs use OAuth properly. Ask explicitly: "Does setup require pasting an API key anywhere?"

2. Does the MCP server run locally (STDIO) or remotely (HTTP/SSE)?

STDIO transport — the one with the disclosed RCE vulnerability — runs the MCP server as a local process on your machine. Remote HTTP/SSE servers run on the vendor's infrastructure. Both have tradeoffs, but post-CVE-2026-30623, remote-hosted MCPs from established vendors carry less individual risk. Ask: "Is this a local STDIO install or a hosted endpoint?"

3. What data does the MCP actually store?

Good answer: "Nothing — we pull data on demand and respond, no persistence." Bad answer: "We cache your data for 24 hours to improve performance." If a vendor stores your marketing data, every breach of theirs becomes a breach of your data. Pull-on-demand is the safer architecture.

4. Can you list the exact scopes the OAuth flow requests?

For Google Ads, "read campaigns" is very different from "manage campaigns." For Meta, "ads_read" is different from "ads_management." A well-built MCP requests minimum scopes and asks for elevated scopes only when you use a feature that needs them. Look at the OAuth consent screen — if it asks for "manage" scopes for what should be read-only, that's a signal.

5. Where are tokens stored, and how are they encrypted at rest?

OAuth tokens are credentials. They should be encrypted at rest, scoped to your account only, and revocable. Ask: "If your database leaked tomorrow, what would happen to my Google Ads access?" The right answer involves token rotation policies and segmented per-user encryption.

6. Has the vendor published a security disclosure policy?

A vendor that takes security seriously has a public security@ email, a responsible disclosure policy, and ideally a posted history of past incidents. A vendor that handwaves this is a vendor that won't tell you when something breaks.

7. Can you revoke access without contacting support?

For OAuth MCPs, revocation should be a one-click action — either from the vendor's settings or directly from your Google/Meta account. If the answer is "email us and we'll disconnect within 48 hours," that's a serious problem during an active incident.

Red flags that disqualify an MCP automatically

• Setup instructions involve pasting an API key, refresh token, or OAuth token into a .env file or settings.json
• No published privacy policy or data retention statement
• STDIO-only transport with no remote alternative (post-CVE-2026-30623)
• Vendor cannot tell you which OAuth scopes they request
• Marketing copy promises "we use your data to train our model" or any training mention
• No way to disconnect without contacting support
• Github repo with hardcoded credentials in any historical commit (check the commit log)

How we built 1ClickReport's MCP (the not-marketing version)

We're an MCP server, so this section is unavoidably about our own stack. Take it for what it is. Our setup:

• OAuth 2.0 for every integration — Google Ads, GA4, Search Console, Meta Ads, Stripe, Keyword Planner. No API keys, no manual token pasting.
• Remote HTTP transport at mcp.1clickreport.com — no STDIO. If CVE-2026-30623 had been an HTTP transport bug we'd have rotated and notified. STDIO wasn't applicable.
• Pull-on-demand, no data storage. Your marketing data hits our server, gets queried against the platform APIs, and returns to your AI client. We don't persist it.
• Minimum scopes by default, elevated only on Premium. Pro is read-only — we request analytics.readonly, adwords:read, etc. Premium adds adwords:manage only when you opt in to campaign management.
• Per-account revocation. Disconnect from your Google Ads account settings or your Meta Business Manager — no email needed.

None of this makes us automatically safe. It just maps to the right answers on the 7-question checklist. Run the same checklist on every MCP you're considering, including ours.

One additional check: your AI client itself

The MCP server is one half of the equation. The other half is your AI client (Claude Desktop, Claude Code, ChatGPT, Cursor) and how it stores and routes MCP credentials. Verify:

• Is the AI client app sandboxed (Claude Desktop) or running with full system access (some Cursor/Continue setups)?
• Where does the client store MCP server config and tokens — keychain, a plaintext file, or environment variables?
• Does the client log MCP responses to disk? If yes, an attacker with disk access has your marketing data.

For high-sensitivity environments (agencies handling client accounts), the safest setup right now is: hosted-MCP + OAuth + Claude Desktop with keychain-backed credential storage. That covers most of the realistic attack surface.

Frequently Asked Questions