MCP Connector (Beta): public endpoint unreachable from ElevenLabs infrastructure (wr.simplybook.it/mcp/public)

Bug Reports
1

Account: patriciasofiahomeopatia
Feature: MCP Connector custom feature, “Public agent integration” (Beta)
Endpoint: https://wr.simplybook.it/mcp/public
Agent platform: ElevenLabs Agents (remote MCP server, Streamable HTTP, Authorization Bearer header)

What we are doing

We are connecting a booking assistant, a chatbot published on our website, to the public MCP endpoint. This is exactly the use case the panel describes: “issue an API key from this panel and paste it into your own server-side agent (for example a chatbot on your booking page)”.

What works

Using the API key issued in our account, from a browser and from other machines, the endpoint behaves correctly:

  • POST /mcp/public with method initialize returns 200 and serverInfo {"name":"sb-public-booking","version":"1.0.0"}
  • It negotiates protocol versions 2024-11-05, 2025-03-26 and 2025-06-18
  • notifications/initialized returns 202
  • tools/list returns 200 with the full catalogue (get_providers_list, get_provider_item, get_services_list, and others)

Endpoint behaviour we confirmed, for reference: transport must be Streamable HTTP and never SSE (GET /mcp/public returns 404); the key is only accepted in the Authorization header, never in a query string (403); Accept: application/json, text/event-stream is required (406 without it); responses come back as text/event-stream.

So the key is valid, the URL is correct, and the server works.

What fails

Every request issued from ElevenLabs infrastructure to wr.simplybook.it fails with “Failed to connect to MCP server”. We isolated the variables before reporting:

  1. Credential ruled out. Three different stored secrets, each tried over both Streamable HTTP and SSE, six combinations in total, all returning the identical error.
  2. Agent platform and response format ruled out. A different public MCP server (mcp.deepwiki.com/mcp) registered on the same ElevenLabs validation endpoint returns success with its tool list, and it also replies in text/event-stream, exactly like your endpoint.
  3. Configuration form ruled out. The MCP server was created through the ElevenLabs API, bypassing the “Test Connection” button, and the runtime tool listing fails the same way.
  4. Reachability probe. We submitted two URLs to an ElevenLabs feature that fetches pages from their own servers. https://example.com returned 197 bytes of real content. https://wr.simplybook.it/mcp/public returned 26 bytes, an empty HTML document, even though the same URL opened from a browser returns visible HTML text (“Cannot GET /mcp/public”). The control proves their fetcher works.

Conclusion: the host returns nothing usable to requests originating from ElevenLabs infrastructure, while the same requests succeed from anywhere else. We could not read server logs on either side, so we can confirm the effect but not the mechanism. Working hypothesis: a bot or data centre traffic protection in front of wr.simplybook.it.

What we are asking

Please allow requests from ElevenLabs infrastructure to reach https://wr.simplybook.it/mcp/public for our account, or tell us which egress addresses or user agent should be allow-listed, and by whom.

If there is a documented list of agent platforms the public MCP connector is expected to work with, we would like to see it. A public endpoint designed for embedded chatbots that rejects agent platforms is of limited use.

We can rerun any test you need and provide timestamps of the failing requests.

Note: live chat support directed us here, and the same report was also sent to support@simplybook.me.

3

Hi, could you please provide your public page URL for investigation and what exactly setings you use in the ElevenLabs?