claude-code - 💡(How to fix) Fix MCP gateway WAF blocks legitimate tool-call bodies (SQL/shell/config text)

Summary

When a remote MCP server tool is invoked through the claude.ai MCP integration, tool calls whose request body contains ordinary technical text — SQL keywords (e.g. SELECT), shell command chains (cmd && cmd), literal .env, 0.0.0.0, file paths — are blocked by Cloudflare with a generic "Sorry, you have been blocked" interstitial.

The block originates on Anthropic's edge (the block page reads "You are unable to access anthropic.com"), i.e. the gateway that proxies the outbound MCP call — not the destination MCP server. A managed WAF SQLi/RCE/LFI ruleset (plus an anomaly-score threshold) appears to be inspecting the MCP tool-call body and treating legitimate note/code content as an attack.

Evidence

• The destination MCP server sits behind its own Cloudflare zone. Querying that zone's firewallEventsAdaptive over the failure window returned only action: skip events (the operator's own rule) and zero block/challenge events — so the destination did not block anything.
• The returned page is the standard Cloudflare interstitial naming anthropic.com, confirming the block is served upstream by Anthropic's Cloudflare.
• Consistent with managed-WAF body inspection: small bodies succeed; bodies containing SQL/shell tokens fail; splitting the same content into smaller chunks, or rewording to drop the tokens, succeeds.

Reproduction

1. Connect a remote MCP server that exposes a write/append tool (e.g. an Obsidian or notes MCP server) to claude.ai.
2. Call the write tool with a body containing, for example:
   • a fenced bash block with python3 -m venv .venv && .venv/bin/pip install ... and cp .env.example .env
   • a sentence like "the guard allows a single read-only SELECT only".
3. Observe the Cloudflare block page (referencing anthropic.com). Removing the tokens or splitting into smaller appends lets the same content through.

Impact

• Legitimate developer/KB content — code snippets, SQL, shell commands, config files — cannot be reliably written to MCP servers through claude.ai.
• Affects any MCP server accepting document/text bodies: note-taking, wikis, knowledge bases, code/dev tools.
• The failure is opaque: the client receives a generic HTML block page, not a structured error, so it looks like the destination server is down.

Expected behavior

MCP tool-call arguments are authenticated, structured data destined for the user's own server. They should be treated as opaque payload, not scanned by a public-web SQLi/RCE ruleset as if they were an attack on Anthropic's infrastructure.

Suggested fixes

• Exclude the MCP gateway proxy path from the managed WAF SQLi/RCE/LFI body-inspection ruleset (or scope that ruleset to Anthropic's own surfaces rather than pass-through MCP bodies).
• If inspection must remain, return a structured error to the MCP client ("request body rejected by gateway security policy") instead of the generic HTML block page, so clients can surface an actionable message instead of a transport failure.

Environment

• Claude Code (model Opus 4.8, 1M context).
• claude.ai MCP integration → remote MCP server behind a Cloudflare tunnel.
• Confirmed the destination/operator-side WAF is not the cause (skip-only events on that zone).

Note: this likely needs routing to the claude.ai / MCP gateway team rather than the Claude Code CLI itself — filing here as the closest public Anthropic tracker.