Client compatibility
MCP Streamable HTTP, SSE and OAuth: what your client actually needs
Separate transport from authentication, avoid misleading compatibility claims, and diagnose a hosted MCP connection before changing infrastructure.
Ask two separate compatibility questions
“Supports MCP” is not enough information to connect a client to a hosted server. Ask which transport and protocol revision the client can use, then ask which authentication flow it expects. Transport describes how protocol messages travel. Authentication establishes who is calling and which authority the request carries. A working connection needs agreement on both. A server that accepts a manually supplied API key may work in one client and fail in another client that only offers OAuth-based connection setup. Changing the URL repeatedly will not repair that mismatch.
Streamable HTTP does not always mean an event stream
In the 2025-11-25 MCP transport specification, Streamable HTTP uses an HTTP endpoint for client messages and allows JSON or server-sent-event responses in the relevant flows. That means a JSON response alone does not imply the transport is invalid. Conversely, a product advertising Streamable HTTP has not necessarily implemented long-lived streams, resumability or server-initiated requests. Determine which of those capabilities your workflow actually uses. A short request that returns one tool result has different operational requirements from a long-running workflow that sends progress messages.
Legacy SSE is a different connection path
The older HTTP+SSE transport and SSE responses within Streamable HTTP are not interchangeable labels. An older client may expect an SSE connection that announces where subsequent messages should be sent. Appending /sse to a modern server URL does not create that behavior. If compatibility with older clients matters, test an explicit adapter or server implementation with those clients, including reconnects and expired credentials. Do not infer support from a proxy configuration with buffering disabled. The application still has to implement the protocol behavior.
A bearer header does not prove OAuth support
Both a static API key and an OAuth access token can travel in an Authorization bearer header, but their lifecycle and security model differ. OAuth compatibility involves more than recognizing a token string: the resource must validate the intended issuer, audience, expiration and permissions, and participate in the required discovery and authorization flow. A platform’s own login screen is a separate concern. Signing into a hosting dashboard with OAuth does not automatically make every hosted MCP an OAuth-protected resource suitable for third-party client onboarding.
Diagnose the boundary that failed
Start by recording the exact endpoint, client version, authentication choice and response status without recording the credential. A 401 suggests examining credentials and authentication expectations; a 403 can point to policy or Origin restrictions; a 404 can indicate a wrong route; and a 405 can mean that the requested HTTP method is not implemented. These are diagnostic clues, not universal guarantees. Compare the request with the server’s documentation, then test initialization and tool discovery before running a business action. Keep request IDs so the client observation can be correlated with gateway and runtime evidence.
What MCP Ops supports today
MCP Ops currently exposes POST /mcp with JSON responses and consumer API-key authentication. It does not provide the legacy /sse endpoint, long-lived SSE streams or completed MCP OAuth authorization. The Connect page states these boundaries so teams can choose a compatible client instead of discovering the limitation during a customer demo. If an OAuth-only client is mandatory, treat that as a requirement to resolve before choosing this deployment path. For compatible bearer-key clients, use a dedicated key, test tools/list, then verify one low-risk tool call and its operational record.