Connector-edge Cloudflare WAF false-positives on benign MCP tool-call arguments

Summary

Tool calls made through claude.ai MCP connectors (mcp__claude_ai_*) are relayed as HTTPS POSTs to anthropic.com, which is fronted by Cloudflare. Cloudflare's managed WAF inspects the POST body — which includes the tool-call arguments — and blocks the request when those arguments contain attack-looking text, even when the text is entirely benign (e.g. a shell command being run, or a memory/note value that merely describes an attack pattern).

The block is returned to the MCP client as an opaque Streamable HTTP error: Error POSTing to endpoint, with a Cloudflare HTML interstitial as the body ("Sorry, you have been blocked … You are unable to access anthropic.com").

Impact

• Legitimate security-engineering and sysadmin workflows are disproportionately affected — the payloads a security review or server-hardening task naturally produces (commands, request samples, notes describing vulnerabilities) are exactly what the WAF flags.
• The failure surfaces as a generic transport error with no indication it's a WAF block, which makes it very hard to diagnose. It initially looks like an MCP/network fault.
• A trivial workaround exists (base64-encode the payload so the WAF can't pattern-match it), which means the rule mostly inconveniences honest callers while being easy to bypass.

Confirmed trigger strings (inside tool arguments)

• A curl invocation against a TLS URL.
• A raw HTTP request line — method + path + version on one line (e.g. what you'd pipe into openssl s_client to test a vhost).
• Some scanner-style path tokens.

Non-triggers (run fine through the same path): ordinary ls / grep / sed / dig / ss, quoted file paths, and base64-encoded payloads.

Reproduction

1. Use any claude.ai-connector MCP run_command-style tool.
2. Pass an argument that contains a curl https://…-style string, or a raw GET / HTTP/1.1-style request line, or describe one in a memory_write-style value.
3. The request is blocked at the Cloudflare edge before reaching the MCP server; the client sees Streamable HTTP error: Error POSTing to endpoint + a Cloudflare block page.

Cloudflare Ray IDs (to locate in Anthropic's edge logs)

a04ae8b6de42ae18
a04aebff4a2cae18
a04aedeb2cc5ae18
a04aeebd6895ae18
a04b102438cf4b56

Suggested fixes

• Scope the managed WAF ruleset to skip the connector relay / tool-call path, or relax request-body inspection on that endpoint.
• At minimum, surface WAF blocks as a distinct, diagnosable error (e.g. an explicit "blocked by upstream WAF" message) instead of a generic streamable-HTTP transport failure, so callers aren't left chasing a phantom network/MCP bug.

Environment

• Claude Code with remote MCP connectors registered via claude.ai (mcp__claude_ai_*).
• Connectors include a run_command-style server and the MemoryManagement memory store; both exhibit the behavior, confirming it's the shared connector relay path rather than any one server.