mcp.exa.ai and api.exa.ai both return Cloudflare 403 from datacenter IP - self-hosting workaround from #414 does not work #446

Summary

The hosted Exa MCP endpoint https://mcp.exa.ai/mcp returns 403 for my network, so the MCP server never connects. This appears to be the same source-IP-based WAF block described in #414, but with a difference that breaks the workaround proposed there: api.exa.ai is blocked as well, so self-hosting exa-mcp-server does not help.

Steps to reproduce

1. Configure https://mcp.exa.ai/mcp as a remote MCP server (streamable HTTP), per the docs.
2. Send POST /mcp with an initialize request:

POST https://mcp.exa.ai/mcp
Accept: application/json, text/event-stream
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}

3. Observe HTTP 403 with Server: cloudflare and an HTML "Attention Required!" interstitial. No MCP JSON-RPC response, no mcp-session-id.

Actual results

The response carries no cf-mitigated header, only the challenge page. The block happens before any MCP or API logic, and is unaffected by auth, User-Agent, or protocol version.

Impact on the self-hosting workaround

#414 suggests documenting that the hosted endpoint rejects datacenter egress and recommends self-hosting exa-mcp-server because "it calls api.exa.ai directly and is unaffected". For my network that recommendation does not hold: api.exa.ai is behind the same WAF and also answers 403, so a local npx -y exa-mcp-server would fail in the same way. There is currently no path to any Exa functionality from this network.

Environment

• Client: OpenCode (remote MCP, streamable HTTP)
• OS: Windows 11, PowerShell
• Cloudflare edge: CF-RAY: a41fab590d65f111-DME
• Client IP: 8.47.69.0 / 8.6.112.0 (hosting/datacenter range)

Questions

1. Is api.exa.ai covered by the same WAF rule as mcp.exa.ai? If so, is the self-hosting path in [Bug] MCP endpoint returns HTTP 403 for clients running on Cloudflare Workers egress #414 still valid for any client?
2. Is there a documented allowlist, alternative hostname, or proxy/region-specific endpoint for clients on datacenter IP ranges?
3. Can authenticated requests (valid Authorization / x-api-key) be evaluated before the block, so keyed clients are not rejected?

Workaround

None available from this network. The only resolution on my side is a residential/VPN egress.