MCP, protokoldeki Logging, Roots, Sampling ve HTTP+SSE özelliklerini kullanımdan kaldırdı; yerine OpenTelemetry geçiyor

Dört protokol özelliği artık bir süre sayacıyla yaşıyor

dev.to'daki MCP gözlemlenebilirliği yazısına göre, Model Context Protocol'ün 2026-07-28 revizyonu tek bir sürümde dört protokol düzeyindeki özelliği kullanımdan kaldırdı: Logging, Roots, Sampling ve eski HTTP+SSE transport'u. Bunlar, MCP'nin resmi özellik yaşam döngüsü politikası altında çıkarılan ilk kullanımdan kaldırmalar oldu ve her biri en az on iki aylık bir destek penceresi taşıyor. Sunucuları protokol üzerinden log bildirimleri gönderen ekipler için pratik son tarihi kabaca 2027 ortasına taşıyor.

Logging, en acil operasyonel sonuçları olan kullanımdan kaldırma. Sunucular kendi log formatlarını icat edip bunları hat üzerinden göndermekte özgürdü ve sonuç, sunucular ile backend'ler arasında asla düzgün şekilde toplanamıyordu. Dikkat çekici olan, spesifikasyonun yerine koyduğu şeyin yeni bir MCP logging özelliği olmaması — OpenTelemetry olması.

Protokol logging'inin yerine ne geçiyor

İki parça bir araya geliyor. Birincisi, revizyon sabit ve öneksiz anahtarlarla — traceparent, tracestate ve baggage — W3C Trace Context yayılımını belgeliyor; bunlar isteğin params._meta bölümünde taşınıyor. _meta transport'tan bağımsız olarak her istekle birlikte hareket ettiği için bağlam, header'ları yeniden yazan gateway'lerde ve hatta hiç header'ı olmayan stdio'da bile hayatta kalıyor. İstemci tarafındaki span, transport ne olursa olsun sunucu tarafındaki span'ın ebeveyni haline geliyor ve daha önce bölünen izleri onaran da tam olarak bu.

İkincisi, OpenTelemetry'nin GenAI semantik konvansiyonlarına özel bir MCP bölümü eklendi; bu bölüm, Nisan 2024'te kurulan bir özel ilgi grubu tarafından semantic-conventions-genai deposunda bakımını yapılıyor. Öneri, genel RPC konvansiyonları yerine MCP konvansiyonlarının tercih edilmesi; çünkü MCP span'ları araç kimliğini, protokol sürümünü ve RPC span'larının temsil edemediği, akış halindeki bir çağrı içindeki mesaj alışverişlerini kaydedebiliyor.

İzler neden MCP sınırında kopuyor

dev.to yazısı tanıdık bir başarısızlık modunu anlatıyor: agent çerçevesi LLM çağrısı için bir span, araç kullanımı için bir alt span üretiyor, sonra istek MCP sunucusuna giriyor ve ebeveynsiz, taze bir iz başlıyor. Tek bir mantıksal işlem, ID ile ilişkilendirilemeyen iki iz olarak sonuçlanıyor ve bir agent'ın neden kırk saniye durakladığını çözmek, iki sistemdeki zaman damgalarını elle eşleştirmek anlamına geliyor.

Kök neden yapısal. HTTP üzerinden JSON-RPC, iz header'ları için bariz bir yere sahip değil ve transport'un header'ları her zaman sizin kontrolünüzde değil. Yeni spesifikasyonun durumsuz (stateless) yönü bunu kolaylaştırmadı, zorlaştırdı: Mcp-Session-Id olmadan ekipler, birçoğunun sessizce yaslandığı tek korelasyon anahtarını kaybetti. Artık her istek tek başına yol alıyor; protokol sürümünü, istemci kimliğini ve yeteneklerini _meta içinde taşıyor — iz bağlamının da tam olarak yaşadığı yer orası.

Göç edilmesi gereken kavramsal sözlük

Konvansiyonlar iki taraf için tek bir span adı formatı tanımlıyor: {mcp.method.name} {target}; böylece bir araç çağrısı genel bir POST /mcp yerine tools/call get_invoice olarak görünüyor. İstemci span'ının türü CLIENT, sunucu span'ının türü SERVER ve panolar, istek gövdelerini ayrıştırmadan araca göre gruplayabiliyor.

Zorunlu öznitelik mcp.method.name. Koşullu öznitelikler arasında rpc.request.id, mcp.resource.uri, error.type ve rpc.response.status_code var. Önerilenler arasında gen_ai.operation.name (araç çağrıları için execute_tool olarak ayarlanır), mcp.protocol.version, mcp.session.id ve network.transport yer alıyor. İki öznitelik — gen_ai.tool.call.arguments ve gen_ai.tool.call.result — opsiyonel, çünkü araç yükleri rutin olarak müşteri kayıtları, token'lar ve iç tanımlayıcılar içeriyor; tavsiye, bunları staging ortamında etkinleştirmek, üretimde agresif örneklemek ve dışa aktarmadan önce temizlemek.

Dört metrik seti tamamlıyor: istemci ve sunucu işlem süresi, ayrıca istemci ve sunucu oturum süresi. İstemci/sunucu ayrımı bilinçli, çünkü aradaki fark transport, gateway ve kuyruk maliyetini ölçüyor ve açıklanamayan zamanın çoğu zaman tam da oraya gidiyor. Yazı ayrıca iki spesifikasyon revizyonunu desteklediğinizde mcp.protocol.version özniteliğini en faydalı olan olarak öne çıkarıyor, çünkü hangi istemcilerin hâlâ eski yolda kaldığını gösteriyor.

Pratik göç notları

Yazının son tarih hakkındaki okuması şu: paniğe kapılıp her şeyi baştan yazmayın, ama kullanımdan kaldırılan özelliklerin üzerine yeni bir şey inşa etmeyin. Ayrıca karışıklık bekleyin — semantik konvansiyonlar henüz stabil değil, bu yüzden instrumentation sürümlerinizi sabitleyin ve öznitelik adı değişikliklerine hazırlıklı olun. 2026-07-28 sürümünün geri kalanı da aynı durumsuz yöne itiyor; Mcp-Method ve Mcp-Name ile header tabanlı yönlendirme ve ttlMs ile cacheScope taşıyan önbelleklenebilir liste sonuçları dahil — bunların hepsi, tek uzun bir oturum yerine çok sayıda kısa ömürlü istek arasında görünürlük varsayıyor.

Neden önemli

Bu kullanımdan kaldırma, gözlemlenebilirliği hoş bir ekstra olmaktan çıkarıp üretimde MCP sunucusu çalıştıran herkes için planlanmış bir göç maddesi haline getiriyor. Bunu atlayan ekipler 2027 ortası civarı bir son tarihle karşı karşıya kalıyor ve bu arada kopuk izler arasında elle araştırılan agent arızaları yaşıyor — en pahalı tür dahil: bir modelin, kimsenin işaret etmediği kötü bir araç sonucuna dayanarak kendinden emin ama yanlış bir yanıt döndürmesi. Bunu düzeltmek için gereken parçalar artık mevcut ve satıcıdan bağımsız; geriye kalan tek iş, sayaç bitmeden onları benimsemek.