MCP yol haritası agent kimliği, HTTP transport birleştirmesi ve kademeli tool keşfini hedefliyor

Protokol için beş parçalı bir plan

Model Context Protocol'ün çekirdek bakımcıları, önümüzdeki aylarda ve bir sonraki sürümde AI-agent bağlantı spesifikasyonunun yönünü belirleyen güncellenmiş bir yol haritası yayımladı. Hacker News'in ana sayfasında öne çıkan MCP blogundaki yazıya göre belge, Core Maintainers tarafından daha geniş topluluk ve çalışma gruplarıyla birlikte hazırlanmış. Önceden gelecekteki iş olarak işaretlenmiş ve kendi başına önceliklere dönüşmüş olan bazı alanlar — sunucu tarafından başlatılan event'ler, sonuç türü iyileştirmeleri ve agent kimliği — dahil beş öncelik alanına ayrılıyor.

Agentic mesajlaşma temel yapıları

İlk alan, modern agent iş yüklerinin artık klasik istek-yanıt desenine uymadığı gözleminden yola çıkıyor: döngüler daha uzun sürüyor, sunucular akış halinde sonuçlar gönderiyor ve bazen çalışan bir işin yarı yoldan yönlendirilmesi gerekiyor. MCP'ye halihazırda Tasks, abonelik ve dinleme semantiği ile ilerleme bildirimleri eklendi; yol haritasının açıklanan hedefi, bu temel yapıların yalnızca var olmasını değil, iyi bir şekilde birlikte çalışmasını sağlamak. Somut işler arasında, istemcilerin artık sonuçlar için polling yapması gerekmemesi için sunucu tarafından başlatılan event'ler (webhook ve kanallar), Agents, Transports ve Triggers & Events çalışma gruplarını kapsayan bir uyumluluk incelemesi ve Tasks uzantısını (SEP-2663) spesifikasyonun kendisine dahil edilecek kadar olgunlaştırmak yer alıyor.

Transport'ların HTTP üzerinde birleştirilmesi

2026-07-28 spesifikasyon sürümüyle birlikte uzak bir MCP sunucusu artık sıradan bir HTTP iş yükü haline geldi; bakımcılar bunun, barındırmayı olağan API altyapısında basitleştirdiğini ve pratikte iyi ölçeklendiğini söylüyor. Yol haritası şimdi bu modeli ek dağıtım modlarına genişletmeyi öneriyor; bunlara, tek bir transport'ın hem istemci hem sunucu geliştirmeyi basitleştirmesi için stdio üzerinden Streamable HTTP konuşan yerel sunucular da dahil.

Sadece insanlar için değil, agent'lar için de kimlik

MCP'nin mevcut yetkilendirme modeli, bir kişinin tarayıcıda erişimi onayladığını varsayıyor. Çağıran taraf, bir bulut iş yükü olarak kendi kimliğiyle çalışan, hazırda olmayan bir kullanıcı adına hareket eden ya da dar yetkileri alt-agent'lara devreden bir agent olduğunda bu model çöküyor. Bakımcılar, sunucuların bu tür agent kimliklerini tanımanın ve onlara güvenmenin standartlaştırılmış bir yoluna sahip olmasını istiyor; bu, statik API anahtarları ve uzun ömürlü token'lar değil, mevcut standartlar üzerine inşa edilecek. Planlanan işler arasında Demonstrating Proof of Possession (DPoP)'yı tamamlamak ve benimsenmesini sağlamak, Workload Identity Federation üzerinden agent kimliği ve yetki devri için bir yol tanımlamak, Enterprise-Managed Authorization'ın arkasındaki ID-JAG grant'i ve standart token exchange yer alıyor. Ekip ayrıca, temel standartların agent kimliğinin gerektirdiklerini destekleyecek şekilde evrilmesi için IETF OAuth ve WIMSE çalışma gruplarıyla birlikte çalışmaya devam etmeyi amaçlıyor.

Daha temiz tool sonuçları ve kademeli keşif

Tool calling, geliştiricilerin MCP'de ilk dokunduğu kısım ve bakımcılar, şu ana kadar protokole iyi hizmet ettiğini, ana eksikliğin ise sonuç işleme olduğunu değerlendiriyor. Bir tools/call yanıtı şu anda aynı çıktıyı birden fazla biçimde taşıyabiliyor ve bir sunucu geliştiricisi, belirli bir istemcinin bu çıktıyı modele hangi biçimde sunacağını bilmenin bir yoluna sahip değil; yol haritası tek bir net sözleşmede karar kılmayı hedefliyor. İkinci sorun ölçek: yüz tool sunan bir sunucuya bağlanmak, kullanıcının ilk isteğinden önce modelin tüm bu yüzeyin bedelini ödemesi anlamına geliyor ve liste büyüdükçe tool seçimi genellikle kötüleşiyor. Yeni bir kademeli keşif çabası, sunucunun kompakt bir başlangıç yüzeyi sunmasını ve etkileşim daraldıkça kataloğunun daha fazlasını açmasını sağlayacak.

SDK geliştirici deneyimi

SDK'lar geliştiricilerin MCP'yi fiilen deneyimlediği yol olduğundan bakımcılar, ergonomilerine, spesifikasyonla uyumlarına ve desteklenen her platform ve dildeki dokümantasyona yatırım yapıyor. Bunun şimdi daha fazla önem taşıdığını savunuyorlar; çünkü birçok geliştirici, MCP istemcileri ve sunucuları oluştururken kütüphaneleri bir agent'a göstererek ilerliyor ve iyi tasarlanmış API'ler ile güvenilir dokümantasyon, ortaya çıkan kodun az sürtünmeyle çalışıp çalışmayığını büyük ölçüde etkiliyor.

SEP yazarları için bunun anlamı

Beş öncelik alanına giren Specification Enhancement Proposal'lar hızlandırılmış incelemeden geçiyor ve kabul edilme şansı en yüksek olanlar onlar. Alanların dışındaki öneriler tamamen reddedilmiyor, ancak bakımcıların inceleme zamanı sınırlı ve önce bu alanlara gidiyor. Yazı, katkıda bulunanları ilgili öncelik alanını belirlemeye, fikirlerini o alandaki çalışma grubuyla paylaşmaya ve sorumlu Core Maintainers ile Discord üzerinden iletişime geçmeye teşvik ediyor. Diğer yollar arasında bir çalışma ya da ilgi grubuna katılmak, SEP'lere yorum yapmak, resmi bir öneriden önce SEP-2133 kapsamında deneysel bir uzantı başlatmak ya da doğrudan spesifikasyona, SDK'lara ve araçlara katkıda bulunmak yer alıyor.

Neden önemli

MCP istemcisi ya da sunucusu geliştiren herkes için bu yol haritası, gelecek değişikliklerin önceden haberi: yeni event odaklı temel yapılar, tek bir HTTP tabanlı transport, makine çağıranlar için düzgün bir kimlik hikayesi ve değişen tool-sonucu ile keşif davranışı. Agent kimliği hattı MCP'nin kendisinin ötesinde dikkat çekici; çünkü protokolün evrimini IETF OAuth ve WIMSE standartlaştırmasına bağlıyor ve burada alınan kararlar daha geniş web altyapısına dalga etkisi yaratabilir. Kademeli keşif çalışması, bir sunucunun sunduğu her tool ile büyüyen pratik bir maliyeti ele alıyor ve açık önceliklendirme kuralı, öneri yazarlarına inceleme dikkatının nereye harcanıp nereye harcanmayacağını tam olarak söylüyor.