## Description

When LiteLLM proxy serves an MCP `tools/call` and the upstream MCP server returns a successful HTTP/JSON-RPC envelope but with `result.isError: true` (an upstream "soft" failure — e.g. validation error from the tool, business-logic error, refusal), the `standard_logging_object` records:

- `status: "success"` - `error_information: null`

i.e. the call is logged as a successful tool invocation, indistinguishable from a real success. Combined with the fact that the upstream response body isn't captured at all (see #28900), the upstream's error message is **invisible** to any callback-based observability — there is nowhere it could be read from in the `standard_logging_object`.

Any dashboard, alert, or SLO that reads MCP error rates from spend logs / standard logging callbacks will severely underreport real failures.

## Repro

Tested on `ghcr.io/berriai/litellm:main-v1.81.14-stable`.

1. Configure any HTTP MCP server (auth_type `none` with header-forwarded token works fine). 2. Call a real tool that exists, with deliberately invalid arguments: ```json {"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"<alias>-<real_tool>","arguments":{"NOT_a_r…