ElevenLabs MCP connector: all Text_To_Speech tools return 404 (request mis-constructed; endpoint verified correct via direct curl)

Summary

Every text-to-speech tool in the hosted ElevenLabs MCP connector returns 404 {"detail":"Not Found"}, while the underlying ElevenLabs REST endpoint is confirmed working. The connector is mis-constructing the TTS request (most likely not substituting voice_id into the URL path /v1/text-to-speech/{voice_id}), producing a route-not-found. This is not a permissions or API-key issue (verified below).

Note: This supersedes #63811, which I opened and closed earlier with an incorrect root cause (I wrongly blamed a missing text schema param, then a scoped key). This issue has the corrected, proven diagnosis.

Affected tools

All three synthesis tools fail identically:

• mcp__elevenlabs__Text_To_Speech
• mcp__elevenlabs__Text_To_Speech_Streaming
• mcp__elevenlabs__Text_To_Speech_With_Timestamps

Non-synthesis tools on the same connector work fine (e.g. List_Voices returns 559 voices), so auth/HTTP plumbing is healthy — the defect is specific to the TTS request construction.

Evidence

| Call | Result |
|------|--------|
| List_Voices (same connector) | ✅ 200, 559 voices |
| Text_To_Speech (voice_id + text) | ❌ 404 {"detail":"Not Found"} |
| Text_To_Speech (no output_format) | ❌ 404 (identical) |
| Text_To_Speech (second, different voice_id) | ❌ 404 (identical — not voice-specific) |
| Text_To_Speech_Streaming | ❌ 404 (identical) |
| Text_To_Speech_With_Timestamps | ❌ 404 (identical) |

The error is a generic {"detail":"Not Found"} (Starlette default for an unmatched route), not ElevenLabs' structured error object — indicating the request hits a URL that doesn't exist on the server.

Proof the endpoint + request shape are correct (not the key)

Direct curl to the identical endpoint, no API key — isolates request-shape from auth:

curl -sS -X POST "https://api.elevenlabs.io/v1/text-to-speech/EXAVITQu4vr4xnSDxMaL" \
  -H "Content-Type: application/json" -d '{"text":"Yes, I can."}' \
  -w "\nHTTP:%{http_code}\n"
# → HTTP 401 {"detail":{"status":"needs_authorization","message":"Neither authorization header nor xi-api-key received..."}}

A 401 (not 404) proves the path/method/body are correct. With a valid key the same request returns 200 and a valid MP3:

curl -sS -X POST "https://api.elevenlabs.io/v1/text-to-speech/EXAVITQu4vr4xnSDxMaL?output_format=mp3_44100_128" \
  -H "xi-api-key: $REAL_KEY" -H "Content-Type: application/json" \
  -d '{"text":"Yes, I can.","model_id":"eleven_multilingual_v2"}' -o out.mp3 -w "%{http_code}"
# → 200, out.mp3 = "Audio file with ID3 ... MPEG ADTS layer III, 128 kbps, 44.1 kHz"

The API key used here has the text_to_speech permission. So the connector's 404 is not the key and not a malformed request on the user's side — it is the connector building the wrong URL.

Likely root cause

The voice_id path parameter is not being interpolated into the request URL. A request to /v1/text-to-speech/ (no id) or a literal /v1/text-to-speech/{voice_id} would yield exactly this generic 404 from ElevenLabs' router.

Secondary (not the blocker)

The TTS tool schemas omit text from advertised properties/required (also model_id, voice_settings, language_code, etc.). In practice text is still forwarded when supplied, so this is a schema-completeness nit, not the cause of the 404.

Environment

• Claude Code CLI, model claude-opus-4-8 (1M context)
• macOS (Darwin)
• MCP server: hosted elevenlabs connector