MCP Spesifikasyonu – 2025-06-18 Sürümündeki Değişiklikler

• MCP spesifikasyonunun yeni güncellemesi, yapılandırılmış meta veri ve bağlam yönetimi bölümlerine odaklanıyor. Amaç, genişletilebilirliği artırmak ve farklı sistemler arasında birlikte çalışabilirliği güçlendirmek
• Yeni veri alanları ekleniyor ve mevcut zorunlu alanlar daha ayrıntılı tanımlanıyor. Meta veri yapısının hiyerarşik hale gelmesi sayesinde sistem bazında ayrı genişletme yöntemleri desteklenebiliyor
• Bağlam izleme ve özellik güncellemeleri için açık kurallar sunuluyor; önceye kıyasla tutarlı durum bilgisi yönetimi özellikle vurgulanıyor
• Yetki yönetimi ve veri doğrulama süreçleri protokol spesifikasyonunda açıkça tanımlanıyor. Yeni eklenen bazı alanlar, gelecekteki protokol sürümleriyle uyumluluk gözetilerek tasarlandı
• Çapraz platform entegrasyonu desteği: birden fazla AI platformu ve bulut hizmeti ortamında da bağlam verilerinin tutarlı bir şekilde değiş tokuş edilmesi için temel sağlanıyor

---

• MCP(Model Context Protocol), makine öğrenimi modelleri veya büyük dil modelleri gibi çeşitli yapay zeka sistemleri arasında bağlam meta verisi alışverişi için kullanılan bir protokoldür

Major changes

