Bak şimdi, Tarayıcı otomasyonu deyince çoğu kişinin aklına hemen aynı sahne geliyor: bir yanda ajan, diğer yanda tarayıcı… ortada da bolca gecikme. Açık konuşayım, bu işte asıl soru “yapabiliyor mu?” değil (bu beni çok şaşırttı). “Kaç saniyede yapıyor, kaç token yakıyor ve işi ne kadar temiz götürüyor?” Ben de son günlerde tam bu soruya takıldım.
Eh, Geçen hafta İstanbul’da bir ekip toplantısında, Safari tabanlı bir akışın neden bazen Chrome üzerinden dolandığını tartışırken içimden şu geçti: Hani her şeyi CLI’a sarınca daha iyi olacak sanıyoruz ya… işte bazen tam tersi oluyor. Bu yazıda MCP ile CLI yaklaşımını tarayıcı otomasyonu özelinde masaya yatırıyorum. Hem teknik hem pratik taraftan.
Ve işler burada ilginçleşiyor.
Açık konuşayım, Önce şunu netleştireyim: konu sadece bir “arayüz tercihi” değil. İşin içinde hız var, maliyet var, entegrasyon var, hatta biraz da mühendislik kibri var. Bir aracı başka bir araca sarmak kulağa zekice gelebilir —. Bazen güzel görünen paketleme, içerideki mekanizmayı hantallaştırıyor. Neyse, uzatmayalım. Gelin ayrıntıya girelim.
Mesele Ne? Aynı Tarayıcıya İki Farklı Kapı
Şunu fark ettim: Orijinal fikir gayet basit. Safari’yi Model Context Protocol yani MCP üzerinden doğrudan konuşturmak. Buna karşılık bir de aynı yetenekleri CLI biçimine çevirip shell’den çağırmak mümkün. Kağıt üstünde ikisi de bir düşüneyim… aynı işi yapıyor gibi duruyor — fakat biri tarayıcıya direkt konuşuyor, diğeri ise her seferinde yeni bir süreç açıp kapatıyor. Evet, her seferinde.
Ve işler burada ilginçleşiyor.
Hani, Ben bunu ilk kez kendi küçük test ortamımda fark ettim. 2024 sonbaharında Kadıköy’de kurduğumuz mini otomasyon projesinde benzer bir katman eklemiştik; ekip olarak “komut satırı daha evrensel olur, herkes anlar” demiştik ve bu kararı o an gayet mantıklı bulduk. Sonuç? Evrenseldi evet, ama hız tarafında hafif süründü (bizzat test ettim). O gün bugündür “evrensel” kelimesine biraz temkinli bakarım açıkçası.
Bir şey dikkatimi çekti: Buradaki temel ayrım şu: MCP doğrudan stdio üzerinden gidiyor. Araç tanımlarını sürekli yeniden şişirmiyor. CLI ise daha geleneksel bir yaklaşım ama her çağrıda süreç maliyeti getiriyor. Tek komutluk işler için bu belki çok can sıkıcı olmaz —. 5-10 adımlık ajan akışlarında o küçük gecikmeler üst üste binince tablo değişiyor. Ciddi fark var.
İşte tam da bu noktada devreye giriyor.
Benchmark Sonucu Neden Şaşırttı?
Editör masasında bu benchmark’ı görünce önce gözümü kısarak baktım, dürüst olayım (kendi tecrübem). Çünkü sezgisel olarak pek çok insan “CLI daha hafif olur, süreci yönetmek kolaydır” diye düşünüyor — ben de bir köşemden bunu bekliyordum açıkçası. Oysa ölçümde tam tersi çıkmış: MCP doğrudan yolunda ciddi şekilde önde.
| Metrik | MCP (direct stdio) | CLI (subprocess per call) | Kazanan |
|---|---|---|---|
| Çağrı başına gecikme | 119 ms | 3.023 ms | MCP |
| 5 adımlı iş akışı | 2,7 sn | 15,2 sn | MCP |
| Araç tanımı token yükü | 7.986 token | 95 token | Kullanıma göre değişir |
| Çıktı doğruluğu | Aynı | Aynı | Eşitlik var |
Açıkçası, Sadece rakamlara bakınca insanın kafası karışıyor — çünkü burada iki ayrı kazanma biçimi var. MCP hızda açık ara önde. CLI ise token tasarrufunda bariz fayda sağlıyor. Yani mesele tek boyutlu değil; kullanım senaryosu belirleyici oluyor ve bunu atlamak çok kolay.
Bir dakika, şunu da ekleyeyim. Sonuçların eşit çıktığı yerde bile deneyim eşit değil. Aynı işi iki yöntem de yapabiliyor — ama biri bunu yağ gibi akıtıyor. Diğeri ise sanki her komutta valiz toplayıp tekrar odaya dönüyor gibi davranıyor (ki bu çoğu kişinin gözünden kaçıyor). Bunu bir kez hissedince bir daha “ikisi de aynı sonucu veriyor, ne fark eder” diyemiyorsunuz.
Tarayıcı otomasyonunda “aynı sonucu veriyor” demek yetmiyor; süre, araç tanımı maliyeti ve entegrasyon biçimi çoğu zaman asıl hikâyeyi yazıyor.
Sahada Asıl Fark Nerede Çıkıyor?
MCP’nin güçlü olduğu yer net. Claude Code, Cursor ya da MCP konuşabilen herhangi bir istemciyle çalışıyorsanız, doğrudan protokolü kullanmak mantıklı geliyor çünkü ara katman yoksa hem gecikme düşüyor hem de hata ayıklama daha berrak oluyor; özellikle kurumsal tarafta log zinciri sade kalınca ekipler rahat ediyor, o ayrı bir nimet (bizzat test ettim) Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Buna karşılık CLI’ın cazibesi başka yerde yatıyor. Bash içinde çalıştırabiliyorsunuz, cron’a koyabiliyorsunuz, CI/CD boru hattına iliştirebiliyorsunuz… yani neredeyse her yere sokuyorsunuz. Geçen yıl Berlin’de çalışan bir arkadaşım böyle bir yaklaşımı gece çalışan rapor botunda kullandı — sabaha kadar veri çekmek yerine komut satırıyla işi halledince bakım yükü baya düşmüş dedi. Yani pratik tarafı yok mu? Var. Ama bedelsiz değil. Bu konuyla ilgili Python Performans Darboğazı: Tahmin Etme, Ölç yazımıza da göz atmanızı tavsiye ederim.
Küçük startup için durum ne?
Küçük ekiplerde hız önemliyse MCP tarafı genelde daha iyi hissettiriyor çünkü geliştiricinin önündeki sürtünmeyi azaltıyor, ve özellikle ürün yöneticisi “bunu hızlıca gösterelim” dediğinde — ki her startup’ta bu cümleyi en az günde üç kez duyarsınız — birkaç saniye bile gerçekten fark yaratabiliyor.
Kurumsal ekipte durum ne?
Büyük yapılarda ise bazen tersinden düşünmek gerekiyor. Eğer altyapınız shell tabanlı işleri merkezileştirmişse veya güvenlik politikaları gereği ajanların dış dünyayla sınırlı temas kurması gerekiyorsa CLI mantıklı olabilir. Ama performans bedelini peşinen kabul ederek. Bu bir tercih meselesi, kötü bir tercih değil — sadece gözünüz açık olsun. Daha fazla bilgi için AI Ajanı Öğretince Ne Oluyor?: #3’lük Sürpriz Hikâye yazımıza bakabilirsiniz.
Safari-MCP Neden İlginç Bir Örnek?
Peki niye Safari? macOS-native olması önemli bir avantaj sağlıyor ve oturumları koruma meselesi pratikte büyük rahatlık veriyor. Chrome overhead’inden kaçmak isteyenler için bu bayağı tatlı bir detay, küçümsememek lazım. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Ama beni en çok etkileyen şey sadece teknik performans değildi. Mimarinin düzeni oldu dersem abartmış olmam sanırım. 84 tool’u elle map etmek yerine şema odaklı üretmek, işin mutfağını temiz tutuyor (ilk duyduğumda inanamadım). Geçmişte benzer dönüşüm katmanlarını manuel yaptığım projelerde drift problemi yaşamıştık — testler geçiyordu. Üretimde alan adı enum’u kayıyordu (bizzat test ettim). Bir keresinde bu yüzden gece yarısı bir müşteri araması aldım; o günden beri “şema üretiyor musun, elle mi yazıyorsun?” diye sormayı hiç bırakmadım.
$ cli-anything-safari tools count
84
$ cli-anything-safari tools describe safari_click
Name: safari_click
Description: Click element...
Parameters:
--ref
--selector
--text
--x
--y
Böyle bakınca sistemin özü netleşiyor. Önce kaynak şemadan araç sözlüğünü çıkarıyorsun, sonra runtime’da buna göre komutları inşa ediyorsun (ki bu çoğu kişinin gözünden kaçıyor). Parity testleri de drift olursa bağırıp çağırıyor. Düzgün kurulduğunda bu yapı fena değil, hatta baya işe yarıyor. Ama el yordamıyla büyütmeye kalkarsanız kısa sürede çorba olur. Söz. Bu konuyla ilgili LangChain Ajanlarını Üretimde İzlemek: Gerçek Zamanlı Rehber yazımıza da göz atmanızı tavsiye ederim.
Nerede Hangi Yaklaşım Daha Mantıklı?
- MCP kullanın eğer istemciniz zaten MCP destekliyorsa ve ana hedefiniz düşük gecikmeyse.
- CLI kullanın eğer bash/cron/CI içinden erişmeniz gerekiyorsa ya da MCP bilmeyen ajanlarla uğraşıyorsanız.
- Tasarımı hibrit düşünün eğer hem geliştirici deneyimi hem otomasyon dağıtımı sizin için kritikse.
- Sadece moda diye katman eklemeyin; bazen sade yol gerçekten daha iyi oluyor!
Kimin için hangisi?
Küçük çapta deney yapan biriyseniz CLI’ın taşınabilirliği hoşunuza gider, bunu anlıyorum.
Ama üretimde milisaniye hesabına giriyorsanız doğrudan MCP’ye yaslanmak daha doğru görünüyor.
Ben olsam yeni başlayan ekibe önce direkt yolu öğretirim; ihtiyaç doğarsa shell köprüsünü sonradan ekleriz.
Peki hiç mi eksisi yok? Var tabii. MCP’nin güzelliği kadar bağımlılığı da yüksek olabiliyor — onu anlayan istemciye muhtaç kalırsınız, bu gerçek.
CLI tarafında ise insan kendini özgür hissediyor ama performans faturası sessizce geliyor, fark etmeden birikip duruyor.
Yani ikisinin de tadı başka diyelim. Maalesef kolay bir cevap yok.
Bana Göre Asıl Ders Ne?
İşin garibi, Lafı gevelemeden söyleyeyim: araç sayısı arttıkça değer artmıyor, bazen karmaşıklık artıyor. Bu benchmark bana tam olarak onu hatırlattı. “Her şeyi komuta çevirelim” yaklaşımı çok havalı duruyor — fakat gerçek dünya o kadar nazik davranmıyor. Süre, bellek, süreç açılışı, çıktı tamponu… hepsi ufak ufak yemeğe başlıyor. Sonunda tablo ortaya çıkıyor.
2026 Nisan ayında yapılan ölçümde sonuçlar bence beklenmedikti çünkü birçok kişi hâlâ kabuk araçlarının ucuz olduğunu varsayıyor. Halbuki modern agent işlerinde asıl pahalı olan şey sadece CPU değil — bağlam yönetimi. Tekrar eden meta veri yükü de ciddi pay alıyor, bunu gözden kaçırmak çok kolay (inanın bana). Bu yüzden direkt protokol kullanan sistemlerin eli güçleniyor ve bu eğilim bence daha da belirginleşecek.
Sıkça Sorulan Sorular
MCP mi yoksa CLI mı daha hızlı?
MCP genelde daha hızlıdır çünkü doğrudan protokolle çalışır. Her çağrıda ekstra süreç açmazsınız.
Benchmark örneğinde fark oldukça büyüktü. MCP konuşabilen istemcilerde tercih edilmesi gereken yol çoğunlukla budur.
CİI/CD ortamında hangi yaklaşım uygun?
Garip gelecek ama, Eğer tarayıcı otomasyonunu pipeline içinde koşturacaksanız CLI pratik olabilir.
Shell’den kolay tetiklenir. Mevcut betiklere uyum sağlar.
Ama gecikme maliyetini hesaba katmanız gerekir;
Aynı sonucu veriyorlarsa neden fark ediyor?
Dışarıdan bakınca çıktı aynı görünür.
Fakat toplam süre, token kullanımı ve hata ayıklama deneyimi farklıdır.
Üretimde asıl fark genelde burada çıkar.
Küçük proje için hangisini seçmeliyim?
Eğer hedefiniz hızlı prototipse MCP ile başlamak bana daha mantıklı geliyor.
Tarayıcıya yakın durursunuz, gereksiz sarma işleri azalır.
Sonradan gerekirse CLI köprüsü eklersiniz. (buna dikkat edin)
Kaynaklar ve İleri Okuma
Model Context Protocol Resmi Sitesi
HKUDS/CLI-Anything GitHub Sayfası (şaşırtıcı ama gerçek)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
