Key takeaways
- Nearly 39% of the 1,400 MCP servers Bloomberry analyzed had zero authentication, meaning anyone who found the endpoint could enumerate every tool, including sensitive write actions, with no login at all.
- Marketing-focused MCP servers (the ones that power your AI visibility dashboards) vary wildly in scope: Otterly.AI exposes 17 tools, LLM Pulse exposes around 90, and some vendors haven't published a tool count at all.
- The single most useful test you can run before connecting is sending an unauthenticated tools/list request to the MCP endpoint. A proper 401 with resource metadata is good news. A server that just hands over its tool catalogue to anyone is a red flag.
- "Listed in Anthropic's Connectors Directory" and "verified by Anthropic" are not the same claim. Most listed connectors are still just community-reviewed.
- Least privilege matters more than brand reputation. Ask what scopes the token actually grants, not just whether the vendor says it's secure.
Why marketers suddenly have to care about this
A year ago, nobody in marketing was reading OAuth specs. Then AI visibility tools started shipping MCP servers so ChatGPT, Claude, or your own internal agent could pull prompt data, citation trends, and competitor rankings directly into a chat window. That's genuinely useful. It's also a new kind of access grant that most marketing teams have never had to evaluate.
Here's the thing that makes this different from connecting, say, a Zapier integration: an MCP server doesn't just return data when asked. It describes its own capabilities to the AI model, and the model decides what to do with that description. If the description is wrong, outdated, or has been quietly altered, the model can be steered into doing things nobody approved. That's not a hypothetical. It's already happened to GitHub's own MCP integration, where a prompt injection flaw let attackers trick agents into reading private repositories and leaking the contents through a public pull request, no server breach required.
So when a vendor says "connect our MCP server to Claude or ChatGPT," you're not approving a data feed. You're approving an autonomous agent's access to your tools, possibly with write permissions, authenticated by a token that may or may not be scoped the way you think it is.
What actually goes wrong
It helps to know the failure modes before you start reading vendor docs, because the marketing copy rarely mentions any of this.
No authentication at all
Bloomberry's analysis of 1,400 public MCP servers found 38.7% had no authentication whatsoever. Anyone who found the endpoint could start a session and list every tool. Among the no-auth servers they found, tool names included things like create_refund, confirm_transfer, and get_kyc_status, write-capable actions sitting wide open. That study wasn't about marketing tools specifically, but it tells you how common sloppy defaults are across the MCP ecosystem generally, including in tools your team might be evaluating.
Long-lived static secrets instead of real OAuth
Astrix's 2025 research on more than 5,000 MCP servers found that while 88% require some form of credential, 53% rely on insecure long-lived API keys or personal access tokens rather than OAuth, and only 8.5% use OAuth, the more modern and preferred method. Static keys are a problem because they don't expire, they're often pasted into config files in plain text, and if one leaks, it keeps working until someone notices and manually revokes it.
Token passthrough and the confused deputy problem
The MCP authorization spec explicitly warns against a failure mode where a server receives a token meant for itself and then passes that same token upstream to another API. If a server does this, a token stolen or misused in one context can be replayed somewhere else entirely. The 2025-06-18 spec revision tried to close this by requiring resource indicators, binding a token explicitly to the server it was issued for, but not every vendor has caught up.
Tool poisoning and "rug pulls"
This one is subtle and worth sitting with for a second. Most MCP clients approve a tool once, based on its description, and then don't re-check that description on every subsequent call. A malicious or compromised server can change what a tool actually does after approval, silently, without triggering a new consent prompt. Researchers call this a rug pull. It means the "safe" tool you approved in week one might not be doing the same thing in week six.
Permission sprawl across multiple connected servers
Most marketing and ops people I've talked to run several MCP servers at once, their AI visibility tool, maybe a CRM connector, maybe an internal docs server. Zuplo's research on MCP builders found most users run two to seven servers simultaneously. The risk isn't any single server's scope, it's the union of all of them. A model with read access to your CRM and write access to your CMS can, in theory, chain actions across both in ways no single permission grant anticipated.
The practical checklist before you connect
I'll be honest, most of this is not glamorous. It's five minutes of reading docs and one technical test, but it's five minutes that most teams skip.
1. Run the unauthenticated tools/list test
If you or someone technical on your team can send a plain tools/list call to the vendor's published MCP endpoint without a token, do it. A well-built server responds with a 401 and resource metadata pointing to a proper OAuth flow. A poorly built one just answers and hands over its entire tool catalogue to anyone who asks. This single test, used by reviewers comparing AI visibility MCP servers in mid-2026, separates the vendors who took authorization seriously from the ones who bolted MCP on as an afterthought.
2. Check the authentication method, not just that one exists
Ask specifically: is it OAuth 2.1 with protected resource discovery, or is it a pasted API key living in a config file? Among AI visibility vendors compared in late 2026, Profound, Otterly.AI, Semrush, SE Ranking, and LLM Pulse have all moved to OAuth as the primary flow in the past year. That's a reasonable baseline to expect from anyone in this category now.
3. Read the actual scope of the token, not the marketing description
"Connects your AI visibility data" could mean read-only access to prompt rankings, or it could mean write access to create projects, delete prompts, launch recommendation runs, and register webhooks. LLM Pulse, for example, exposes close to 90 tools including a mix of read and write actions, create projects, bulk-add prompts, manage competitors and tags, launch recommendation runs, start technical GEO reports. Otterly.AI's surface is much smaller, 17 tools total, 11 read and 6 write, mostly scoped to prompt and tag management. Neither is wrong, but they're not the same risk profile, and you should know which one you're authorizing.
4. Ask whether write actions require confirmation
Some vendors build in a safety net: the server instructs the connected assistant to confirm quota-spending or destructive actions with a human before executing. Others don't bother. This matters a lot more once you've connected several servers and the model is making multi-step decisions across all of them without you watching every call.
5. Don't confuse "listed in a directory" with "verified"
Anthropic's Connectors Directory review checks things like who owns the API, how users authenticate, and whether write actions are properly marked. But most accepted servers start life as community connectors. Verified status is a separate, later step that not every listed connector gets. If a vendor says "we're in the Anthropic directory," that's a fine starting signal, but it's not the same claim as "Anthropic verified our security."
6. Check whether MCP access is even available on your plan tier
This sounds mundane but it changes the conversation internally. Otterly.AI gates MCP and API access to its Standard tier ($189/mo) and above, it's not available on the entry Lite plan. Profound, after restructuring its pricing in mid-2026, no longer publishes self-serve plans at all, MCP access there appears to be an enterprise-negotiated feature. Know what you're actually buying before you promise your security team a specific integration.
Comparing MCP security posture across AI visibility vendors
| Vendor | Tool count (approx.) | Auth method | Write actions exposed | MCP access tier |
|---|---|---|---|---|
| LLM Pulse | ~90 | OAuth 2.1, dynamic client registration or API key | Yes, with safety hints on destructive actions | Not publicly gated by plan |
| Profound | Not fully published | OAuth | Yes, prompts, agents, docs, projects | Enterprise only (as of late 2026 restructuring) |
| Otterly.AI | 17 (11 read, 6 write) | OAuth 2.0 | Yes, prompt and tag management | Standard tier ($189/mo) and up |
| SE Ranking | ~40 of 180+ touch AI search | OAuth 2.1 or API key | Mixed | Varies by plan |
| Semrush | Not published | OAuth 2.0 or API key | Not detailed | Varies by plan |
| Ahrefs | ~22, read-oriented | OAuth | Minimal, mostly read | Varies by plan |
Note the pattern: the vendors who've published clear tool counts and safety hints are, generally, the ones who've thought hardest about this. A vendor that can't tell you how many tools its server exposes probably hasn't audited it closely either.
If you're using Promptwatch or evaluating it alongside these, the same questions apply, ask what scopes its MCP server and API tokens request, whether write actions (like triggering a Content Agent publish to your CMS) require a confirmation step, and whether access is tied to OAuth rather than a static key. Promptwatch's MCP and API access sits alongside its broader platform, which already connects to Webflow, Framer, and WordPress for publishing, so understanding exactly which scopes are in play before granting access matters just as much here as with any other vendor.
Questions to ask your vendor directly
Bring these to a sales call or a security review. If the answers are vague, that's data too.
- What authentication method does your MCP server use, OAuth with protected resource discovery, or a static API key?
- Can you show us the full list of tools your server exposes, and which ones are read versus write?
- Does your server require explicit confirmation before executing destructive or quota-spending actions?
- How do you prevent token passthrough, meaning does our token ever get forwarded to another upstream service?
- Are tool descriptions signed or version-pinned so a change can't happen silently after we've already approved the connection?
- If our token is compromised, what's the blast radius, just this tool's data, or does it touch other connected systems?
- Is your server listed in Anthropic's Connectors Directory as community-reviewed, or has it been elevated to verified status?
A short note on internal process
None of this needs to become a six-week security review. Most marketing teams don't have a dedicated AppSec person reviewing every SaaS connection, and that's fine, but MCP connections deserve slightly more scrutiny than a typical OAuth "sign in with Google" button, because the agent on the other end is making autonomous decisions, not just fetching a dashboard.
A reasonable middle ground: treat any MCP connection request that includes write permissions as something that needs a second person's sign-off, even if that second person is just your ops lead glancing at the scopes list for two minutes. Treat read-only connections with lower friction. And revisit the connection list every quarter, because permission sprawl creeps in quietly, one "just connect it and we'll figure it out later" at a time.
If you want to see how AI visibility platforms stack up more broadly, not just on security but on what they actually track and how they help you act on it, the GEO software directory at bestgeosoftware.com and the AI rank tracking comparisons at ai-rank-tools.com are reasonable places to cross-check vendor claims before you sign anything.