MCP'ye Eleştirel Bir Bakış

• MCP(Model Context Protocol), LLM'lerin dış dünyayla etkileşim kurması için standartlaştırılmış bir entegrasyon yöntemi sunar
• Son dönemde IBM'in ACP'si ve Google'ın A2A'sı gibi benzer standartlar ortaya çıkarken, MCP uygulamaları ve ilgili araçlar da hızla artıyor
• Ancak tasarımdaki kafa karışıklığı, yetersiz dokümantasyon ve fiili protokol belirtiminin eksikliği gibi olgunlaşmamış mühendislik pratikleri sorun olarak gösteriliyor
• HTTP+SSE ve Streamable HTTP gibi şu anda önerilen taşıma yöntemleri, karmaşıklığı ve güvenlik sorunlarını artırıyor; alternatif olarak WebSocket öneriliyor
• En güncel protokol, yetkilendirme ve oturum yönetimi tarafında tutarsız ve aşırı karmaşıklık ekliyor

---

MCP ve son gelişmelere bakış

• MCP, uygulamaların büyük dil modellerine (LLM) bağlam sağlamasının yolunu standartlaştırmak için oluşturulmuş açık bir protokoldür
• Son bir ayda MCP, LLM'leri ajanlara dönüştüren temel standart olarak öne çıktı ve kullanımıyla uygulamaları hızla yayılıyor
• IBM'in ACP'si veya Google'ın A2A'sı gibi, benzer amaçlara sahip daha ortodoks standartlar da hızla ortaya çıkıyor

Mühendislik pratikleri ve protokol belirtimi sorunları

• Gerçek uygulama ve dokümantasyon seviyesinin düşük olduğu birçok yerde görülüyor
• Büyük teknoloji şirketleri model eğitimine devasa yatırımlar yaparken, SDK'lar ve dokümantasyon düşük seviyede kalıyor ve bu da kullanıcıların kafasını karıştırıyor
• MCP de benzer sorunlar gösteriyor; bazı tasarımlar mantıksız ve belirtim, örnekler ile kılavuzlar yetersiz durumda

Taşıma protokolü tartışması

stdio taşıma yöntemi

• Stdio, MCP sunucusu ile istemcisini yerelde pipe(stdout, stdin) üzerinden doğrudan bağlayan geleneksel bir yöntemdir
• Karmaşık soket işlemleri veya işletim sistemine özgü sorunlar daha azdır ve ortam değişkenleriyle giriş/çıkış akışları gibi sade bir ortam yapılandırması sağlar

HTTP+SSE / Streamable HTTP yöntemi

• Web çağına uyum sağlamak amacıyla HTTP tabanını da destekleme niyetiyle HTTP+SSE ve Streamable HTTP yöntemleri benimsendi
• Ancak bu yaklaşım, WebSocket'in yerine geçmeyi hedeflerken tersine daha fazla belirsizlik, tasarımsal kafa karışıklığı ve karmaşıklık yaratıyor
• Tek bir oturum ve bağlantı birden fazla yolla oluşturulup sonlandırılabildiği için, sunucunun durum yönetimi ve güvenlik tarafında büyük bir yük oluşturuyor

MCP sunucu/istemci uygulama örneklerinde yaşanan zorluklar

• Resmî Go SDK eksikliği gibi, birçok dilde desteğin yetersiz olması belirgin bir sorun olarak öne çıkıyor
• Dokümantasyon ve belirtim net olmadığı için, uygulamayı gerçekte tersine mühendislik yoluyla yapmak gereken durumlar sık görülüyor
• Örnek sunucuların çoğu Python, JavaScript tabanlı olsa da, bağımlılık ve taşınabilirlik sorunları yüzünden bunları üretim ortamında uygulamak zor
• Sunucu geliştirirken SSE/Streamable HTTP soketmiş gibi davranıyor; ancak gerçekte oturum ve bağlantı durumunu tutarlı şekilde korumak zor ve mesaj kuyruğu gibi ek altyapılar gerekiyor

