Reconsider PR #850: Wrong Fix for a Potentially Invalid Use Case

[jayaraman-venkatesan]

References: PR #850, Issue #260

Rationale 1: charset=utf-8 is non-conformant

RFC 8259 §8.1 and IANA do not recognize charset as a valid parameter for application/json.

This might result in status 415 with strict servers.
csharp-sdk issue

Rationale 2: Non-ASCII tool names are spec-violating

The MCP spec and accepted SEP-986 both restrict tool names to [a-zA-Z0-9_\-.]. Non-ASCII characters like 天気予報 are outside this set (SHOULD, not MUST — but still discouraged).

Proposed Actions

1. Revert Content-Type header change
2. Add tool name validation at registration

Happy to submit a PR if maintainers agree.

@Kehrlann

[Kehrlann]

Hey @jayaraman-venkatesan - thanks for the report!

Rationale 1: I do understand that charset is not recognized, but it is encountered in the wild, and some servers do respect it.

Rationale 2: yes, you are correct, tool names should be spec compliant. In fact, they are validated since #764 . But the content-type is also important for the "content" of the tool, including tool description or call arguments (see this test bit)

If the server is too strict, you can work around it at the client transport level but overriding the value, e.g.:

HttpClientStreamableHttpTransport.builder("...")
	.httpRequestCustomizer((builder, method, endpoint, body, context) -> {
		var built = builder.build();
		var contentType = built.headers().firstValue("Content-Type").orElse("");
		if (contentType.equalsIgnoreCase("application/json; charset=utf-8")){
			builder.setHeader("Content-Type", "application/json");
		}
	})

Unless there is very strong demand for this, we will not be addressing this issue.