Web 2.0 2.0'ın gelişi: MCP

• Model Context Protocol (MCP) hızla benimsenerek yeni bir açık standart olarak öne çıkıyor
• MCP'nin temel değeri kusursuzlukta değil, açıklık ve birlikte çalışabilirlikte yatıyor
• Web 2.0'ın gerçek anlamı kapalı platformlar değil, açık API'ler ve veri paylaşımıdır
• Geçmişteki kapanma döneminden yeniden açık webin değerlerine dönüş yönünde bir akım ortaya çıkıyor
• MCP'nin benimsenmesiyle geliştiricilerin platform kontrolü ve şeffaflık taleplerini daha da artırabileceği gündeme geliyor

---

MCP: Yeni açık webin ortaya çıkışı

Son birkaç ayda geliştiriciler arasında Model Context Protocol (MCP) konusuna ilgi patlayıcı biçimde arttı. Başlangıç noktası, Anthropic'in 2023'te kendi LLM (Claude) sisteminin çeşitli uygulamalarla etkileşim kurabilmesi için bunu tasarlamasıydı. Ardından OpenAI'ın ChatGPT'de aynı protokolü desteklemesiyle birlikte hızla bir standart haline geldi. Şimdi Windows tarafından da benimsenmesiyle başlıca platformlara yayılıyor.

İlginç olan nokta, MCP'nin netliği ya da tamamlanmışlığı değil, kullanım kolaylığı ve hızı. Geleneksel olarak titizlikle tasarlanan standartların aksine MCP, bir miktar muğlak ve gevşek tanımlanmış bir spesifikasyon olmasına rağmen pratikte iyi çalışmasıyla önemli bir güç kazanıyor. Her şeyden önce, herkesin kullanabildiği bir açık protokol olması büyük önem taşıyor.

Gerçek açık webin anlamı

Gerçek dünyadaki web ortamında, kusursuz olmayan ve bir miktar eksik standartlar hızla benimsendiğinde gerçek ilerleme sağlanır. Bu tür akışlar, "podcast'leri dinlediğiniz her yerde dinleyin" gibi yenilikleri ortaya çıkardı.

Web 2.0'ın ruhu; açık API'ler, veri paylaşımı, kullanıcı ve geliştiricilerin denetim gücünün artması gibi açık bir ekosistemi hedefliyordu. Facebook gibi kapalı platformların, Web 2.0'ı ortadan kaldıran aktörler olduğuna dikkat etmek gerekiyor. Geçmişte Flickr, del.icio.us, Upcoming gibi servisler paylaşım ve bağlantıyı önceleyen kültüre öncülük etti; canlı blog gibi platformlarda da API/protokol açık standartları üzerine tartışmalar yoğundu.

Açığın geri dönüşü

Bir nesil geçtikten sonra, birlikte çalışabilirlik beklentilerinin yeniden yükseldiği bir dönemdeyiz. Geçmişte büyük teknoloji şirketlerinin kapalı politikaları nedeniyle API'lerin engellenmesi ve servislerin ortadan kalkması tekrar tekrar yaşandı. Örneğin yazarın geliştirdiği sosyal ağ veri analizi aracı, sonunda platform tarafının API engeli nedeniyle kullanımdan kalktı. Bu tür politikalar, Web 2.0'ın açık veri ve uyumluluk vizyonunu çökertti. Sonuç olarak içerik gömmemenin mümkün olmaması, veri taşınabilirliğinin engellenmesi gibi sorunlar gündelik hale geldi.

Ancak MCP'nin ortaya çıkışıyla yapay zeka bir tetikleyici olarak programlanabilirliğin ve açıklığın yeniden yükselişini mümkün kılabilir. Birden fazla platformun aynı protokolü benimsemesi, teknoloji temelli olumlu bir döngü kurulmasına olanak tanıyor.

Platformlar protokolü olduğu gibi kabul edip standardizasyona sadık kaldığında ekosistemin tamamında olumlu değişimler yaşanır. Geliştiricilerin "standarttan daha iyisini yapmak" isteğinin paradoksal biçimde ekosisteme zarar verebileceği vurgulanıyor. HTML gibi teknolojiler de kusursuz spesifikasyonlar değildi, ancak sonuçta internetin büyük ölçekli birlikte çalışabilirliğinin temeli oldular.

Standartlara uyumun önemi

