Add Accept header validation

[keisku]

Motivation and Context

The MCP 2025-06-18 specification requires clients to include specific Accept headers when communicating with servers via Streamable HTTP transport:

• POST requests MUST include both application/json and text/event-stream
• GET requests MUST include text/event-stream

This change brings the SDK into compliance with the specification by:

1. Server-side: Validating incoming Accept headers and returning 406 Not Acceptable when requirements aren't met
2. Client-side: Automatically including the required Accept header on all HTTP requests

How Has This Been Tested?

• Added new unit tests.
• Ran this command to simulate the communication between MCP client and server.

bundle exec ruby -I lib -e '
require "mcp"
require "rack"

# Create server transport
transport = MCP::Server::Transports::StreamableHTTPTransport.new(MCP::Server.new(name: "test", version: "1.0"))

# Test 1: POST without Accept header should return 406
env = Rack::MockRequest.env_for("/mcp", method: "POST", input: "{}", "CONTENT_TYPE" => "application/json")
request = Rack::Request.new(env)
status, headers, body = transport.handle_request(request)
puts "Test 1 - POST without Accept header: #{status == 406 ? "PASS" : "FAIL"} (status: #{status})"

# Test 2: POST with only application/json should return 406
env = Rack::MockRequest.env_for("/mcp", method: "POST", input: "{}", "CONTENT_TYPE" => "application/json", "HTTP_ACCEPT" => "application/json")
request = Rack::Request.new(env)
status, headers, body = transport.handle_request(request)
puts "Test 2 - POST with only application/json: #{status == 406 ? "PASS" : "FAIL"} (status: #{status})"

# Test 3: POST with both required types should succeed (not 406)
env = Rack::MockRequest.env_for("/mcp", method: "POST", input: "{\"jsonrpc\":\"2.0\",\"method\":\"initialize\",\"id\":1}", "CONTENT_TYPE" => "application/json", "HTTP_ACCEPT" => "application/json, text/event-stream")
request = Rack::Request.new(env)
status, headers, body = transport.handle_request(request)
puts "Test 3 - POST with both required types: #{status != 406 ? "PASS" : "FAIL"} (status: #{status})"

# Test 4: GET without Accept header should return 406
env = Rack::MockRequest.env_for("/mcp", method: "GET")
request = Rack::Request.new(env)
status, headers, body = transport.handle_request(request)
puts "Test 4 - GET without Accept header: #{status == 406 ? "PASS" : "FAIL"} (status: #{status})"

# Test 5: Verify client includes Accept header constant
puts "Test 5 - Client Accept header constant: #{MCP::Client::HTTP::ACCEPT_HEADER == "application/json, text/event-stream" ? "PASS" : "FAIL"}"

puts "\nAll Accept header validation tests completed!"
'

Test 1 - POST without Accept header: PASS (status: 406)
Test 2 - POST with only application/json: PASS (status: 406)
Test 3 - POST with both required types: PASS (status: 200)
Test 4 - GET without Accept header: PASS (status: 406)
Test 5 - Client Accept header constant: PASS

All Accept header validation tests completed!

Breaking Changes

Yes.

Servers will now reject requests without proper Accept headers with HTTP 406. Clients that don't send the required Accept header will receive an error response. However, compliant MCP clients should already be sending this header per the specification.

This change aligns with https://github.com/modelcontextprotocol/typescript-sdk/pull/266/changes#diff-fa2d8ab461bf11229eaa80d28cfa765b7244ab37a737a0b67f26aae8102175eeR121-R123.

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

[keisku]

@atesgoral Thank you! I addressed it.

[koic]

I've left a few minor comments, but overall this looks ready to move forward. Can you address them and squash the commits into one?