HTTP+SSE ve Streamable HTTP'nin yapısı ile sorunları

HTTP+SSE modu

• İstemci sunucuyla bir SSE oturumu açar; ayrı bir endpoint'e yazma isteği gönderdiğinde sunucu 202 yanıtı döner ve cevabı mevcut SSE bağlantısı üzerinden iletir
• Oturum bağlantısını ve durum eşzamanını korumak gerekir; ancak bu süreç hem yetersiz belgelenmiş durumda hem de işletim karmaşıklığı çok yüksektir

Streamable HTTP modu

• Oturum oluşturma, SSE açma ve yanıt iletimi için birden çok yöntem birlikte kullanıldığı için tek bir istek-yanıt akışı tutarlı değildir
• Birden fazla durum yönetimi, çeşitli endpoint'ler ve header yöntemlerinin iç içe geçmesi, fiili uygulama ve ölçeklenebilirlik açısından ciddi engeller yaratır

Genel etkiler

• Teknik karmaşıklık arttıkça, geliştiricinin bilişsel yükü ve bakım maliyeti büyür; ayrıca farklı sunucu ve istemci uygulamaları arasında uyumluluk tutarsızlıkları ve öngörülemez davranışlar ortaya çıkar
• Sunucunun tüm durumları ve bağlantı koşullarını takip etmesi gerekir; dağıtık ortamlarda ise verimli ölçekleme ve durum eşzamanı daha da zorlaşır

Güvenlik etkileri

• İnce parçalı ve çeşitli bağlantı/oturum yöntemleri, oturum ele geçirme, yeniden oynatma saldırıları ve hizmet reddi (DoS) gibi durum yönetimi kaynaklı güvenlik açıklarını artırır
• Birden çok giriş noktası ve yanıt yöntemi saldırı yüzeyini genişletir, ayrıca istenmeyen akışlar üzerinden kötü niyetli faaliyetlerin gizlenmesini mümkün kılar

Yetkilendirme protokolündeki kafa karışıklığı

• Mevcut belirtim, yalnızca HTTP taşımada OAuth2 gibi yöntemleri zorunlu kılarken, STDIO taşımada ise keyfî biçimde ortam değişkeni kullanımı gibi tutarsız kurallar uyguluyor
• Neden yalnızca HTTP taşımasının karmaşık OAuth2 uygulamasını zorunlu kıldığı gibi kafa karıştırıcı ve mantıksız noktalar var

İyileştirme önerileri

• Tek bir JSON RPC protokolü üzerinde, taşıma yöntemlerinin fiilen yalnızca Stdio ve WebSocket etrafında sadeleştirilmesi gerekir
• Stdio ortamındaki değişkenlerin HTTP ortamındaki header'lara, giriş ve çıkışların ise sırasıyla WebSocket'in çift yönlü akışlarına eşlenmesi daha uygun olacaktır
• Böylece gereksiz oturum takibi, durum yönetimi ve sayısız istisna işleme ihtiyacı ortadan kaldırılabilir
• WebSocket, tüm HTTP tabanlı taşımalar için standart seçenek hâline gelmeli; karmaşık durum eşzamanı sorunlarını da çözebilir

Alternatif protokollerle karşılaştırma ve pazar eğilimleri

• IBM'in ACP'si ve Google'ın A2A'sı, ajanlar arası birlikte çalışabilirlik açısından daha sade bir taşıma tasarımı ve ajan keşif özellikleri sunuyor
• Ancak özünde bunların çoğu, MCP kurulum ekosistemi içinde ayrı araçlar olarak entegre edilebilecek düzeyde
• Yeni protokollerin sürekli ortaya çıkması standartların çoğalması riskini doğurduğundan, taşıma tarafındaki sadeliğe öncelik vermek sektörün büyümesi için önemlidir

[GN⁺]

Hacker News görüşleri

