Currently, when using StdioClientTransport with stderr set to "pipe", the stderr stream is not available until after start() is called. This means that any error output from the child process during startup is lost if the caller wants to capture it.

Motivation and Context

The current implementation has a race condition:

1. User creates StdioClientTransport with stderr: "pipe"
2. User wants to attach stderr listeners
3. But stderr is only available after start() is called
4. By the time start() is called and stderr becomes available, early error output may have already been lost

This forces users to implement workarounds like:

let stderrOutput = '';
const transport = new StdioClientTransport({...});
const connectionPromise = client.connect(transport);
transport?.stderr?.on('data', (chunk) => {
  stderrOutput += chunk.toString();
});
await connectionPromise;

How Has This Been Tested?

The changes maintain backward compatibility while fixing the race condition. No existing behavior is changed - we just make the stderr stream available earlier.

Breaking Changes

No, purely additive

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context