### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

When a `/v1/responses` request is handled by the MCP gateway (a hosted MCP tool with `server_url: litellm_proxy/...`), the id LiteLLM returns to the client is base64-encoded twice. On the next turn LiteLLM only decodes one layer, so it forwards a still-encoded `previous_response_id` to the upstream provider. OpenAI rejects it:

``` litellm.BadRequestError: OpenAIException - { "error": { "message": "Invalid 'previous_response_id': string too long. Expected a string with maximum length 64, but got a string with length 205 instead.", "type": "invalid_request_error", "param": "previous_response_id", "code": "string_above_max_length" } } ```

On the non-streaming path this surfaces as a 400. On the streaming path the same error is swallowed inside the MCP streaming iterator, so the client gets HTTP 200, sees `response.mcp_list_tools.completed`, and then `[DONE]` with no model output at all (a silent empty completion). Multi-turn conversations that rely on `previous_response_id` together with a hosted MCP tool are therefore comple…