Yeni geliştirici kuşağı, aynı protokol ve format temelli yeniliğin gücünü doğrudan deneyimliyor. Bu deneyim, yeniden açık standartlara yönelik güçlü bir bağlılığa dönüşebilir. Geçmişte RSS, Podcast, OpenID, OAuth, OpenSocial gibi açık formatların kullanıcılara gerçekten güç verdiği döneme benzer bir atmosfer yeniden oluşuyor.

Bugün artık yalnızca büyük şirketlerin belirlediği bir dönem değil; geliştirici ve kullanıcı topluluklarının kendi taleplerini ileri sürebileceği bir an. Herkesin platformlardan deneyim üzerinde kontrol ve şeffaflık talep edebilmesi gerekiyor ve MCP gibi açık standartlar benimsenirken platform iç işleyişiyle veri kullanımına dair şeffaflığın mutlaka desteklenmesi gerekiyor. MCP açık olsa da iç işleyiş ve güvenlik meselelerinde hâlâ eksik olduğu için sonraki iyileştirmelere ihtiyaç duyuyor.

Web 2.0 ruhunun geri dönme ihtimali

MCP tüm sorunları çözen sihirli bir çözüm değil, ancak Web 2.0 dönemindeki açık ekosistemin geri dönüşünü tetikleyebilecek bir fırsat gibi görünüyor. Yapay zeka tartışmalarındaki abartı ve eleştiri eksikliği gibi sınırlamalar ise sürüyor.

Buna rağmen özellikle genç geliştiriciler arasında programlanabilir web ve kapalılıktan uzaklaşma değerleri yeniden öne çıkıyor. Web, yalnızca birkaç dev şirketin mülkü değil; herkesin istediği şekilde kullanabildiği açık bir alandı ve MCP'nin bu felsefeyi yeniden çağırma ihtimali gündeme geliyor.

[GN⁺]

Hacker News görüşü

• Birçok kişinin MCP’nin özünün kurumsal yazılıma uygun olmasını gözden kaçırdığını düşünüyorum; LLM’ler bir tür evrensel çevirmen gibi, birbirine bağlanması zor sistemleri birbirine bağlayan esnek bir ara katman görevi görebiliyor. Nitekim B2B SaaS sektöründe de MCP sunucularının benimsenmesi hızlanıyor. Şirket içinde de API kullanım kalıplarına göre kısıtların ya da yapının nasıl ayarlanacağına dair tartışmalar artıyor. Protokol birçok açıdan “enterprise-ready” olmasa bile bunun çok da önemli olmadığını düşünüyorum; çünkü standartların tarihinde, cilalanmamış ve “dağınık” görünen spesifikasyonların pazar ihtiyacına uyduğu için sonunda benimsendiği çok örnek var
  • MCP’yi uzun süreli bağlantılar üzerinde çalışan bir RPC gibi anlıyorum ve genelde WebSocket tabanlı. Bana göre RPC daha kolay; birincisi, REST endpoint tasarımında tüm nesneyi POST ile mi değiştirelim, yoksa yalnızca bazı alanları PUT ile mi güncelleyelim gibi gereksiz tartışmaları azaltıyor. İkincisi, LLM’nin REST terminolojisini ya da semantiğini bilmesine gerek kalmıyor; sadece RPC metodunu görüp doğrudan çağırabiliyor. Sonuç olarak bunlar büyük avantajlar
  • Şirket açısından MCP’nin harika bir gelir modeli olduğuna da dikkat çekmek isterim. Her veri isteği ücretli bir LLM çalıştırmasıyla doğrudan bağlantılı. Öte yandan, MCP benimsenmesiyle gelecekteki sorguları daha ucuz hale getirecek şema pazarlığı gibi optimizasyonların hiç olmaması hayal kırıklığı yaratıyor
  • Zaten rest ve openapi var; bunlar self-discovery gibi özellikleri destekliyor. MCP sunacak şirketlerin de sonuçta iyi API’ler sağlayacağına inanıyorum
  • Buna gerçekten katılıyorum: Büyük şirketlerde, sabah 9’dan akşam 5’e kadar güzel işlere odaklanıp mesaiden sonra şirketi hiç düşünmeyen çok sayıda mühendis var. O halde şirket açısından, çalışan verimliliğini yalnızca çalışma saatleri içinde azamiye çıkarma fırsatını değerlendirmek en mantıklı sonuç oluyor
