Stateless server transport shouldn't require TEXT_EVENT_STREAM

[quaff]

Motivation and Context

It's a trivial improvement.

How Has This Been Tested?

Tested with curl.

Breaking Changes

No

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

[quaff]

@chemicL Could you review this? I confirm the failed test is not introduced by this PR since I can't reproduce it locally.

[chemicL]

@chemicL Could you review this? I confirm the failed test is not introduced by this PR since I can't reproduce it locally.

Hey, as I understand the spec, this is violating it:

The client MUST include an Accept header, listing both application/json and text/event-stream as supported content types.

I do understand why you'd want to take away this strictness, but it's against another assumption behind the spec, which is that servers can be simple but clients have to support all kinds of servers, therefore this step is validating that a client is a proper one and if the server decides to return a stream it will be able to.

[quaff]

Thanks for your explanation.