### Check for existing issues

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

### What happened?

When LiteLLM Proxy is used as an MCP StreamableHTTP gateway in front of another StreamableHTTP MCP server, tool calls with a large UTF-8 string argument fail only when routed through LiteLLM.

Expected: - LiteLLM should forward the full request body to the downstream MCP server. - The tool call should succeed, just like the same request does when sent directly to the downstream StreamableHTTP MCP server.

Actual: - LiteLLM returns HTTP 500 with: `{"error":"MCP request failed","details":"'utf-8' codec can't decode byte 0xd1 in position 4095: unexpected end of data"}`

Why I think this is in LiteLLM and not the downstream server: - The same downstream StreamableHTTP MCP server succeeds when called directly with the same large UTF-8 payload. - The failure appears only when the same request goes through LiteLLM's StreamableHTTP MCP path. - The error position (`4095`) matches LiteLLM's `_MCP_ROUTING_PEEK_MAX_BYTES = 4096` in `litellm/proxy/_experimental/mcp_server/server.py`. - The relevant code path seems to be `_read_request_body_for_routing()` …