Web 2.0 2.0'ın Gelişi: MCP
(anildash.com)- Model Context Protocol (MCP), Anthropic’in LLM’leri harici uygulama ve sistemlere bağlamak için oluşturduğu bir spesifikasyondur; OpenAI’ın ChatGPT’de desteklemesinin ardından birçok platformda ortak bir arayüz gibi yaygınlaştı
- Spesifikasyon gevşek ve eksik olsa bile, çok sayıda katılımcı aynı yaklaşımı hızla benimserse gerçek web’de açık protokoller güç kazanabilir
- Web 2.0’ın asıl değeri, kapalı sosyal sitelerden çok açık API’ler ve birlikte çalışabilir araçların oluşturduğu geliştirici ve kullanıcı ekosistemine daha yakındı
- Facebook ve Twitter gibi büyük platformların API’lerini kapatmasıyla zayıflayan birlikte çalışabilirlik beklentisini MCP, yapay zeka kodlama araçları akışı içinde yeniden programlanabilir platformlar olarak canlandırma potansiyeline sahip
- MCP her derde deva değil; veri işleme konusundaki belirsizlikler ve güvenlik riskleri de büyük. Ancak standartlara uyum ve şeffaflık talep etmek için yeni bir fırsat olabilir
MCP’nin standart gibi yayılmasının arka planı
- Model Context Protocol, yani MCP, Anthropic’in Claude için tasarladığı bir spesifikasyondur
- LLM’lerin çeşitli uygulamalardan bilgi istemesini veya başka sistemlerle etkileşime geçmesini sağlamayı amaçlar
- OpenAI’ın birkaç ay önce ChatGPT’de aynı protokolü desteklemesiyle MCP, birçok yerde benimsenen bir standart gibi konumlandı
- MCP’nin Windows’a da dahil edilmesi, yayılım alanını gösteriyor
- Önemli nokta, spesifikasyonun ne kadar tamamlanmış olduğundan çok, birden fazla oyuncunun aynı arayüzü hızla benimsemiş olmasıdır
- MCP daha çok gevşek bir spesifikasyona yakındır; ancak açık olması ve çalışması bakımından web’in başarı biçimine benzer
Web 2.0’ın aslında işaret ettiği şey
- Web 2.0, Facebook gibi kapalı ve tescilli siteler anlamına gelen bir ifade değildir
- Erken dönem Web 2.0 topluluğunun merkezinde, birçok sitenin açık API’ler sunması ve geliştiriciler ile kullanıcıların insanları ve verileri birbirine bağlayabilmesini sağlayan bir akım vardı
- Flickr, Del.icio.us ve Upcoming; etiketler ve sosyal paylaşım gibi özelliklerin öncülüğünü yapan dönemin önde gelen siteleriydi
- LiveJournal ve Movable Type gibi platformlar da API’ler ve protokoller etrafındaki açık standart çalışmalarını etkiledi
- O dönemin ortak değerleri görece açıktı
- Araçları, teknolojileri ve platformları açık veri ve açık protokoller üzerine inşa etmek
- Kullanıcının kontrol sahibi olması
- Geliştiricilerin tutarlı ve birlikte çalışabilir araçlarla sistemlerle etkileşime girmesi
Kapalı platformların kopardığı birlikte çalışabilirlik
- Bir nesil boyunca geliştiricilerin uygulamalar ile platformlar arasında birlikte çalışabilirliği olağan bir beklenti olarak görmesi zorlaştı
- Büyük VC’lerin ve teknoloji sektörü liderlerinin açıklık çağını sona erdirdiği yönündeki eleştiriler de buna eşlik etti
- Sosyal ağ etkinliklerini analiz eden araçlar, büyük sosyal ağ platformlarının API’lerini kapatmasıyla ürünlerin ve kullanıcı tabanlı hizmetlerin durdurulduğu örnekler yaşadı
- Facebook ve Twitter gibi platformlar, birçok insan için Web 2.0’ın açık veri ve birlikte çalışabilir teknoloji beklentisini yıktı
- Sonuç olarak kullanıcıların kendi ağlarını istedikleri şekilde yönetemediği bir durum günlük hayatın parçası haline geldi
- Twitter zaman akışında gömülü Instagram fotoğraflarını görememek
- fediverse veya Bluesky’de mümkün olan takipçi içe/dışa aktarma gibi özellikleri kullanmakta zorlanmak
- Kendi ağını istediği uygulamayla kontrol etmekte zorlanmak
MCP’nin yeniden açabileceği olanak
- MCP’nin yükselişi, yapay zekanın kodlayıcılar arasında popülerlik kazanmasıyla örtüşerek platformların yalnızca LLM’lere değil, çeşitli programlama amaçlarına da açılabileceği beklentisini yaratıyor
- Kilit nokta, Anthropic’in oluşturduğu spesifikasyonun diğer platformlar tarafından aynen benimsenmesidir
- Başka bir şirketin protokolünü sadık biçimde ikinci olarak benimsemek, tüm ekosistemin aynı şekilde daha kolay çalışmasını sağlayabilir
- Buna karşılık bir protokolü kopyalayıp genişlettikten sonra sonunda ortadan kaldırmak ekosisteme zarar verebilir
- Aynı arayüzü kullanmaya yönelik iyi niyetli bir benimseme olduğunda, çeşitli araç ve platformların birlikte çalışması için alan genişler
Standardı aynen izlemenin zorluğu
- Bir standardı aynen desteklemek göründüğünden daha zordur
- Yapay zeka platformları için semantik önbellekleme ürünü çıkarırken bile geliştiricileri normal ChatGPT API’sini aynen kullanmaya ikna etmek kolay değildi
- Geliştiriciler “bunu daha iyi yapabilirim” diye düşünmeye yatkındır; ancak standarttan sapıldığı anda sonuç tam tersine daha kötü hale gelebilir
- Tutarsızlıkları çok olan kötü bir spesifikasyonda bile bazen herkesin aynı şekilde uygulaması daha önemlidir
- HTML de pek çok şeyi eksik bırakan kusurlu bir spesifikasyondu, ancak web onun üzerine kuruldu
- İnternetin bütünü de çeşitli kusurlu spesifikasyonların üzerinde duruyor
Standartlara uyum ve şeffaflık talebi
- Yeni nesil geliştiriciler, sevdikleri araç ve platformların aynı protokol ve biçimleri kullandığında ortaya çıkan yaratıcılığı ve olanakları deneyimliyor
- RSS, podcasting, OpenID, OAuth, OpenSocial gibi akımların bir kısmı daha sonra fediverse ve ActivityPub gibi sonuçlara uzandı
- Geliştiriciler, kodlayıcılar, teknoloji meraklıları ve sıradan kullanıcılar da platformlarda deneyimlerini kodla kontrol edebilecek erişim hakkı talep edebilir
- MCP gibi açık standartlarla erişim sağlanırken, platformların gerçekte ne yaptığına dair şeffaflık da birlikte talep edilmelidir
- MCP esnektir, ancak birçok riski geride bırakır
- Platformların kullanıcı verilerini nasıl işlediği belirsizdir
- MCP üzerinden etkileşimlerde hangi eylemlerin gerçekleşeceğini bilmek zordur
- Güvenlik riski çok büyüktür
- Protokol bu endişeleri yeterince ele almaz
Web 2.0 tarzı açıklığın sınırları ve beklentisi
- MCP, geliştirici ekosistemindeki tüm sorunları çözen evrensel bir çözüm değildir
- Yapay zeka etrafındaki abartıyı ve tartışmaların çarpıtılmasını da düzeltmez
- Ancak önceki neslin Web 2.0 dönemini deneyimlememiş genç geliştiricilerin, MCP sayesinde web’i özgün mimarisine daha yakın bir hale döndürmeye çalışması mümkündür
- Web, tescilli olması ya da birkaç büyük şirketteki az sayıda kişi tarafından kontrol edilen bir yapıya dönüşmesi için tasarlanmamıştı
- Web’in, herkesin alelacele benimsediği kaba spesifikasyonlar aracılığıyla programlanabilir olması gerekiyordu; bu hack’lenebilir keyif, web’e sürüm numarası verilmeden önce de vardı
1 yorum
Hacker News yorumları
MCP konusunda birçok kişinin kaçırdığı nokta, bunun kurumsal yazılıma çok iyi uyması
LLM’ler genel amaçlı çevirmenler olduğundan, arada bir miktar gevşek bir katman olmadan bağlanması son derece zor olan kopuk sistemleri birbirine yapıştırmak için uygun bir tutkal işlevi görüyor
Bu yüzden B2B SaaS sektörü MCP sunucuları çıkarıyor; içeride de değişen kullanım kalıplarına göre API’leri ve sınırlarını nasıl yeniden tasarlayacaklarını tartışıyorlar
Protokol, birçok tanıma göre “kurumsala hazır” değil ama yazarın dediği gibi bu çok da önemli değil. Standartların tarihine bakınca, dağınık ve “kötü” şeyler de doğru zamanda doğru insanlara denk gelirse yaygın şekilde benimsenebiliyor
Kullanıcı nesnesinin bir alanını değiştirmenin, aslında kullanıcı nesnesini değiştiren bir PUT mu yoksa POST mu olduğu gibi tartışmalar azalıyor. REST fiilleri üzerine epey zaman harcamışlığım var
LLM’in de API’nin REST semantiğini anlaması gerekmiyor. Kullanılabilir RPC metotlarına bakıp işe yarayacak gibi görünen çağrıyı yapması yeterli. Bence işin özü gerçekten bu kadar
Uç noktaların birbirleriyle ileride ucuzca sorgulanabilecek bir şema pazarlığı yaptığı bir model de değil
Sadece bunlarla bile kendi kendini keşfetme gibi özellikler mümkün
MCP sunacak bir yer zaten muhtemelen düzgün bir API de sunacaktır
Hangi şirket mesai saatleri boyunca çalışanlarından mümkün olan en yüksek verimi almak istemez ki
“Eskiden şartnameleri huysuz yaşlı Unix amcalarının yazdığı dönemle karşılaştırınca” kısmı, bence semantik webin başarısız olmasının çeşitli nedenlerinden biri. Bu, yazarın “kötü olan daha iyidir” ana fikriyle de çelişmiyor
İnsanlar XML’deki eXtensible kısmına fazla kapıldı ve bence bir noktada yorgunluk birikti. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS derken fazlası oldu
O dönemde dünyanın ihtiyacı olan şey basit bir değişim formatıydı; JSON bu ihtiyaca uydu, XML tarafı ise veri formatı konusunda mimari astronotluğa yakındı
Ama artık XML’in zamanının geldiğine de inanıyorum. Anthropic gibi yerlerin sızan sistem promptlarında XML sıkça görülüyor. LLM’ler yapılandırılmış metin formatlarını, özellikle Markdown ve XML’i oldukça iyi idare ediyor gibi
Yine de MCP’nin yanlış model olduğunu düşünüyorum. Modelin bağlamı doğrudan “çekmesini” istemek yerine, bağlamı modele bizim “itmemiz” gerektiğini düşünüyorum
Dört makro etiketi (
#=,#&,#?,#!) sırasıyla atama, ikame,condbenzeri koşullu dallanma ve kullanıcı tanımlı fonksiyon çağrısıyla kendini makro genişletme sonucuyla değiştiriyordu; sonunda XSLT’yi yeniden yaptığımı fark ettimAsıl istediğim şey XPath’ti. Bir grafiği çeşitli eksenler boyunca ileri geri dolaşma yolunu tarif etme biçimi; gerçekten mükemmel bir şartname
Sonra rastgele XML belgelerini sorgulanabilir bir veritabanına alıp XPath veya XQuery ile sorgulamayı sağlayan BaseX’i https://basex.org/ buldum
Halüsinasyonsuz, güvenilir bir doğal dil veri kümesi arayüzü oluşturmak için en iyi yol, XML şemasını sistem promptuna verip modelin veriyi getiren sorguyu yazmasını sağlamak gibi görünüyor
Bilgiyi önceden biliyor olsaydınız muhtemelen sorunu kendiniz çözerdiniz
MCP’den alınan değer daha çok “15 kaynağı birbirine bağlamayı öğrenme; benim yerime hangi sorguları çalıştıracağını bul” gibi görünüyor
Hiç kimse™ LLM’e XML bildirimiyle başlayan düzgün XML vermiyor; namespace, XSLT, XML Schema gibi şeyler de kullanılmıyor
Daha çok SGML tarzı etiketlerin keyfi bir koleksiyonu gibi
XML, açılı parantezlerden ibaret olmayan büyük bir şartname; tüm durumları kapsayıp güvenlik ve karakter kodlamasını doğru ele almaya çalışıyor
Bu yüzden “düz metin düzenleme” pek sezgisel değil. Bu paragraf gibi bir şey yazarsanız uyumluluk modunda parse edilebilir ama geçerli olmayabilir
Değişim formatı ya da buna uygun tasarlanmış uygulamalara yüklenen bir format olarak daha fazla potansiyeli var; LLM’lerin de bunu anlamakta kesinlikle zorlanmayacak olması iyi
Geçmişteki pek çok sorun, zamanı az olan ve özellikleri hızlıca sıkıştırmak isteyen programcıların güçlü biçimde yapılandırılmış şartnameleri kaba bir sopa gibi kullanmasından kaynaklandı. “XML mi? Regex’le yazarız.” Bunu üç farklı program ve üç farklı yazar tekrarlayınca ortalık karışıyor
Kişisel olarak istediğim şeye gerçekten yakın olan format BBCode’du. Pek çok şeyin kaynak formatı olarak harika. Temelde hâlâ açılı parantez ailesinden ama genel amaçlı frontend sözdizimi olarak kullanılacak kadar yapı ve esnekliğe sahip
İlk uygulamalar “regex’le yazarız” şeklindeydi ama onlarca yıllık pratik sınamadan sonra bugün daha zarif parser’lar da var
“MCP’nin yükselişi, yapay zeka kodlayıcılar arasında popülerlik kazandıkça, LLM’lerin yalnızca kontrol etmesi için değil, herhangi bir amaçla programlanabilir olmaları için başka platformları da açabileceği umudunu veriyor” cümlesinin tersini düşünüyorum.
MCP, semantik webin başarısız olduğu aynı nedenle başarısız olmaya mahkûm. Çünkü bir şey kilitli değilse kimse para kazanamaz.
Yapay zekanın bizim yerimize web’de arama yapması, pardon “deep-research” denen özelliğin ne kadarının daha iyi bir yolla çözülebileceğini merak ediyorum.
Restoranlar menülerini metadata formatında yayımlayabilir ve herkes bir Python script’iyle Teksas’taki en ucuz taco’yu bulabilirdi; ama gerçeklikte bir elle veriyi yapay bariyerlerin arkasına kilitliyor, diğer elle de bunu aşmak için veri merkezleri dâhil yapay zeka inşa ediyoruz. Makro ölçekte bakınca düpedüz aptalca.
Önceki ajan dalgasının ölmesinin nedeni, sonunda herkesin pazarlığa konu olan makineler üzerinde çalışan kendi kodlarına güvenemeyeceğini fark etmesiydi. 90’lardaki Java tarafıydı bu.
Temelde, etkileşime giren ajanlar arasında kasıtlı olarak tasarlanmış bir bilgi asimetrisi sorunu var. Bunu ortadan kaldırırsanız toplumun büyük bir kısmı çalışmayı durdurur.
Soruna ne kadar çok kaynak atarsanız atın, birileri çok küçük bir kazanç uğruna o kaynakları tüketmenin yolunu bulacaktır.
MCP, yapay zeka ajanları açık MCP sunucularına çekirge sürüsü gibi üşüştükçe sorunu yalnızca daha da kötüleştirir.
İstikrarlı seçenek, çağrı başına ücretlendirilen RPC fiyatlandırması gibi görünüyor. En azından modeli ya da ajanı işleten taraf ödeme takas merkezi rolünü üstleneceğinden, Web 2.0 API dönemine göre daha olası.
Muhtemelen en makul ücretlendirme yöntemi bu maliyetleri abonelik paketlerine dâhil etmek olur. Teşvikleri hizalamanın en iyi yolu bu gibi görünüyor.
Zaten HATEOAS adını koyan kişi başarısız olması için zemini hazırlamış sayılır.
Veriyi standart formatta yayımlamanın “kolay” bir değeri olsaydı, birlikte çalışabilir endpoint’ler çok daha yaygın benimsenirdi.
Örneğin schema.org ya da genel ortak ontolojiler kullanmak gibi. Ama gerçeklikte her seferinde özel bir sihirli SDK gerektiren kişiye özel formatlar çok.
Restoranlardan menülerini metadata formatında yayımlamalarını istemek yapay bariyerdir.
Yeni doğal dil işleme araçlarının güzelliği burada. Restoran sahibinin JSON öğrenmesi ya da JSON üreten bir yazılım paketi satın alması gerekmiyor.
Veriyi olduğu gibi kullanabiliriz. Yararlı araçlar üretmenin maliyeti neredeyse 0’a yaklaşıyor.
Hatalı olacaktır; ama insan dili zaten böyledir.
MCP var diye her şeye erişebileceğini düşünenlere acıyorum.
Bunlar onlarca katmanlık ödeme doğrulama ve kimlik doğrulama katmanlarının arkasına saklanacak. Elbette izin verilen IP listesi de eklenecek ve tabii ki IPv4 olacak.
Size görünecek tek şey muhtemelen
ERR 402;olacak.MCP’de en çok endişe ettiğim şey protokolün berbat tasarlanmış olmasından ziyade, bunu düzeltme ve iyileştirme işinin yalnızca Anthropic ve OpenAI iç ekiplerine bağlı olması.
Protokolü yapanlar, onu gerçekten uygulamayı da deneyen mühendisler gibi görünmüyor.
Belirsiz biçimde Visa-Mastercard oligopolünü andırıyor.
https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
Artık LLM’ler API dokümantasyonunu okuyup uyum sağlayabiliyorsa, standart API izlemek eskisine göre daha az gerekli hâle gelmiş olabilir mi?
Benim için önemli avantaj, sitenin MCP spesifikasyonuna uyup uymamasından bağımsız olarak bir API’ye “sahip olduğu” beklentisinin oluşması.
Dokümantasyon iyi olsa bile LLM, API ile etkileşen hatalı kod üretebilir. Üretilen kodu düzeltip LLM’in bu kodu çağırarak API ile etkileşmesini sağlıyorsanız, zaten bir ara katmana giden yola girmişsiniz demektir. Fiilen “MCP benzeri” bir sunucu yapıyorsunuz.
LLM’e API’ye doğrudan erişim verirken güvenlik veya kaynak tahsisi sorunları da var. LLM’in API’nin en son ne zaman çağrıldığına dair bilgisi sınırlıdır. Çok sık çağırabilir; çağrı başına maliyet pahalıysa beklenmedik altyapı faturaları doğar.
Bunun dışında da araya bir şey koyunca çözülen pek çok potansiyel acı noktası var.
O “şey”in MCP olması gerekip gerekmediği konusunda makul insanlar farklı düşünebilir. Şimdilik insanların yapması gereken işleri halletmeye yetecek kadar iyi çalışıyor gibi.
Artık semantik webi kurabiliriz. Kuruluşların SQL
CREATE TABLEDDL’lerini MCP uygulamalarının okuyabileceği statik dosyalar olarak paylaşan küçük bir protokol yapması yeterli. MCP’nin isteğe bağlı bir uzantısı olarak yeter.Böylece yapay zeka/LLM function calling’i SQL’e bağlayan zaten mevcut araçları kullanarak veriyi anlayıp sorgulayabiliriz; semantik web de bu olur.
Bu yaklaşım, semantik web’in önünü hep kesen eksik halkayı tamamlıyor: Şirketlerin tescilli veri tipleri yerine standart “veri tipleri” kullanmasını sağlayacak teşvikin olmaması sorununu.
MCPQ, yani sorgu içeren MCP ortaya çıkarsa, kuruluşların veri yapısı katmanında işbirliği yapmak için birdenbire nedeni olur.
Meğerse “semantik web” başından beri sözdizim web’iymiş; belki de bu sefer gerçek olan budur.
Birinin hamamböceği gibi bir şeyi kontrol eden bir MCP sunucusu yapması ne kadar sürer merak ediyorum
Referanslar:
https://www.technologynetworks.com/informatics/news/robo-roa...
https://www.sciencealert.com/scientists-turned-cockroaches-i...
Ve 10 yıldan da öncesine uzanan başka birçok örnek de var
“Şartnamelerin huysuz yaşlı Unix amcaları tarafından yazıldığı dönem” ifadesi epey komik
Bu neslin “yaşlı Unix amcalarını” huysuz insanlar olarak hayal etmesi ilginç. Oysa Unix, MIT ekolüne karşı nihai hızlı hareket et ve bir şeyleri kır isyanıydı
Bazı şeyler hiç değişmiyor galiba :-)