## Description

When LiteLLM proxy serves an MCP `tools/call` request, the resulting `standard_logging_object` includes the call **request** (tool name, arguments) but **not** the upstream MCP server's **response/result**. There is no `response`, `result`, or `content` field on the record.

As a result, downstream loggers (Langfuse, Datadog, custom callbacks, the UI Logs tab) cannot observe what an MCP tool actually returned. Standard LLM completion logs do include the response, so this is an MCP-specific gap.

## Repro

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

- `set_verbose: true` - `--detailed_debug` CLI flag - `store_prompts_in_spend_logs: true`

Steps:

1. Configure any HTTP MCP server (`auth_type: none` works; pass the upstream bearer token via `x-mcp-{alias}-authorization: Bearer <token>` if needed). 2. POST `/mcp/` with a JSON-RPC `tools/call` invocation. 3. The MCP server returns a successful result (verified out-of-band via direct curl to the upstream URL — `isError: false`, real `content` and `structuredContent` payloads). 4. Inspect the resulting `standard_logging_object` (from verbose logs / a registered `CustomLogger` / Langfuse).

## Observed

…