Yapay zeka tarayıcı otomasyonu için "MCP-B Protokolü"

 (mcp-b.ai)
6 puan yazan GN⁺ 2025-07-11 | 2 yorum | WhatsApp'ta paylaş
  • MCP-B: tarayıcıya özgü yapay zeka otomasyon protokolü
  • Mevcut ekran yakalama ve tıklama yöntemleri yerine, web sitesinin API’sine doğrudan erişerek yapay zekanın 1.000 kat daha hızlı ve doğru otomasyon yapmasını destekleyen bir tarayıcı bağlam protokolü
  • Yalnızca yaklaşık 50 satır kod ekleyerek, ayrı OAuth, API anahtarı veya karmaşık ayarlar olmadan, site içindeki kimlik doğrulama bilgileriyle yapay zekayı hemen entegre etmek mümkün
  • Tarayıcı oturumu ve mevcut kimlik doğrulama sistemlerini kullanarak, yeni kimlik doğrulama ya da yetki ayarı olmadan anında çalışır ve her web uygulamasının API güvenlik politikasına aynen saygı gösterir
  • Eklenti aracılığıyla yapay zeka asistanı birden fazla sekme ve uygulama arasında dolaşarak doğrudan veri sorgulayıp işlem gerçekleştirebilir; mevcut otomasyona kıyasla performans (birkaç ms içinde yürütme) ve güvenilirlik ezici biçimde artar
  • Yapılandırılmış API erişimi kullandığı için UI değişiklikleri, ekran görüntüsü hataları ve karmaşık seçici yönetimi sorunlarından etkilenmez. Kurulum ve kullanım da son derece basittir

MCP-B’ye Genel Bakış

  • MCP-B (Machine Context Protocol for Browsers), tarayıcılar için bir model bağlam protokolüdür ve yapay zeka tabanlı terminal otomasyonuna benzer biçimde tarayıcı ortamını kontrol edip onunla etkileşim kurmak için bir standart sunar
  • Bu protokol, tarayıcı ile yapay zeka motoru arasındaki iletişimi açık biçimde tanımlayarak çeşitli otomasyonları ve model etkileşimlerini yapılandırır

Mevcut yöntemlerden farkı

  • Geleneksel tarayıcı otomasyonu: ekran görüntüsü analizi, öğe tıklama, UI değişikliklerine karşı kırılganlık; yavaş ve kararsızdır (iş başına 10~20 saniye, 4~5 dolar maliyet)
  • Mevcut MCP yöntemi: API anahtarı ve karmaşık kimlik doğrulama gerekir, ilk kurulum eşiği yüksektir
  • MCP-B: tarayıcı oturumunu kullanır, API’ye doğrudan erişir, karmaşık kimlik doğrulama ve ayarlar olmadan anında çalışır

Temel prensip ve yapı

  • Sekme başına MCP sunucusu: Her web uygulaması kendi TypeScript tabanlı MCP sunucusunu çalıştırır (bellek içi aktarım, mevcut cookie/JWT kimlik doğrulamasını yeniden kullanma)
  • MCP-B eklentisi: Chrome/Edge/Firefox eklentisi (content script, sekme sunucusuyla postMessage üzerinden iletişim kurar), tüm sekmelerin araçlarını ve API’lerini tek yerde birleştirir
  • Yapay zeka asistanı entegrasyonu: Native Bridge ve çeşitli istemcilerde (Claude Desktop, Cursor IDE vb.) MCP-B üzerinden tarayıcı otomasyonu mümkündür

Kullanım ve dağıtım şekli

  • Geliştiriciler: 1) paketi kurar 2) MCP sunucu kodunu ekler 3) dağıtımı tamamlar → ayrı API anahtarı, OAuth veya karmaşık ayarlar gerekmez
  • Kullanıcılar: Eklentiyi kurduktan sonra hemen kullanabilir; yalnızca yapay zeka ayarıyla otomasyon anında hazır olur

Pratik avantajlar

  • Kimlik doğrulama: Mevcut web sitesi giriş ve oturum bilgilerini aynen kullanır; OAuth 2.1/ayrı kimlik doğrulama gerekmez
  • Performans: Doğrudan API çağrılarıyla işlemler ms düzeyinde tamamlanır (mevcut yöntemlere kıyasla 10.000 kat iyileşme)
  • Güvenlik: Uygulamanın içinde çalışır; mevcut erişim kontrolü ve yetki politikalarına aynen uyar
  • Ölçeklenebilirlik: Birden fazla web uygulaması, sekme ve yapay zeka aracı MCP-B üzerinden entegre şekilde yönetilebilir
  • Ayarlar: Yaklaşık 50 satır kodla otomasyon kullanıma hazır hale gelir

Karşılaştırma özeti

