Streamable HTTP

Kısaca: Bir MCP istemcisi ile sunucusunun birbiriyle konuştuğu taşıma türlerinden biri (stdio ve daha eski SSE’nin yanında). Streamable HTTP ile iletişim, bir uç noktaya (tipik olarak /mcp) normal HTTP istekleriyle yürür.

Biraz daha ayrıntılı: stdio’dan farklı olarak (burada istemci sunucu sürecini kendisi başlatır, örn. node server.js), Streamable HTTP’de istemci zaten çalışan bir sunucuya bir URL aracılığıyla bağlanır – sunucu (buradaki Obsidian eklentisi gibi) zaten başka bir uygulamanın parçası olarak çalışıyorsa çok uygundur.

Bizim bağlamımız: Obsidian MCP sunucusu, claude mcp add --transport http ile bağladığımız bir Streamable HTTP uç noktası olarak http://127.0.0.1:27200/mcp altında çalışır.

Ayrıntılı

SSE’nin yerini almak

2025’te Streamable HTTP, ağ bağlantıları için önerilen MCP standardı olarak daha eski SSE taşımasının (server-sent events) yerini aldı. Temel fark: SSE iki ayrı bağlantıya ihtiyaç duyuyordu (istemciden sunucuya iletiler için normal POST üzerinden bir tane, sunucudan istemciye iletiler için ayrı, kalıcı açık bir bağlantı) — Streamable HTTP ikisini aynı /mcp uç noktası üzerinden birleştirir; gerekirse tek bir yanıt, tek bir tam yanıt yerine bir akış (art arda birkaç ileti) olarak teslim edilebilir. Bu sadeleştirme, sunucu tarafındaki altyapı karmaşıklığını da önemli ölçüde azaltır: aynı anda iki farklı bağlantı türünü yönetmek (bir bağlantı koptuğunda ikisini nasıl eşgüdümlü tutacağı sorusu dahil) yerine tek bir klasik HTTP uç noktası yeter.

stdio ve ağ taşımaları

stdio taşımasında (ağsız alternatif) istemci, sunucu sürecini alt süreç olarak kendisi başlatır ve standart girdi/çıktısı üzerinden iletişim kurar — bu yalnızca istemci ve sunucu aynı makinede çalışırsa işe yarar. Streamable HTTP, sunucu istemciden bağımsız çalıştığında (burada Obsidian’ın kendisi çalışır çalışmaz başlayan, o an etkin bir Claude oturumu olup olmadığından bağımsız Obsidian eklentisi gibi) veya istemci ile sunucu farklı makinelerde bulunacağında gerekli hale gelir. stdio’nun pratik bir avantajı: süreci istemci kendisi başlatıp durdurduğundan yaşam döngüsü yönetimiyle kimsenin ilgilenmesi gerekmez (sunucu yalnızca gerektiği sürece çalışır) — Streamable HTTP gibi ağ taşımalarında ise sunucu, o an bir istemcinin bağlı olup olmadığından bağımsız olarak kendi başına çalışmalı ve erişilebilir kalmalıdır.

Oturum yönetimi ve kimlik doğrulama

Streamable HTTP normal HTTP istekleri üzerinden çalıştığından standart web mekanizmaları doğrudan yeniden kullanılabilir: oturumlar bir oturum kimliğiyle (örn. başlık olarak) yönetilebilir ve kimlik doğrulama, Authorization başlığındaki bir bearer belirteci gibi yaygın HTTP kalıplarıyla yürür — tıpkı klasik bir REST API gibi. Bu, stdio’ya göre pratik bir avantajdır; stdio’da doğası gereği klasik anlamda “kimlik doğrulama” gerekmez (istemci sunucuyu kendisi başlattı ve aynı güvenlik bağlamında çalışır), ama bu gerekirse de yerleşik bir mekanizması yoktur.

Hangi taşıma ne zaman mantıklı

Pratik kural: istemci örneği başına yalnızca yerel olarak ve bir kez başlatılan sunucular için stdio (örn. bir dosya sistemi erişim aracı), bağımsız, kalıcı çalışan bir hizmet olarak var olan ve potansiyel olarak aynı anda veya zaman içinde birkaç istemci tarafından kullanılan sunucular için Streamable HTTP — burada tek tek hiçbir Claude Code oturumunun yaşam döngüsünden bağımsız çalışan bir Obsidian eklentisi gibi.

Ayrıca bak: MCP (Model Context Protocol), Bearer belirteci, HTTP