VirtualMCPServer: Add tool execution trace output for composite tools

Description

When using VirtualMCPServer with composite tools that execute multiple backend tool calls in sequence, developers currently have limited visibility into which specific tools were invoked during execution. This makes debugging and auditing composite tool workflows challenging.

Current Behavior

When a composite tool executes:

• Multiple backend MCP tools are called sequentially based on the workflow steps
• Step outputs are used internally for template variable expansion (e.g., {{.steps.step_id.output}})
• The final response is returned to the client
• No information about the internal tool execution flow is exposed to the caller

Desired Behavior

VirtualMCPServer should provide an optional output that includes execution trace information showing:

• Which backend tools were called during the composite tool execution
• The order of execution
• Step IDs and their corresponding tool invocations
• Any relevant execution metadata (timing, status, etc.)

This trace information would be invaluable for:

• Debugging: Understanding why a composite tool produced unexpected results
• Development: Validating that workflow steps execute as intended
• Auditing: Tracking which backend services were accessed during a request

Suggested Implementation

Add a debug flag or configuration option (e.g., include_execution_trace: true) that when enabled, includes execution trace metadata in the tool response. This could be:

• An additional field in the response payload
• Part of the tool metadata
• Configurable at the VirtualMCPServer CRD level or per-request

Example response structure:

{
  "result": "...",
  "execution_trace": [
    {"step_id": "fetch_data", "tool": "backend1.fetch_api", "status": "success", "parameters": {...}},
    {"step_id": "process", "tool": "backend2.transform", "status": "success", "parameters": {...}}
  ]
}

Related Issues

This issue complements but differs from existing observability work:

• #2849 (OpenTelemetry metrics): Focuses on infrastructure-level monitoring and metrics collection for operational observability
• #2850 (Audit logging): Focuses on compliance and security audit trails stored server-side

This proposal differs by providing client-visible execution traces specifically for development and debugging purposes. While #2849 and #2850 focus on backend observability and compliance, this feature would give developers immediate feedback about composite tool execution in the tool response itself.

References

• THV-2106 Virtual MCP Server Proposal

Read the THV-2106 Virtual MCP Server proposal first, then locate the VirtualMCPServer composite-tool execution and tool-response paths. Define how an optional client-visible trace should be configured and represented, including step order, tool invocations, status, and metadata; the work is done when the behavior and response contract are implemented and validated.