• MCP sunucusuyla hamamböceği benzeri canlıları kontrol eden bir deneyin ne kadar yakında çıkacağını merak ediyorum. Gerçekten de geçmişte 10 yılı aşkın süredir robo-roach deneyleri, sibernetik hamamböcekleri gibi birçok örnek oldu
• Eskiden Unix geliştiricileri çok titiz spesifikasyonlar yazardı ama zaman değişti. Bu katılığın ve extensible olma yorgunluğunun, XML tabanlı mimarilerin başarısızlığındaki etkenlerden biri olduğunu düşünüyorum. O dönemde XSL, XHTML, XSD, WSDL, RDF, RSS gibi aşırı karmaşık bir mimari vardı ve sonuçta JSON gibi basit formatların popülerleşmesinin zemini buydu. Yine de son dönemde XML kullanımının yeniden arttığı bir eğilim de görüyorum. Özellikle Anthropic gibi LLM sistem prompt’larında XML ya da Markdown gibi yapısal metinlerin yoğun kullanıldığını hissediyorum. Ancak MCP modelinin hatalı olduğunu düşünüyorum; modele bilgiyi “çekmesini” söylemektense “itme”, yani bağlamı önceden sağlama yaklaşımı daha iyi
  • İlginç olan şu ki, yakın zamanda JSON tabanlı bir makro genişletme dili yaparken aslında XSLT ya da XPath’i yeniden icat ettiğimi fark ettim. Grafik/graph taramasında çok güçlü olan xpath spesifikasyonuna hayran kalmıştım. BaseX gibi araçlarla rastgele XML’i bir veritabanına alıp XPATH/XQUERY ile sorgulamak mümkün ve faydalı. Eğer LLM’nin saçmalamasını önleyecek sağlam bir veri arayüzü kuracaksam, XML şemasını sistem prompt’una koyup veri sorgularını üretmesini sağlamak en iyi çözüm olur diye düşünüyorum
  • “Bağlamı önceden iten modelin” pratikte ne tür sorunlara kadar karşılık verebileceğinden emin değilim. Kullanıcı bilgiyi zaten önceden biliyorsa sorunu doğrudan çözerdi; MCP talebinin çoğu da “15 farklı kaynağın nasıl bağlanacağını öğrenmeden sadece sorguyu hallet” türü ihtiyaçlardan geliyor
  • LLM’ler tag biçimindeki XML’i iyi işliyor ama gerçekte çoğu kişi düzgün bir XML bloğu (<?xml version="1.0" encoding="UTF-8"?> ile başlayan, namespace, şema vb. içeren yapı) kullanmıyor; daha çok SGML tarzı bir etiket yığını kullanıyor
  • Semantik web’in gerçekten başarısız olmasının nedeni, reklam yerleştirme ya da iş modeli entegrasyonu konusunda başarılı olamamasıydı; bence asıl gerçekçi sebep bu
  • “Bağlam itme” yaklaşımına eleştirel bakıyorum. LLM’nin context window kapasitesi çok sınırlı, dolayısıyla yalnızca gerekli bilgiyi en az miktarda aktarmak en iyi yaklaşım. Her model gerekli bağlamı kendisi seçip pull edebildiğinde bu sınırlamaların aşılma ihtimali daha yüksek
