Add allowClientError to Scenario interface for expected client failures

[mikekistler]

Motivation and Context

Prior to this change, client conformance tests could fail in expected error cases because the client exited with a non-zero exit code. This behavior should be allowed and considered as passing for expected error tests.

How Has This Been Tested?

Ran the tests locally.

Breaking Changes

No previously passing test should fail as a result of this change.

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

[pkg-pr-new]

Open in StackBlitz

npx https://pkg.pr.new/modelcontextprotocol/conformance/@modelcontextprotocol/conformance@123

commit: f27cd37

[pcarleton]

Love it, thank you! one minor nit.

for a follow-up: I'm thinking clientOutput should actually be a mandatory argument to printing the results. so we don't have to do that existence check. If we don't have an exitCode we should likely consider it a failure, but happy to tackle that separately

[maciej-kisiel]

Hi! I'm working on implementing client conformance tests for Go and just wanted to let you know that likely due to this change the auth/resource-mismatch scenario passes for an incomplete client that doesn't even implement this scenario and returns non-zero exit code right away. I don't have any good proposal how to improve that (maybe it should be asserted that some communication actually happens?), it's more of an FYI.