• LLM satıcılarının yazdığı belgelerin kafa karıştırıcı olmasının nedeni, belgeleri bizzat LLM kullanarak yazmaları olduğuna eminim; bu çok kötü bir yaklaşım, özellikle de spesifikasyon çalışmalarında LLM kullanmak, iyi doküman yazımında LLM kullanmaktan çok daha kötü. Spesifikasyonu yazma sürecinin kendisi asıl önemli kısım; insan tasarımcıların dikkatle kusurları ve eksikleri bulup farklı durumları ele alması gerekirken MCP spesifikasyonunda böyle bir insani muhasebenin izleri pek görünmüyor. O kendine özgü düz üslup, dağınıklık ve liste ağırlıklı yapı tam bir LLM çıktısı gibi duruyor.
  • DeepSeek'in dokümanlarında ise sorun, tersine, yazım ve dilbilgisi hatalarının çok fazla olması. Gün boyu dille uğraşan, hatta bir dönem dünyanın en iyi İngilizce LLM'lerinden birine sahip olan böyle bir şirketin profesyonel görünecek düzeyde belge üretememesi gerçekten tuhaf.
  • Ben de bu spesifikasyonun LLM tarafından yazıldığına güçlü biçimde inanıyorum; bütün işaretler bunu gösteriyor. Çoğu ürünün zaten en makul görünen sonucu ortalamaya alan şekilde üretildiğini ve bunun yatırımcılara anlatılacak bir IPO hikâyesi olduğunu tahmin ediyorum.
  • Eğer bu doğruysa gerçekten üzücü. Anthropic'te çok zeki insanlar da var; buna rağmen önemli bir ekosistemin çekirdek bileşeninde böyle bir şey yaşanması talihsiz.
  • Ancak şimdi fark ettim ki AI coding satıcılarının dokümanları bilerek anlaşılmaz hâle getirmek için bir motivasyonu olabilir. İnsanların anlayamadığı, sadece kendi yapay zekâlarının yorumlayabildiği kodlar üreterek kullanıcıları kendi özel AI hizmetlerine tamamen bağımlı kılmak isteyebilirler. Eğer iki yıl içinde gerçek programcıların yerini tamamen alamazlarsa bu strateji tüm tüketicileri yok edip kendi pazarlarını da çökertir. Sonunda geriye yalnızca insanların ve yapay zekânın karşılıklı çeviremeyeceği dev bir kod yığını kalır.
  • LLM tarafından yazılmış düzyazıyı okurken dikkatimin dağılması sadece bana özgü bir sorun değil sanırım; makinelerin ürettiği o tekrarlı ve bağlamsız metinlerin derin düşünce içermediğini ve giderek duygusal yorgunluk bile verdiğini hissediyorum. Aynı türden LLM'ler teknik spesifikasyon da yazmaya başlayınca, yazarın bile anlamadığı şeylerin bilinçsizce metne karışması kaçınılmaz oluyor. Bu beni giderek daha fazla kaygılandırıyor.
  • DeepSeek'in dokümanları genel olarak o kadar da kötü görünmedi. Hızlıca kotarılmış gibiydi ama kötü bir seviyede değildi. Bu da, LLM doküman yazarsa sonuç her zaman kötüdür düşüncesinin istisnaları olabileceğini gösteriyor.
