🐛 Bug-fix PR

📌 Summary

The previous gateway validation logic incorrectly handled StreamableHTTP transport detection, causing valid MCP StreamableHTTP gateways to be incorrectly rejected.

🔁 Reproduction Steps

1. Start any MCP server exposing POST /mcp StreamableHTTP endpoint (e.g., fastmcp example).
2. Add the server in the gateway.
3. Registration fails for all streamablehttp server as validation logic fails.

🐞 Root Cause

The previous implementation incorrectly validated StreamableHTTP by:

• Expecting a GET request instead of POST.
• Expecting an mcp-session-id header, which is NOT required per MCP spec.
• Enforcing Content-Type: application/json only, even though StreamableHTTP may emit text/event-stream when streaming.
• Not sending a ping method, meaning valid servers responded with errors.
• Using the same code path as SSE for content-type testing.

As a result, most valid StreamableHTTP servers appeared “invalid”.

💡 Fix Description

Correct validation flow that:

• Performs a JSON-RPC ping for StreamableHTTP
• Validates response content-type (application/json or text/event-stream)
• Eliminates incorrect assumptions about mcp-session-id headers
• Ensures HTTP redirects, auth failures, and protocol mismatches are handled consistently
• Uses a single request client and unified cleanup logic

🧪 Verification

📐 MCP Compliance (if relevant)

• Matches current MCP spec
• No breaking change to MCP clients

✅ Checklist

• Code formatted (make black isort pre-commit)
• No secrets/credentials committed