• MCP, yapay zekanın popülerliği sayesinde çeşitli platformların her amaç için programlanabilir hale geleceği umudunu veriyor gibi görünüyor; ama bence tersine, başarısız olmaya mahkûm. Çünkü semantik web’in başarısızlık nedeni de sürdürülebilir bir gelir modeli kuramamasıydı. Yapay zekanın web’in yerine geçip derinlemesine “araştırma” yapması fikri de aynı soruna sahip. Örneğin restoran menülerini metadata olarak yayımlayıp “Teksas’taki en ucuz tacoyu bul” gibi otomasyonlar mümkün olabilirdi; ama gerçekte karşımızda veri kilitleme ve bunu aşmaya çalışan AI crawler altyapısı arasında bir yarış var. Büyük resimde mevcut sistemin verimsiz olduğu sonucu çıkıyor
  • MCP de sonuçta evrimleşmiş bir robots.txt’den ibaret gibi. Özünde “kaynaklarımı iyi tarif edersen kullanırım” modeli. 90’larda Java tabanlı ajan sistemleri de ajanlar arasındaki bilgi asimetrisi yüzünden başarısız olmuştu; bu tasarım sınırını tamamen kaldırırsak, tüm sosyal ve ticari yapının işleyişi bile sekteye uğrayabilir endişesi var
  • Open API’lerin sorunu yalnızca para kazanma meselesi değil; pratikte sınırsız kaynak yatırmadan AI ajanlarının istek botu dalgası kaynakları tüketip sonunda iflasa yol açabiliyor. Uzun vadede RPC pay-per-call ücretlendirmesi daha istikrarlı bir alternatif olabilir. Model/ajan işletmecileri bir ödeme clearing house’u gibi davranır ve maliyeti abonelik ücretlerine yansıtır diye tahmin ediyorum
  • HATEOAS gibi REST mimarisinin idealize edilmiş yaklaşımları 2010’ların başında çok modaydı ama swagger yaml gibi otomasyon araçları dışında anlamlı bir genişleme yaşanmadı ve sönüp gitti. Hatta bence kullandığı terminoloji bile fazla zordu; bu da başarısızlığı davet etti
  • İnsanların okuduğu metni yapay bir bariyer olarak görme fikrine katılmıyorum. Asıl yapay bariyer, örneğin bir restorandan JSON üretme becerisi ya da yazılım benimsemesi beklemek. NLP araçları sayesinde mevcut veriyi olduğu gibi kullanmak mümkün hale geldi ve geliştirme maliyeti neredeyse sıfıra indi. Evet, dilsel belirsizlikler var ama bu zaten insan dilinin doğasında olduğu için çok büyük bir sorun saymıyorum
  • Semantik web’i eleştirirken bunu söylemek biraz hassas ama, gerçekten isteyen bir restoran sahibi bugün istediği anda metadata yayımlayabilir ve bu, alıcıyla satıcıyı daha kolay buluşturmaya yardımcı olabilir. Örneğin WordPress eklentilerinde schema.org/Restaurant, Menu, MenuItem, Offer gibi metadata desteği zaten var. Sonuçta en büyük engel belki de Cloudflare gibi geçit bekçileri; pratikte Python otomasyon fikirlerini engelleyen gerçek unsur da bu olabilir
• LLM’ler API dokümantasyonunu okuyup otomatik uyum sağlayabildiği için, standart API spesifikasyonlarına uyum artık eskisi kadar zorunlu olmayabilir. MCP spesifikasyonunun benimsenmesinden bağımsız olarak, her sitenin “API sunmasının” beklenmesi bile başlı başına büyük bir değişim
  • Gerçek ortamda API dokümantasyonu zayıf olabilir; bu durumda LLM hatalı kod ya da yanlış çağrılar üretebilir. Kullanıcı bunları düzeltip tekrar LLM’ye verdiğinde, sonuçta bir ara katman —MCP tarzı bir sunucu— oluşturmuş olursunuz. LLM’ye API’ye doğrudan erişim yetkisi verdiğinizde güvenlik ve kaynak yönetimi açısından da riskler ortaya çıkar; örneğin aşırı çağrılar büyük maliyetlere yol açabilir. Başka birçok pain point daha var ve bunların bir kısmı ortada MCP benzeri bir arayüz olduğunda gerçekten çözülebiliyor. Bunun ille de MCP olması şart mı, ayrı konu; ama bugün için fazlasıyla pratik bir çözüm
• MCP ile ilgili beni en çok endişelendiren şey, protokol seviyesindeki eksikliklerden ziyade, Anthropic ve OpenAI gibi şirketlerdeki belirli ekiplerin iyileştirme/düzeltme yetkisini tek elde toplaması. Bunun gerçek geliştirici ve operatör topluluklarından ziyade, sadece beyin fırtınası aşamasında kalan bir spesifikasyon olabileceği yönünde de bir tedirginlik var. Sanki Visa-Mastercard düopolünün gölgesi hissediliyor
  • Microsoft da steering committee’ye katıldı örneği var
• “Semantik web” aslında yalnızca bir sözdizimi yapısıydı; MCP’nin ise gerçekten somut bir uygulanabilirlik taşıyor olabileceğine dair bir beklenti var
• “Eski usul Unix geliştiricileri aşırı titizdi” algısı var ama ironik biçimde Unix aslında “hızlı dene ve kır” kültürünün de öncüsüydü. Kuşaklar değişse de öz aynı kalıyor diye düşünüyorum
• MCP’nin, Google arama motoru optimizasyonu (SEO) gibi, yapay zekaya yönelik reklam ve spam yayılımı için kötüye kullanılabileceğine dair gerçekçi bir endişe var
• MCP sayesinde herkesin her türlü veriye kolayca erişeceği yanılgısına kapılmamak gerektiğini düşünüyorum. Gerçekte katman katman ödeme doğrulaması, izinli white list IP’ler gibi güvenlik mekanizmalarına takılıp, son kullanıcıya sadece “ERR 402” dönmesi daha olası ve daha tanıdık bir senaryo