• Bugünlerde LLM alanı, yazılım paradigmasını sanki hile kodu kullanır gibi hızla taklit ediyor. Uzak fonksiyonları açığa çıkarma yöntemleri için geçmişte DLL, gRPC, SOAP, IDL, dCOM gibi pek çok örnek vardı; ama bugünkü LLM çevreleri bunların varlığından bile habersiz gibi görünüyor. Zamanla olgunlaşmasını bekliyorum ama sonuçta eldeki ödevi yapmak gerekiyor.
  • Birkaç ay daha geçince elbette olgunlaşacaktır ama erken Python ekosistemine bakınca, hataların alt katmanlarda yerleşip herkesin onun üstüne yeni araçlar yığdığı dönem aklıma geliyor. Üstelik bu kez geçmişte yapılmış aynı hataların tarihi zaten ortadayken AI ekosisteminin yine aynı yoldan gidiyor olması daha da üzücü.
  • MCP ile ilk karşılaştığımda aklıma COM/DCOM geldi, eski DLL Hell günlerini hatırladım. Bundan sonra MCP'nin nasıl gelişeceğini izleyeceğim.
  • Hâlâ MCP'nin tam olarak ne olduğuna dair açıklayıcı bir anlatım bulamadım; eski geliştirme dilleri açısından buna ne denebileceğini merak ediyorum.
  • Böyle katı ve deklaratif protokollerde LLM'nin potansiyel anlam uzayı ve semantik gücü kayboluyor demek istiyorum. Belki sadece web root'a bir agents.json dosyası koyup semantik bir diyalog üzerinden agent'ların işi kendi kendine çözmesi daha sezgisel olabilirdi. Sonuçta HTTP, agent'ların standart giriş/çıkışı olurdu.
  • Verilen örneklerin hepsinin yerinde olduğunu düşünüyorum.
  • MPC'nin JSON-RPC tabanlı olup olmadığını merak ediyorum.
• Yazının genel çerçevesine katılıyorum. Özellikle MCP sitesinde somut bilgi bulamayıp yaşadığım şaşkınlığı paylaşıyorum. RFC'ler okumak zordur ama "sadece SDK kullan" yaklaşımından çok daha iyidir.
  • Keşke daha fazla kişi bu blog yazısının önemini fark etse. MCP benimsenmesini kısa süreliğine durdurup temelde sağlam bir teknik zemin olup olmadığına yeniden bakmak gerekiyor. Çok fazla coşku var ama uygulamanın derinlerine indikçe hayal kırıklığı yaşanacaktır. Özellikle çekirdek işlevlerde websocket gibi çeşitli tercihler soru işareti yaratıyor; hepsi değil ama genel olarak aceleyle yapılmış bir geçici çözüm hissi veriyor.
  • Sitede açık bir spesifikasyon olmaması üzücü. Spesifikasyonun yarısı sanki Sonnet'ten çıkarılmış gibi ve protokolün gerçekte nasıl çalıştığı net biçimde anlatılmıyor. Buna karşılık GraphQL spesifikasyonu çok daha iyi yazılmış.
• Şu anda AI alanındaki işlerin büyük kısmı matematikçiler, (veri) bilim insanları, öğrenciler ve amatör meraklılar tarafından yapılıyor. Profesyonel yazılım mühendisliği standartlarından bakınca bunların çoğu ancak hafta sonu projesi düzeyinde olgun görünüyor.
  • Ben ise işlerin çoğunu gerçekten profesyonel yazılım mühendislerinin yaptığını düşünüyorum.
• MCP en başından beri stateless HTTP ile gitmeliydi. Çoğu sunucuda durum tutmaya gerek yok; küresel ölçekte durum saklamak ya da yalnızca bir oturum tanımlayıcısı bulundurmak yeterli olurdu.
  • MCP'nin gerçek etkileşim yapısını anlayamıyorum. Neden stateless olmadığını, neden bağlantının sürekli açık tutulması gerektiğini bilmek istiyorum.
  • Kişisel deneyimim sınırlı ama isteğin ardından bağlantıyı kapatırsanız bir sonraki istek için yeniden bağlanmanız gerekir. Oturumun açık mı kapalı mı tutulacağı kullanım deseni, bellek tüketimi gibi birçok değişkene bağlıdır.
