The remote MCP client config matrix nobody documents (and the three ways type fails silently)

The author maintains a remote MCP server that uses a static Authorization: Bearer header for authentication. They discovered that different clients have their own way of handling the JSON Transport configuration. The author tested the same endpoint with seven clients and found that the same HTTP transport has four different names. The interesting part is not that the names differ, but that a wrong name fails in three completely different ways.

1. The first way is the endpoint being inaccessible due to transport issues like wrong path, type, proxy, or a client-side bridge eating the request. The client response is not a 200.

2. The second way is when the client treats the request as stdio and omits the type. This can cause clients to either not launch anything or report a spawn failure. The config might look correct, but the error message will point at a nonexistent process. The URL is never dialed.

3. The third way is the most problematic. The client negotiates SSE instead of streamable HTTP, and if the server doesn't support SSE, it will answer 405 or the client will fall back until something half-works. This results in a 401 response on the first call.

The author advises testing the calling path and ensuring that the transport field is validated against a closed set by the client.