/sse tuzağı: bozuk görünen ama bozuk olmayan 387 sunucu

MCP, HTTP'yi iki farklı şekilde konuşur ve bunlar birbirinin yerine geçmez. Streamable HTTP, JSON-RPC'yi doğrudan tek bir uca gönderir. Daha eski HTTP+SSE taşıması ise bambaşka çalışır: önce bir akış açarsınız, sunucu size nereye göndereceğinizi söyler.

Yanlış gittiğinde neye benziyor

Bir HTTP+SSE ucuna initialize isteği gönderirseniz hata almazsınız. Şunu alırsınız:

HTTP 200
content-type: text/event-stream

event: endpoint
data: https://example.com/my-mcp/api/process

İki yüz OK. Hata kodu yok, şikâyet yok. Yalnızca kibar bir not: "asıl uç şurada." Bunu beklemeyen bir istemci ise bunu boş yanıt olarak okur.

Tuzak tam burada. Başarı dönen bir hatayı fark etmek, 500 dönen bir hatayı fark etmekten çok daha zordur.

Biz de bu tuzağa düştük

Okuyamadığımız sunucuları "unknown" diye sınıflandırıyoruz. Bu kovanın neden bu kadar büyük olduğuna baktığımızda, 387 sunucunun yanlış şekilde istek gönderdiğimiz HTTP+SSE uçları olduğu ortaya çıktı. URL'i /sse ile biten sunucuların %84'ü unknown işaretliydi — katalog genelinde bu oran %10. Sekiz katı bir oran tesadüf değil, parmak izidir.

O sunucular baştan beri sağlamdı. Yanlış protokolü konuşan bizdik.

Nasıl kaçınılır

• Gövdesi boş ya da ayrıştırılamayan bir 200 yanıtını ölü sunucu değil, taşıma uyuşmazlığı olarak değerlendirin.
• Yanıtın içerik türü text/event-stream ise ve ilk olayın adı endpoint ise, onu takip edin ve isteği oraya gönderin.
• Yalnızca URL'e güvenmeyin. /sse ile biten bir yol ipucudur, garanti değil — üstelik pek çok HTTP+SSE ucu /sse ile hiç bitmiyor.

Sunucu yayınlıyorsanız en ucuz çözüm, registry kaydınızda hangi taşımayı konuştuğunuzu yazmaktır. İstemcilerin çoğu size inanır.