• Ben Ruby on Rails tabanlı bir MCP hizmeti olan ninja.ai'yi geliştiriyorum; bu, tek tıkla MCP sunucusu kuran bir uygulama mağazası. İstemci cihazına Model Context Protocol sunucularını Tauri ile kuruyoruz. Rails ile bulut MCP sunucuları da sağlıyoruz. HTTP+SSE ya da Streamable HTTP özelliklerine eleştirel bakıyorum; çift yönlü gerçek zamanlı iletişim için WebSockets daha iyi ve Rails'in SSE desteği sınırlı olduğu için endpoint'leri Falcon web sunucusuna taşımak zorunda kaldım. Shopify mühendislerinin neden Streamable HTTP'yi seçtiğini merak ediyorum; muhtemelen altyapı veya dağıtım kısıtlarından kaynaklanıyordur. MCP'nin taşıma katmanının soyutlanmış olması da önemli; gelecekteki uygulamalarda WebSockets veya WebRTC'nin benimsenmesi gayet mümkün.
• Ben MCP kayıt dizinlerinden birinin (glama.ai/mcp/servers) işletmecisiyim. Yazarın görüşlerine kısmen katılıyorum ama protokol hâlâ çok erken aşamada ve önümüzde ciddi değişiklikler olabilir. Beklenenden çok daha fazla ilgi gördü; en başta birkaç düzine sunucu varken bir anda binlerce sunucu ortaya çıktı ama gerçekten çalışanlar bunların yalnızca bir kısmı olduğu için ayıklamaya çok zaman harcıyoruz. Bu, MCP olgunlaşmadan önce kamuoyunun dikkatini çekmesinin sonucu. Buna rağmen son dönemde kod çatıları, kayıt dizinleri, MCP destekleyen istemciler gibi ekosistem bileşenleri şaşırtıcı derecede hızlı büyüdü. Daha altı ay önceye kıyasla bu ölçekte değişim benzeri görülmemiş bir şey. Bu hız sürerse görünümün parlak olduğunu düşünüyorum. Yeni başlayanlar için yararlı bir kaynak derlemesi de sunuyorum.
  • Protokol tasarımının başında hata yaparsanız o hatayı sonsuza kadar taşımak zorunda kalırsınız; bu yüzden spesifikasyonun alçakgönüllü biçimde kurgulanması gerekir. SSE gibi bir Rube Goldberg makinesi kalıcı hâle gelip sonradan düzeltilemeyebilir. Enterprise seviyesinde protokolü bozan değişiklikler yapmak kolay değildir; bu yüzden başlangıç kararlarına uzun süre mahkûm kalabilirsiniz.
  • MCP protokolünün zaman içinde gelişmesi zaten beklenen bir şey. Daha en başta kusursuzluk beklemek asıl garip olurdu. Her şeyden önce agentic API standardizasyonu gerçekten güçlü bir değişim yaratıyor. Kendi kodunuzu yazıp dağıttığınızda AI'nın bunu hemen fark edip otomatik kullanabilmesi, yaşamadan tam anlaşılmıyor.
  • Benim kaygım, bu hız içinde MCP'nin uzun ömürlü olmayabilecek bir taşıma katmanı tasarımını fazla erken benimsemesi. Bu bana 90'lardaki tarayıcı savaşları gibi, standartların uzun süre bölünmüş kaldığı dönemleri hatırlatıyor; tıpkı IE11'in gereğinden fazla uzun süre ortada kalması gibi.
• Yetkilendirme (Authentication) etrafındaki tartışma için zaten güncelleme çalışmaları yapılıyor. Anthropic ve güvenlik topluluğuyla birlikte MCP içinde kaynak sunucusu (RS) ile yetkilendirme sunucusu (AS) rollerinin ayrılması uygulandı. Yeni protokol sürümü resmileşene kadar geçici olarak bir taslak spesifikasyon yayımlandı.
  • MCP spesifikasyonunun ne kadarının LLM çıktısı olduğunu merak ediyorum. Sürekli alarm zilleri çaldığı için bunu içgüdüsel olarak mı sezdim diye düşünüyorum.
  • Ben görece tarafsızım ama OAuth taslağının sadece üstünkörü kopyalanmış gibi durmasından ve HTTP kullanıldığında seçme şansı olmadan bunun dayatılmasından hoşnut değilim. Aslında istemci ve sunucunun OAuth2 desteğini isteğe bağlı olarak sunabileceği daha net bir düzenleme yapılabilirdi.