1. JSON-RPC toplu işlem (batching) desteği kaldırıldı (PR #416)
2. Yapılandırılmış araç çıktısı (structured tool output) desteği eklendi (PR #371)
3. MCP sunucuları OAuth kaynak sunucusu olarak sınıflandırıldı; korumalı kaynak meta verileri eklenerek bağlı Authorization sunucusunun bulunması iyileştirildi (PR #338)
4. MCP istemcilerinin RFC 8707 Resource Indicator uygulaması zorunlu hale getirildi (kötü niyetli sunucuların erişim belirteci edinmesini önlemek amacıyla) (PR #734)
5. Authorization spesifikasyonundaki güvenlik değerlendirmeleri (security considerations) ve en iyi uygulamalar netleştirildi; ayrıca ayrı bir güvenlik kılavuzu sayfası eklendi
6. Elicitation (ek bilgi isteme) özelliği eklendi; böylece sunucular kullanıcıdan ek bilgi isteyebiliyor (PR #382)
7. Resource Links desteği eklendi; araç çağrısı sonuçlarına kaynak bağlantıları dahil edilebiliyor (PR #603)
8. Protokol sürümü uzlaşması sırasında HTTP'de MCP-Protocol-Version başlığı zorunlu hale getirildi (PR #548)
9. Lifecycle Operation içindeki SHOULD, MUST olarak değiştirildi (referans)

---

Other schema changes

1. _meta alanı daha fazla arayüz türüne eklendi (PR #710); doğru kullanım şekli de belirtildi
2. CompletionRequest içine context alanı eklendi; daha önce yorumlanan değişkenleri içerebiliyor (PR #598)
3. Programatik tanımlayıcıdan ayrı, kullanıcı dostu gösterim için title alanı eklendi (name kod tanımlayıcısı için, title ise gösterim için kullanılıyor) (PR #663)

[kernel00]

Hacker News yorumları biraz hayal kırıklığı yaratıyor. Sanırım sadece stdioya bakmışlar; şu anda remote MCP server'lar ya da onlara aracılık eden registry'ler ne kadar da mantar gibi çoğalıyor....

[GN⁺]

Hacker News görüşü

• MCP (Machine Context Protocol) patlamasından benim çıkardığım en büyük ders, backend yazılım geliştirmede aslında MCP kullanmaya gerek olmadığı oldu. Mimari olarak tam oturmayan tarafları var. Özellikle Elixir gibi ortamlarda bu daha da belirgin geliyor. Her API için ayrı bir sunucu koyarsan, 500 API için 500 mikroservis çalıştırman gerekir. Bunu ancak 20 farklı MCP sunucusunu bizzat kullandıktan sonra fark ettim; sonuçta MCP de function calling için bir kabuktan ibaretmiş. Her API’yi sunucu yerine ayrı bir modül olarak yapmak yeterli. Sürekli en yeni MCP spesini takip etmeye ya da spes değiştikçe yüzlerce mikroservisi güncellemeye gerek yok. Sonuç olarak bu sadece gereksiz karmaşıklık
  • İstemci gateway ya da BFF üzerinden geçmeden her mikroservise doğrudan bağlanmıyorsa, MCP’yi tüm servisin önüne koyup API, GraphQL, RPC gibi mevcut yöntemlerde olduğu gibi sadece işlevleri açığa çıkarmak yeterli. Pratikte LLM’e özel bir arayüz gibi duruyor. OpenAPI spesine dayalı tool call da gayet kullanılabilir. Her durumda tüm mikroservislerin birbiriyle sadece MCP üzerinden konuşmasını hayal etmek fazla abartı
  • Ben MCP’yi, Claude gibi ortamlarda API maliyeti olmadan function call yapmayı sağlayan eklenti tarzı bir entegrasyon çözümü olarak görüyordum. Zaten API kullanıyorsan ve acelen yoksa, aslında pek de gerekli bir seçenek değil
  • Aslında MCP’nin istemci ile modeli bağlayan standart bir protokol olduğunu düşünüyorum. Sadece tool çağrılarını saran bir kap değil
  • Evet, her API için bir MCP sunucusu koymak ölçeklenebilir bir yapı değil. nango.dev gibi bir şey kullanırsan tek bir sunucuda 400’den fazla API’yi kapsayabilirsin. Kimlik doğrulama yönetimi, görünürlük ve doğrudan tool call yapılabilen çeşitli arayüzler de sunuyor. (Bu arada ben kurucusuyum)
  • Ben bir adım daha ileri gidip, LLM’yi JSON çıktıya zorlamanın kültür olarak baştan saçma olduğunu düşünüyorum. Modelin doğal olarak sevmediği, zorlayıcı bir formata uydurmak için gereğinden fazla zaman ve emek harcanıyor. Çok daha kısıtlı bir metin tabanlı DSL çok daha iyi bir alternatifti. Eski GPT 3.5 döneminde prompt’a birkaç basit örnek vermek bile İngilizce tabanlı DSL’i güvenilir şekilde üretmeye yetiyordu. Ama en yeni modeller için bile JSON schema’nın bazı kısımlarının bazen yok sayıldığına dair uyarılar var. Kare deliğe yuvarlak çivi çakmaya çalışmak gibi; keşke herkes bunu zorlamasa
• Artık kimliği doğrulanmış MCP sunucularına giden basit bir yol oluşmuş olmasına gerçekten seviniyorum. MCP topluluğuna ve Anthropic ekibine içten teşekkür etmek istiyorum
  • MCP sunucularına neden ihtiyaç olduğunu pek anlamıyorum. Agent RPC yapmak istiyorsa, neden doğrudan RPC kullanmasın?
• Çekirdek spesin OpenAPI ya da başka bir şey yerine TypeScript ile yazılmış olması bana gerçekten ilginç geliyor. Geçerli bir nedeni vardır elbette ama yine de şaşırtıcı
  • Bunun neden şaşırtıcı olduğunu merak ettim. Ben de TypeScript’i çok kullanıyorum ama bu açıdan hiç düşünmemiştim; dil tasarımı tarafında nasıl bir karar verildiğini merak ediyorum
• WWW-Authenticate challenge’ın eklenmesi harika bir gelişme. Artık MCP sunucusunun istemciyi kaynak sağlayıcının OAuth akışına yönlendirmesi ve sonra sadece Authorization: Bearer ... başlığını alması gereken tablo netleşmiş oldu
• <i>Çoğunlukla</i> bunun gereksiz karmaşıklık olduğuna katılıyorum ama batch execution özelliğini özleyeceğim. “Bütün bu işleri yap, sonra sonucu tek seferde dön” yaklaşımını uygulamak eğlenceliydi. Elbette istemci batch yanıtlarını kendi tarafında birleştirebilir ama yine de keyifliydi
  • Aynen. JSON-RPC batch özelliği gerçekten “vay, bu ilginçmiş” dedirten bir şeydi. Spesten çıkmasına üzüldüm ama sonuçta sadece karmaşıklığı artırdığı tarafı da var, o yüzden anlıyorum
• elicitation’ın (çıkarıma dayalı prompt işleme) büyük kazanç olduğunu düşünüyorum. En sevdiğim MCP sunucularından biri kendi yaptığım SSH sunucusu. Sunucu işlerimin %90’ını otomatikleştirebiliyor. Kimlik doğrulamayı bir yapılandırma dosyasıyla yönetiyorum ama yeni bir sunucuya bağlanmam gerektiğinde dosyayı elle düzenlemek biraz uğraştırıyor
  • Böyle durumlarda fabfile.org gibi bir şey de kullanılabilir diye düşünüyorum. LLM eklemeyi gerektirmeyen bir konuşmaysa özel kalması daha iyi olabilir
• Son birkaç gündür MCP ile bir veri kümesi sarmalayıcısı yaparak oynuyordum

1. Bunun LLM alanındaki en heyecan verici denemelerden biri olduğunu düşünüyorum. Elbette mevcut API ve tool call ile de benzer şeyler yapılabilir ama teknik olmayan bir arkadaşa sadece Claude için bir MCP URL’si atıp birkaç tıklamayla denemesini sağlamak gerçekten etkileyiciydi
2. csharp SDK kullanıyorum ve kimlik doğrulama özelliği hâlâ sadece bir branch’te olduğu için çok erken aşamada. MCP entegrasyonunun %95’i kimlik doğrulamayı hayata geçirmekle geçti (lokal build değilse zorunlu). Belgeler arttıkça düzelir ama şu an oldukça zahmetli bir süreç
3. Geliştirici loglarının görünürlüğü de yetersiz. Claude’un web’de (masaüstü değil) ne gönderip aldığını, hatanın nerede çıktığını geliştirici modunda request/response loglarıyla görmek isterdim. Kimlik doğrulama yenileme sorunuyla uzun süre uğraştım ve ancak sonra yanlış endpoint’i logladığımı fark ettim. Daha iyi MCP loglama olsaydı bu iş birkaç dakikada biterdi. Masaüstü ve MCP inspector’da düzgün çalışıyor
4. En büyük sorunum uzun süren işleri ele alma konusu. Açığa çıkardığım veri kümesi birden fazla PDF belgesinden oluşuyor. Claude’un PDF’leri doğrudan işleyebilmesi mümkün görünmüyor (bilen varsa söylesin lütfen!), ben de şimdilik önce gemini ile metne çevirip sonra MCP üzerinden veriyorum. Basit belgelerde iyi çalışıyor ama uzun belgelerde işlem süresi uzuyor. Şu an sadece “işleniyor, lütfen daha sonra tekrar deneyin” mesajı gönderiyorum. Bir progress API var ama sunucuya sürekli bağlı kalmak gerektiği için (Cloudflare üzerinde bir süre sonra bağlantı kopuyor) pratikte sınırlı görünüyor. LLM’nin x saniye sonra tekrar kontrol etmesini, o zamana kadar başka iş yapmasını sağlayan ve zamanlayıcı bitene kadar “çalışması geçici olarak askıya alınan” bir model olsa harika olurdu. Şu anda ya bağlantı açıkken LLM hiçbir şey yapamadan bekliyor ya da job ID verip dönünce eksik yanıt üretilip genel bağlam kayboluyor. 10 dakikadan uzun süren işler için bu ciddi bir engel olabilir

• Uzun süren işler hâlâ açık şekilde tartışılan bir konu. Bildiğim kadarıyla MCP’nin bunu ileride çözme niyeti var. Çeşitli öneriler dolaşıyor ve bir işin uzun süreceği her zaman baştan bilinmediği için, uzun iş API’sini ayrı yapmak tek başına çözüm değil. Bu konuyu bütünleşik ele almak için benim de bir önerim var discussion link
• MCP spesinin hızlı şekilde gelişiyor olması çok sevindirici. Her yeni sürümde, daha önce MCP entegrasyonlarında eksik bulduğum bir noktanın tamamlandığını görüyorum
• Spes değişikliğinin birleştirilmesi için sadece tek bir onay gerekmesi bana ilginç geliyor
• MCP’nin gerçekte neyi çözdüğünü pek anlamıyorum. Kişisel olarak aklıma gelen tek şey, laptop üzerinde hızlı prototipleme yaparken işe yarayabileceği. Yerel bir program geliştiriyorsam, LLM’nin erişebileceği araç setini çok daha ayrıntılı kontrol etmek isterim. Örneğin Google Calendar için bir MCP sunucusu düşünsek bile, MCP ciddi bir zaman kazancı sağlamıyor. Aynı API’yi ben doğrudan da kullanabilirim ve LLM’ye Google Calendar’ı ne zaman, nasıl çağıracağını açıkça söylemem gerektiği için bunu üçüncü bir katmana bırakmak istemiyorum. Ayrıca MCP hangi dilde yazılmış olursa olsun, kendi ortamımda rastgele prosesler çalıştırmak da beni rahatsız ediyor. Benim tarafım Python’sa ve kullanıcıdan ayrıca bir TypeScript runtime kurmasını isteyeceksem bu sorun olabilir. MCP wrapper’ında bir açık çıkarsa güvenlik tarafı da endişe verici. Sunucu ortamında bunu meşrulaştırmak daha da zor. Farklı makinelerde uygulama ayrıntılarını bilmeden çağrı yapmanın zaten çok iyi bir yolu var: RPC. MCP ise bunun üstüne sadece fikir dayatan middleware ve güvenlik sorunları ekliyor gibi geliyor
  • Benim anlamadığım şey, şimdiye kadar gördüğüm tüm MCP’lerin neden komut tabanlı olduğu ve HTTP arayüzü kullanmadığı. HTTP olsaydı tek bir sunucu ayağa kaldırılıp tüm organizasyon tarafından paylaşılabilirdi, herkesin kendi toolchain kurulumunu yapmasına da gerek kalmazdı
  • Klasik backend’lerin sabit akışlar dayatmasının aksine, MCP kullanınca orkestrasyonu doğrudan LLM’nin yapabilmesi avantaj sağlıyor. Örneğin web aramasında sorguyu tekrar tekrar düzenleyip istediği bilgiyi bulana kadar deneyebilir. CLI ile özel bir problemi çözerken de birden çok aracı uygun sırayla kullanabilir. Bu, sabit akışlarla yapılamayan bir organizasyon biçimi
  • MCP’nin çözdüğü şey, LLM merkezli bir yapıda agent’i, tool’ları ve başka yetenekleri standartlaştırılmış bir protokolle birbirine bağlamak
  • Buna ben de güçlü biçimde katılıyorum. Gerçekte kullanınca çok yavaş hissettiriyor. Ben 2 yıl önce LLM istemcisi geliştirmek için işimi bıraktım ama hâlâ Google Calendar entegrasyonu yapabilmiş değilim. Yine de kullanıcı açısından, bu tür geçici boşlukları doldurabilmesi MCP’nin işe yarar tarafı. Eskiden iPhone ana ekranının ilk 3 satırı birbirine benzerdi ama son satır herkes için bambaşka olurdu diye bir örnek vardı, onu hatırlatıyor. Bundan sonra da IT ekipleriyle geliştirici ekiplerinin kendi iş akışlarına uygun MCP sunucuları yapmaya devam edeceğini tahmin ediyorum