Yöntem Kimlik doğrulama ve ayarlar Çalışma biçimi Performans ve güvenilirlik
Mevcut otomasyon Karmaşık kimlik doğrulama, API anahtarı Ekran kazıma, tıklama Yavaş ve kararsız (10~20 saniye)
Mevcut MCP API anahtarı, OAuth gerekir API erişimi Giriş eşiği yüksek
MCP-B Ayar yok, tarayıcı oturumu kullanılır Doğrudan API çağrısı ms düzeyi, çok hızlı/kararlı

Sonuç: yeni nesil tarayıcı tabanlı yapay zeka otomasyonu

  • MCP-B, tarayıcı ortamına optimize edilmiş bir yapay zeka otomasyon protokolü olarak kimlik doğrulama, güvenlik, ölçeklenebilirlik ve performans açısından yenilikçi
  • Ek kimlik doğrulama veya karmaşık ayarlar olmadan, yalnızca tarayıcı tabanlı doğrudan API çağrılarıyla büyük ölçekli yapay zeka otomasyonu uygulanabilir
  • MIT lisansı, topluluk odaklı yapı, tüm büyük tarayıcı desteği

İlgili okumalar

2 yorum

 
shindalsoo 2025-07-12

MCP-B teknolojisinin temel vizyonunun şu olduğu söylenebilir.
"Güvenilir bir aracı olan Chrome uzantısı (Extension) üzerinden, tarayıcının zaten güvenli şekilde yönettiği kullanıcı bilgilerini (çerezler, oturum, kimlik doğrulama vb.) kullanarak,
web sayfasında geliştiricinin önceden tanımladığı 'araçları (Tools)' AI sohbet penceresinden doğal dil komutlarıyla çağırıp kontrol etmek."

Ancak ben bunun "ölçeklenme ihtimali pek yokmuş gibi göründüğünü" düşünüyorum ve nedenleri de şöyle.

  1. Kullanıcı direnci: En büyük eşik bu. Kullanıcılar, kendi tarayıcı bilgilerine erişen bir uzantıyı kurma konusunda içgüdüsel bir direnç ve güvenlik kaygısı taşıyor. Bu teknolojinin sunduğu kolaylık, bu kaygıları aşacak kadar ezici değilse, kullanıcılar kurulumu erteleyecektir.
  2. Web geliştiricisinin yükü: Web sitesi geliştiricileri, mevcut API'leri oluşturmanın yanı sıra MCP-B için 'araçları (Tools)' ayrıca tanımlayıp yönetmek gibi ek bir yük üstlenmek zorunda kalacak. Bu teknoloji yaygın biçimde benimsendiğinde elde edilecek fayda büyük değilse, geliştiriciler durduk yere bu çifte çabayı harcamak istemeyecektir.
  3. Güvenlik sorunlarında sorumluluğun kime ait olduğu: Bu teknoloji üzerinden bir güvenlik olayı yaşanırsa sorumluluğun web sitesi geliştiricisinde mi, uzantı geliştiricisinde mi, yoksa AI model sağlayıcısında mı olduğu belirsizleşebilir. Bu tür bir karmaşıklık, şirketlerin teknolojiyi benimsemekten kaçınmasına yol açar.
  4. Merkezi bir platformun yokluğu: Şu anda "hangi web sitesinin hangi araçları sunduğunu" gösteren standartlaştırılmış bir dizin ya da platform yok. Kullanıcıların, bir web sitesini ziyaret etmeden önce hangi AI işlevlerini kullanabileceklerini bilmesi zor.

Sonuç olarak,
MCP-B fikrinin kendisi teknik olarak son derece ilgi çekici ve yenilikçi olsa da, hem kullanıcılar hem de geliştiriciler için "neden özellikle bu yöntemi kullanmak gerekiyor?" sorusuna net bir yanıt veremeyecek gibi görünüyor. Mevcut API yaklaşımına kıyasla sağladığı avantajlar belirsizken, güvenlik kaygısı ve geliştirme karmaşıklığı gibi dezavantajları açıkça ortada.

Bu nedenle, şimdilik bu teknoloji bazı meraklılar ya da belirli amaçlara sahip geliştiriciler arasında deneysel olarak kullanılabilir; ancak web ekosisteminin geneline yayılması için aşılması gereken çok sayıda zorluk var gibi görünüyor.
 