• MCP'nin Streamable HTTP çıkışıyla ilgili olarak her şeyin basitçe HTTP istekleri olarak tasarlanıp tasarlanamayacağını soran bir issue açmıştım. MCP spesifikasyonu LLM ile araçları bağlamak için genel amaçlı bir çözüm olarak umut verici ama pratikte kimlik doğrulama, akış, araç başına özel komutlar, araçların güvenilirliğini doğrulama gibi pek çok zorluk var. Bence yalnızca REST API üzerinden entegrasyon yapmak daha basit. OpenAI ya da Gemini gibi şirketler de MCP'yi benimseyeceklerini söyledi ama yakında spesifikasyonun istemedikleri UI veya etkileşim katmanlarıyla uyuşmaması ya da markalarıyla örtüşmemesi, hatta yetkilendirmenin ele geçirilmesi gibi sorunlarla karşılaşacaklarını tahmin ediyorum.
  • Anthropic MCP'yi kurmuş olsa da, ölçek bakımından ChatGPT ile kıyaslanamayacak kadar küçük. OpenAI ve Google gibi büyük şirketlerin, dışarıdaki tek bir ekibin kullanıcı deneyiminin sınırlarını belirlediği bir spesifikasyonu uzun süre kabul edip etmeyeceği şüpheli. Geçmişte ChatGPT Plugins'in, şık mühendislikten çok tüketici deneyimi sınırları nedeniyle başarısız olması gibi bir örnek var. Yine de güçlü bir topluluğun itici gücüne umut bağlamaya hazırım.
  • Bu blog yazısını yayımladıktan sonra ben de benzer bir issue açmıştım. Konu gerçekten çok önemli; yanlış yapılırsa geri dönüşü zor olur diye düşünüyorum.
• MCP'nin neden bu kadar popüler olduğunu anlamıyorum ama her hâlükârda şu an bir trend. OpenAPI spesifikasyonuyla kıyaslandığında MCP'nin hangi açılardan daha iyi olduğuna dair bir açıklama duymak isterim.
  • Bence MCP popülerliğinin büyük kısmı, son dönemde LLM'lerin araç kullanma becerisinin gerçekten iyileşmiş olmasından geliyor. 2023'teki OpenAI plugins başarısız olmuştu çünkü o dönem LLM'ler araç kullanımında yeterince güvenilir değildi; MCP ise çok daha doğru bir zamana denk geldi.
  • MCP sunucusunu ilk kez ayağa kaldırmak çok kolay ve giriş bariyeri düşük; bu da büyük bir etken. Araç sayısı arttıkça LLM'ye gönderilen metin de artıyor ama OpenAPI sağlandığında bile tek tek path detayları ve açıklama mesajları verilerek Claude ile gayet başarılı entegrasyon kurulabiliyor.
  • MCP'nin önemli olmasının sebeplerinden biri de şu: OpenAPI statik bir belgedir ve LLM'nin tüm istek üretim sürecini üstlenmesi gerekir, oysa MCP sunucusu bu yükü soyutlamayla azaltır. Sonuç olarak LLM açısından daha kolay, daha hızlı ve daha güvenlidir.
  • MCP'nin kusursuz olduğunu düşünmüyorum ama LLM'ler için OpenAPI'den daha uygun olduğu bazı yönler var. Öncelikle MCP araçları çok daha kısa ve basit biçimde tanımlanabiliyor; OpenAPI spesifikasyonları ise fazla büyük olup LLM bağlamını gereğinden çok doldurabiliyor. LLM aslında gerçek çağrıyı oluşturmuyor, yalnızca çıktı metni üretiyor; bu yüzden MCP yaklaşımı daha doğal geliyor. Ayrıca MCP, araç ekleme/değiştirme gibi dinamik yapılara çok daha esnek biçimde uyum sağlıyor; OpenAPI'nin statik sınırlarını aşıyor. Elbette sorunları da var, özellikle taşıma katmanında iyileştirme alanı açık; ama önde gelen kütüphaneler de oldukça iyi uygulanmış durumda.