Add ITestOutputHelper logging in scenario/conformance harness for better CI diagnostics

[jongalloway]

Why

We’re increasingly relying on stdio-level scenario + conformance tests to validate end-to-end MCP behavior. When these fail in CI, the most useful debugging info is often test-local context (server args, tool call payloads, raw tool output, parsed machine-readable JSON, etc.).

Today the tests mostly rely on assertions + some Console.WriteLine, but we’re not consistently using xUnit’s per-test output channel.

Context

• Scenario tests currently run fast (~20–25s locally for the whole scenario namespace) and provide high signal.
• We use Microsoft Testing Platform + xUnit v3 runner.
• MinVer 7.0.0 mentions “enable xunit output capture” in MinVer’s own repo, but it does not provide a consumer-facing feature for this repo. If we want better output in CI, we should implement it in our tests.

Proposal

Adopt ITestOutputHelper for scenario and conformance test infrastructure so diagnostics are attached to the failing test (and not interleaved globally).

Suggested approach

• Pass ITestOutputHelper into the harness classes used by:
  • scenario tests (e.g., the stdio client/server wrapper)
  • conformance tests (where we start the server process)
• Log only high-value events:
  • server start command + working directory
  • tool name + args (redacted/sanitized)
  • raw machine-readable JSON payload returned (when machineReadable: true, and preferably only on failure)
  • process exit codes + stderr/stdout snippets (redacted)
• Keep output minimal by default:
  • either write logs only when assertions fail, or
  • write a small header always and detailed logs only on failure.

Acceptance criteria

• Add at least one representative test which uses ITestOutputHelper and demonstrates that:
  • output is visible in CI logs when the test fails
  • output is tied to the failing test (not lost/interleaved)
  • no secrets are printed (reuse existing redaction helpers / patterns)
• Update the scenario/conformance harness to accept an optional output sink.
• Keep runtime impact negligible.

Notes

If we find that the runner/CI isn’t showing ITestOutputHelper output the way we want, document the required dotnet test/runner configuration (Microsoft Testing Platform + xUnit v3) in doc/testing.md and/or the workflow.