GN⁺ 2025-07-11
Hacker News görüşleri

  • Beklenti: RSS ile benzer bir yol izleyecek. Şirketler, kullanıcıların verilerinin nasıl kullanılacağını kendilerinin kontrol etmesinden hoşlanmama eğiliminde

    • REST API’ler için de aynı şey geçerli; bir dönem API-first tasarım rüzgarıyla birlikte hizmet otomasyonu ve entegrasyonunun geleceği olmaları bekleniyordu. Ancak işletmeler, bu tür yetenekleri sunmanın kendi gelir yapılarını tehdit ettiğini hızla fark etti ve yön hemen değişti. Sonunda paranın, kullanıcıların bu tür yetkilere sahip olmasını engellemekte yattığını yeniden hatırladılar

    • RSS’nin başarısız olduğunu değil, aksine muazzam bir başarı elde ettiğini düşünüyorum. Google Reader ortadan kalktıktan sonra başka bir okuyucuya geçsem de RSS feed’leri 20 yılı aşkın süredir sorunsuz çalışıyor. RSS’yi desteklemeyen sitelerle neredeyse hiç karşılaşmadım

    • Web sitelerinin çoğu hâlâ RSS’yi destekliyor ve bazıları bunu sayfada göstermese bile varsayılan olarak bir feed mevcut. Bazıları tam metni vermese bile güncelleme bildirimi ya da otomasyon tetikleyicisi olarak hâlâ çok değerli. RSS hâlâ çok kullanışlı biçimde hayatta; adeta mikrodalga fırın gibi, varlığı doğal kabul ediliyor

    • Pazar yapısında bir değişim oldu ve artık büyük şirketler içeriğin kendisinden çok “intelligence layer”a odaklanıyor. İçerik giderek metalaşıyor. Google’ın reklam satmaya devam edebilmesi için kullanıcıların gözlerini, dikkatini ve onları etkileyen akıllı teknolojiyi elinde tutması gerekiyor. Google’ın RSS istememesinin nedeni, RSS’nin Google Search’ü baypas edebilmesiydi

    • Yapay zeka yakında insanlar gibi tıklayıp kaydırma yapabildiğinde, bir kez daha sonsuz rekabet başlayacak

  • Github projesinin katkı geçmişi çok ilginç (doğrudan bağlantı verilmiş). MiguelsPizza 3 kez, Claude 2 kez commit atmış ama Claude’un kod değişikliği miktarı neredeyse ezici düzeyde

    • Eklenti geçici olarak gizliye alınırken git geçmişi düzenlendiği için gerçek kayıtlarla biraz fark var. Yine de toplam kodun yaklaşık %85’ini Claude’un yazdığı doğru

    • Gelecekte bu tür bir örüntü (devasa AI tabanlı kod katkısı) giderek daha sık görülecek gibi duruyor

    • Claude’un commit grafiği oldukça sıra dışı. Claude Code doğrudan commit atıyormuş gibi görünüyor ama gerçekte neredeyse hiç yok. claude profili de incelenebilir

    • Gerçek commit listesine bakıldığında hepsi MiguelsPizza / Alex Nahas adıyla görünüyor (bağlantı). Bir tuhaflık var gibi

  • Blogdan alıntılanan bir bölüme değinilerek MCP’nin kimlik doğrulama sorunları tartışılıyor. OAuth2.1 uzun vadede de makul görünüyor, ancak kullanıcı adına hareket eden ajanlara uygun kimlik doğrulamayı yeniden icat etmek zorunda olunan bir durum var. Çok kiracılı uygulamalarda veri sızıntısı riski hâlâ çözülmüş değil

    • Modelin etki alanını ve erişebildiği verileri sınırlamak, MCP’nin büyük avantajlarından biri olabilir. Çok kiracılı uygulamaların istemci tarafı API’lerinin zaten kullanıcı kapsamıyla sınırlandırılmış olması beklenir; modele yalnızca bunu verirseniz zarar büyük olmayacaktır. Amazon’un iç kimlik doğrulama sistemi ile OAuth2.1 arasındaki uyumluluk sorunu da anılıyor (Amazon’da kimlik doğrulama farklı)

    • OAuth2.1’in bazı işlevlerinin RFC 8693’teki delegation vs impersonation kapsamında zaten ele alınıp alınmadığı merak ediliyor

    • Modelin erişebileceği kapsam sonuçta kullanıcıyla aynı olacağından, güvenli uygulamanın sorumluluğu nihayetinde web sitesi yöneticisine ait

    • Amazon örneğinde OAuth’un düzgün uygulanmamış olması asıl mesele değil gibi görünüyor. Kullanıcı yetki kapsamını aşan arka kapı benzeri erişim çok tehlikeli. MCP uygulamasının tüm eylemleri kullanıcı erişimiyle aynı kategoride kaydedilirse ciddi uyumluluk sorunları doğabilir. Bu açıdan çok ilginç ama güvenlik bakımından bir kestirme yol olarak sorun çıkarma potansiyeli yüksek görünüyor

  • Swagger(OpenAPI) spesifikasyonu yayımlanıp yalnızca genel amaçlı bir swagger mcp istemcisi olsa, tüm bu uygulamaların büyük kısmı neredeyse ikame edilemez mi fikri ortaya atılıyor. Kullanıcının kimlik doğrulama oturumunu kendisinin manuel açması yeterli olabilir. Claude’un prompt/ayarlar içinden API anahtarını iyi kavrayıp swagger tabanlı API istemcisi kullansa aynı şey olmaz mı deniyor

    • MCP ilk ortaya çıktığında herkesin aklına gelen ilk yaklaşım buydu. Ancak pratikte araç sayısı fazla olduğundan bunun iyi çalışmadığı görüldü. Yine de bu alanda ilginç denemeler sürüyor

    • API anahtarını prompt içine koymamak gerektiği yönünde bir uyarı da var

    • Claude Code’a CLAUDE.md içinde sadece swagger.json bağlantısı vermek bile API testlerini gerçekten çok kolaylaştırıyor

    • Bunu doğrudan denemeleri için teşvik ediliyor

  • Hedef kullanıcının kim olduğu pek anlaşılmıyor. Frontend testlerinde UI büyük ölçüde değiştiğinde testlerin bozulması zaten faydalı bir şey. Bunun dışındaki otomasyon amaçları içinse gerçek bir API sunmanın daha iyi olduğu düşünülüyor

    • Gerçek kullanıcılar olarak crawler’lar ve kişinin VLM ile süt satın alma işi örnek veriliyor

  • “Home Depot’ta masa yapmaya çalışırsan daha da zor olur” benzetmesine, Home Depot’ta da bolca kereste olduğu söylenerek itiraz ediliyor

    • Home Depot’ta zaten hazır masalar da satılıyor

    • Home Depot’ta daha iyi hassas aletler ve hatta uzmanlar bulunduğundan iş aslında daha kolay olabilir

    • “Keresteyi senin hayal edip yaratman gerekiyor” anlamında şaka yapılıyor

    • Bu işaret üzerine ifadeyi düzelttiğini belirtiyor

  • MCP’yi doğrudan kullanmamış olsa da, engelli biri olarak MCP’nin tarayıcı ve akıllı telefon otomasyonunda erişilebilirlik açısından büyük kullanım alanları sunduğu düşünülüyor. Ancak bu tür teknolojilerin kötü niyetli kişilerce suistimal edilebilmesi nedeniyle büyük web/app’lerde gerçekten benimsenip benimsenmeyeceği sorgulanıyor. Erişilebilirliği iyileştirmek için fiilen kullanıldığı örnekler olup olmadığı merak ediliyor

    • Erişilebilirlik araçlarının nasıl kötüye kullanılabileceğinin daha somut açıklanması isteniyor

  • MCP-B’nin açık kaynak olarak yayımlanmış olmasına teşekkür ediliyor. Çoğu şey tarayıcı üzerinde gerçekleşiyor ama MCP’de ön kabul, işi bir AI istemcisinin yaptığı yönünde biraz farklı. Temelde MCP-B’nin bir web uygulamasının JS API’sini doğrudan LLM sunucusuna bağlayıp kullanmaktan farkının ne olduğu soruluyor. Sonuçta aynı şey mi, yoksa daha büyük bir resim mi var diye soruluyor

    • Verilen yanıtta temel farkın şu olduğu açıklanıyor: MCP-B sayesinde web sitesi sahibi, ayrı bir AI sohbet özelliğini doğrudan uygulayıp yönetmek zorunda kalmadan, kullanıcının istediği modeli sitenin çeşitli araçlarıyla standart bir protokol üzerinden entegre etmesine olanak tanıyabiliyor

  • Sadece ana sayfadaki açıklamaya bakınca pek anlaşılmadığı ve bunun Selenium’un tarayıcı sürümüne benzer hissettirdiği söylenerek soru soruluyor

    • Benzer ama tamamen aynı değil. Playwright veya Selenium, tarayıcı otomasyon framework’leri ve Playwright-MCP sunucusunda ajan otomasyon için Playwright’tan yararlanabiliyor. Buna karşılık MCP-B, web sitesinin içine bir MCP sunucusu yerleştiriyor ve tarayıcı eklentisi ya da JS enjeksiyonu ile MCP-B istemcisi çalıştırıyor. Playwright ekranı doğrudan parse ederken, MCP-B standartlaştırılmış bir function calling yaklaşımı kullanıyor. Blogdaki kod örneğine bakılması öneriliyor

  • Ücretsiz LLM kullanıcıları için MCP ile tarayıcı otomasyonu yaygınlaşırsa, ücretsiz modeller için bile captcha istenen bir dünyaya geçileceği öngörülüyor. Sorun şu ki captcha’lar LLM’lere karşı pek etkili değil; sonunda LLM’lerin otomasyon yapan LLM’lerin erişimini engellemek için birbiriyle savaştığı tuhaf bir robot savaşları çağı başlayabilir

    • Bu tür hikâyelerde son genelde robotların aslında aynı hedefe sahip olduklarını fark edip iş birliği yapmalarıyla bitiyor