Tarayıcı işlemleri MCP’ye devredildiğinde iş akışı nasıl değişiyor ve koddan hangi parçalar kayboluyor? Bu pratik yazı, sorumlulukların nasıl bölüneceğini, dört yaygın yapılandırma sorununu ve sorun giderme sırasını ele alıyor.
Claude Code ile tarayıcı otomasyonu yazarken ilk can sıkan şey genellikle glue code olur: tarayıcıyı başlatmak, proxy bağlamak, environment oluşturmak ve handle beklemek. Bunların iş mantığıyla doğrudan ilgisi yoktur ama tekrar tekrar yazılması gerekir. Tarayıcı işlemleri MCP üzerinden dışarı devredildiğinde bu bölüm büyük ölçüde koddan kaybolur. Yapılacak işi tarif edersiniz, hangi tool’un çağrılacağına model karar verir.
Sorumluluklar nasıl bölünür
Claude Code, komut satırında çalışan bir kodlama asistanıdır. Dosya okuyup yazabilir, komut çalıştırabilir ve Git ile çalışabilir. Güçlü olduğu taraf kod ve terminaldir. Tarayıcıyla doğrudan etkileşim onun güçlü yanı değildir ve bu işi üstlenmesi de gerekmez.
MCP tam olarak bu boşluğu doldurur. Tarayıcı otomasyon environment’ının yeteneklerini, kayıt sonrasında modelin çağırabileceği bir tool seti olarak sunar: environment listelemek ve oluşturmak, tarayıcıyı başlatmak ve durdurmak, ekran görüntüsü almak ve sayfa içeriğini okumak. Bir taraf kodu ve logları, diğer taraf tarayıcıyı ve sayfaları yönetir. Sınır net olduğunda sorunların kaynağını bulmak da kolaylaşır.
İş akışı nasıl değişir
En belirgin değişiklik, tüm zincirin daha hızlı kurulabilmesidir. Önceden süreçte yapılan her değişiklik script düzenlemeyi gerektirirdi. Şimdi önce doğal dille denenebilir: mevcut environment’ları listele, ikisinde giriş yapıp ekran görüntüsü al ve sonuçları özetle. Akış çalıştıktan sonra kalıcı bir script’e dönüştürülür.
Gerçek projelerde genellikle üç katman birlikte çalışır. MCP doğal dil talimatlarını üstlenir ve keşif ile geçici görevler için uygundur. Yerel HTTP API, örneğin tek seferde onlarca environment oluşturmak gibi toplu işlemleri üstlenir; kararlı çalışır ve yeniden denemesi kolaydır. Belirli bir state’i beklemek veya sayfadan structured data çıkarmak gibi hassas etkileşimler ise CDP üzerinden tarayıcıya bağlanarak yapılabilir. Bu üç yaklaşım birbiriyle çelişmez; her biri iş akışının farklı bir bölümünü yönetir.
Environment katmanını ayrı yönetmenin önemi de bu aşamada netleşti. Environment’lar farklı script’lere dağılmışsa görev sayısı arttıkça sorun incelemek zorlaşır. Artık environment-level tools ile oluşturma, görüntüleme ve toplu reclaim işlemleri merkezi olarak yapılıyor; script yalnızca kullanacağı bir environment ID alıyor. Çok hesaplı senaryolarda PurpleMark gibi bir izolasyon çözümü tam olarak bu katmanda görev yapar: her hesabın environment, session ve cache verilerini ayırır, böylece execution layer bunları güvenilir biçimde zamanlayabilir.
Sık takılınan dört nokta
İlk sorun tool’un tanınmamasıdır. Çoğu client configuration’ı yalnızca başlangıçta okur; bu yüzden kayıt yaptıktan sonra yeniden başlatılmazsa değişiklik etkili olmaz. Configuration file path’inin yanlış olması da sık görülür, çünkü farklı araçlar dosyayı farklı konumlarda tutar. Basit ama etkili bir test şudur: service’i elle başlatın. Başlıyorsa sorun büyük olasılıkla configuration’dadır; başlamıyorsa environment’dadır.
İkinci sorun authentication başarısızlığıdır. En yaygın neden, credential kopyalanırken fazladan boşluk veya satır sonu eklenmesidir. Önce bunu kontrol edin, ardından environment variables’ın nasıl okunduğuna bakın. Farklı işletim sistemleri ve launch yöntemleri farklı sonuçlar verebilir.
Üçüncü sorun local API’nin çalışmamasıdır. Birçok MCP service, client application’ın kendisinin açık olmasına bağlıdır. Client çalışmıyorsa service başlamayabilir veya connection timeout olabilir. Port’un kullanımda olup olmadığını da kontrol edin; düzgün kapanmamış eski bir process port’u tutuyor olabilir. Port numarası client settings içinden doğrulanabilir.
Dördüncü sorun concurrent task’lerin birbirini etkilemesidir. Tek başına çalışan bir task sorunsuz olabilir, ancak birkaçı birlikte çalıştırıldığında data karışabilir veya login session’lar birbirini ezebilir. Bunun temel nedeni genellikle birden fazla task’in aynı environment’ı paylaşmasıdır. Bu sorun yalnızca debugging ile çözülemez; bir kural gerekir: her task için bir environment, environment oluşturma ve reclaim işlemleri batch API üzerinden yapılmalı ve script içinde geçici olarak oluşturulmamalıdır.
Hata ayıklamada birkaç alışkanlık
Talimatlarda waiting condition açıkça belirtilmelidir. “Gönder düğmesine tıkla” yeterli bilgi vermez. “Gönder düğmesi tıklanabilir olana kadar bekle, sonra tıkla” çok daha güvenilir sonuç verir. Ne yapılacağına model karar verebilir, ancak ne zaman beklemesi gerektiğini sizin belirtmeniz gerekir.
Zinciri doğrulamaya read-only task’lerle başlayın. Environment listelemek, ekran görüntüsü almak ve sayfa metnini okumak yan etki oluşturmaz; buna rağmen authentication, network ve service üçlüsünü tek seferde kontrol eder. Zincir çalışmıyorsa yan etkili işlemlere geçmek için acele etmeyin.
Credential’ları code içine yazmayın. Environment variables veya local configuration files kullanın ve bu dosyaları ignore list’e ekleyin; ekipte değişiklik olduğunda credential’ları rotate edin. Local API kendi validation mekanizmasını kapatmışsa en azından yalnızca local machine üzerinde dinlediğinden ve dışarıdan erişilemediğinden emin olun.
Son sınır şudur: MCP teknik zinciri birbirine bağlar, platform kurallarını değiştirmez. Entegrasyon ne kadar sorunsuz olursa olsun, görev için geçerli tüm hizmet şartlarına yine de uyulmalıdır.
