MCP mi CLI mı sorusu yanlış soru. Asıl soru şu: durum nerede yaşıyor?

21 Eylül 2026’da, saat 00:33 UTC’de Tobi Lütke şunu paylaştı: “LLM’ler için MCP ile CLI tartışması yanlış bir tartışma. İnsanlar yanlış katmanda tartışıyor.” Ardından 23 Ekim’de, yeni bir depoya, dquickts adlı projeye dikkat çekti. Bu, QuickJS’in bir çatalı: bir programı bir for döngüsünün ortasında duraklatabiliyor, tüm belleğini baytlara yazabiliyor ve onu başka bir süreçte kaldığı yerden sürdürebiliyor. “Mükemmel bir kod modu ortamı,” diye yazdı.

Katman konusunda haklı. Önce ona kendi sözleriyle katılmak, sonra da iddiayı bir senkronizasyonun kullanabileceği bir şey söyleyene kadar daraltmak istiyorum.

Kastettiği katman

Argümanı, onun kurduğu biçimiyle aktarıyorum; esnetmeyi düşündüğünüz bir argümanı alıntılamanın tek adil yolu budur:

İkisi de durumu koruyabilen REPL benzeri bir ortamın üzerinden çalıştırıldıkları sürece inanılmaz iyi çalışır. CLI’ın ilginç yanı şu: CLI araçlarına genellikle BASH üzerinden erişilir ve BASH da tesadüfen kalıcı durumu olan bir REPL’dir (dosya sistemi); bu yüzden CLI, MCP’den çok daha iyi çalışır. Ama bu, MCP’nin özünde bulunan bir özellik olmaya yakın bile değil. Sadece daha iyi çalıştırma ortamlarına ihtiyacımız olduğu anlamına geliyor.

Bu doğru ve birçok kişinin açıklamadan yaptığı bir gözlemi açıklıyor. CLI verilen bir ajan bir dosya yazar, üç adım sonra onu geri okur, içinde grep ile arar, başka bir komuta aktarır. Çıplak bir MCP sunucusu verilen bir ajan ise çağrı başına tek bir sonuç alır ve geri kalan her şeyi bağlam penceresinde taşımak zorundadır. CLI protokol sayesinde kazanmadı. Bash, bir şeyleri koyacak bir yerle birlikte geldiği için kazandı.

Bahsi de buradan çıkıyor. Biri bash’i, TypeScript’i ya da araç çağrılarını tek bir plana dönüştüren, çalışmadan önce denetlenen ve dayanıklı yürütme için tasarlanmış, gömülebilir, SQLite tarzı bir motor geliştirecek. dquickts bu yönde atılmış bir adım. README’si, “fonksiyonları ve değişkenleri yeniden başlatmalardan sağ çıkan” bir REPL’i anlatıyor. Ayrıca dayanıklı bir ana bilgisayar çağrısını da anlatıyor: “bir betik, yanıtı saatler sonra gelen bir ana bilgisayar fonksiyonunu çağırır. Süreç betiği kaydeder ve çıkar.”

Buraya kadar tam bir uzlaşma var. Şimdi daraltmaya geçelim.

Hangi iş için hangi durum

“Durumu korumak” bir soruyu gizliyor: kimin durumu ve hangi biçimde? Bir kodlama ajanı için durum depo ve kabuktur; yeniden başlatmalardan sağ çıkan bir REPL de iyi bir yanıttır. İki SaaS sistemi arasında bir senkronizasyon kuran bir ajan içinse, adımlar arasında ihtiyaç duyduğu durum işin kendisi tarafından zaten tanımlanmıştır. Bu durumu dört kayıt taşır ve hiçbiri bir betikteki değişken değildir.

İmleç. Bir senkronizasyon kaynağı pencereler hâlinde okur ve son pencerenin nerede bittiğini bilmek zorundadır. Tajo’nun senkronizasyon motorunda bu, her senkronizasyon ve kapsam için saklanan, başarısız kaydı olmayan her toplu işlemden sonra yazılan bir imleçtir; bir sonraki çalıştırma oradan devam eder. Zamanlanmış bir çalıştırma, başka bir şey yapmadan önce başlangıç noktasını kaydeder; böylece başarısız olan ilk çalıştırma, bir sonrakinin aynı noktadan okumasını sağlar. Bunun arkasındaki ilke, yani tabloyu değil yalnızca farkı göndermek, ters ETL açıklamasında anlatılıyor. İmleci orada bırakıyorum.

Bekleyen öneri. Tajo’nun bağlayıcı MCP araçlarında bir yazma işlemi iki çağrıdır. brevo_propose girdiyi tanımlanmış eyleme göre doğrular ve bir öneri kaydeder. Hiçbir şey gönderilmez. Sonuç bir öneri kimliği ve bir kişinin karar vermesi gerektiğinde, onaylayacağı sayfayı içerir. brevo_apply, o bağlantının onaylanmış yazma işlemlerini sırayla çalıştırır ve hâlâ bir kişiyi bekleyen ilk işlemde durur. Aradaki kayıt durumun ta kendisidir. Girdiyi ve girdinin bir özetini tutar; böylece onaylanmış bir yazma işlemi, karar ile uygulama arasında değiştirilemez. Sağlayıcının yanıt değerlerini tutmaz, çünkü yalnızca eklemeye açık bir onay kaydı kişisel veri deposuna dönüşmemelidir.

Kira. Bir senkronizasyonun her çalıştırması, tüm ömrü boyunca tek bir özel kira tutar: bir sahip belirteci, varsayılan olarak on beş dakikalık bir süre sınırı ve yenileme ile. Eski bir sahip, daha yeni bir kirayı serbest bırakamaz. Kira deposuna ulaşılamıyorsa çalıştırma tahmin yürütmek yerine başlamayı reddeder. Çalıştırmayı hangi işçinin tuttuğu, herhangi bir sürecin belleğinde değil, kirada yazılı bir olgudur.

Plan. syncs.dryRun imleçten bir sonraki pencereyi okur, her kayıt için ekleme, güncelleme, silme ya da değişiklik yok kararını çıkarır ve tam olarak tek bir satır yazar: bir saat saklanan planı. Hiçbir imleci ilerletmez ve iki sistemin hiçbirine bir şey yazmaz. syncs.apply bu planı bir kez yazar. Bu arada imleç ilerlediyse ya da kayıtların tolere edilen paydan fazlası değiştiyse reddeder. Tekrarlanan bir çağrı yeniden yazmak yerine ilk sonucu döndürür.

Adımlar arasındaki durum budur: kimliği olan ve görmeye yetkili her ajanın okuyabildiği dört kayıt.

MCP tarafı neden oturumda hiçbir şey tutmuyor

Durum kayıtlara geçtiğinde, bir oturumun tutacağı hiçbir şey kalmaz. Bu yüzden Tajo’nun MCP uç noktaları oturum tutmaz. Her istek yeni bir sunucu ve oturum kimliği olmayan bir taşıma katmanı alır. Okumalar çağrı başına tek istektir ve sonuçlar, tek bir yanıt bir turu doldurmasın diye sınırlandırılmıştır. Yazma işlemleri önce öneri, sonra uygulamadır ve taşıdığınız şey önerinin kimliğidir.

Protokol de aynı yöne ilerledi. MCP spesifikasyonunun 2026-07-28 revizyonu, protokol düzeyindeki oturumları ve Mcp-Session-Id başlığını Streamable HTTP taşıma katmanından kaldırdı. Süreklilik isteyen bir sunucu artık kendi tanıtıcısını üretiyor ve onu sıradan bir argüman olarak geri alıyor. Bir öneri kimliği tam olarak budur. MCP sunucusu nedir yazısı bu revizyonu ve bir araç çağrısının dayanıklı bir senkronizasyondan nasıl ayrıldığını ele alıyor; bu yazı yalnızca durumun nereye gittiğiyle ilgili.

Entegrasyon çalışması için önemli olan sonuç şu. Claude Code’daki bir ajanın bir yazma işlemi önerdiğini ve oturumunun sona erdiğini düşünün. Kişi bunu bir saat sonra onaylıyor. Farklı bir istemcideki bir ajan ya da ertesi gün aynı ajan, kimlikle uygulama çağrısını yapıyor ve yazma işlemi bir kez gerçekleşiyor. Çöken bir ajan bağlam penceresini kaybeder, başka hiçbir şeyi değil. Hiçbir şey askıya alınmadı, bu yüzden hiçbir şeyin sürdürülmesi gerekmedi.

Neyimiz yok ve bunun bedeli ne

Dürüst itiraz REPL tarafından gelir ve şöyledir: “Tamam, kayıtlarınız ayakta kalıyor. Ama her çağrı, bir önceki çağrının zaten elinde olanı yeniden okuyor. Bir betik kişileri bir kez çeker, birleştirir, filtreler ve bir sayı döndürürdü. Sizin ajanınız beş çağrı yapıyor ve her birinin bedelini ödüyor.” Bu itiraz mekanizma konusunda haklı ve bedeli ölçmedik. Taşınan durumla ve taşınan durum olmadan görev başına çağrı sayısını sayacak değerlendirme henüz kurulmadı. Kurulana kadar, çağrı modunun daha fazla token harcadığı iddiası yanıtsız kalıyor.

Üç şeyin daha açıkça söylenmesi gerekiyor, çünkü bu yazıyı bitiren bir okur bunların var olduğunu sanmamalı:

• Bugün müşterinin yazdığı hiçbir kod çalışmıyor. Bağlayıcı okumaları, yolda hiçbir korumalı alan olmadan çağrı başına tek istektir. Altyapımızda bir kod çalıştırıcı var ve bu dahili bir araç. Üretimde, iki ayrı bayrak ayarlanmadıkça kapalıdır ve yalnızca yöneticilere yanıt verir. Her çağrı yeni bir bağlam, yalnızca okumaya izin veren bağlamalar ve eşzamanlı kod için iki saniyelik bir süre bütçesi alır. Kendi başlığı, büyük harflerle, bunun bir güvenlik sınırı değil bir doğruluk sınırı olduğunu söyler.
• REPL yok. Bir ajanın bir çağrıda hesapladığı hiçbir şey, kimliği olan bir kayıt olarak yazılmadıkça bir sonraki çağrıda kullanılamaz.
• Kalıcı ajan oturumu yok. İstemci kendi konuşmasını tutar. Tajo önerileri, planları, imleçleri ve kiraları tutar. Üçüncü bir şey yoktur.

Dayanıklı bir motor ne işe yarar

Bunların hiçbiri dquickts’e karşı bir argüman değil. README’si anlık görüntülerin ne işe yaradığını sıralıyor ve liste iyi. Boşta bekleyen bir betiği uyku moduna alıp belleğini boşaltmak. Uzun bir hesaplamayı, hangi işçi boştaysa onda dilimler hâlinde çalıştırmak. Kurulumu tekrarlamak yerine her örneği bir anlık görüntüden hızlı başlatmak. Bir betiği, yanıtı daha sonra gelen bir ana bilgisayar çağrısında bekletmek. Bir kodlama ajanının çalışma alanı ya da yeniden başlatmadan sağ çıkması gereken bir not defteri için doğru araç budur.

Yine de bir senkronizasyon buna bağlı olmamalı ve bunun üç nedenini bana README’nin kendisi veriyor. Birincisi: “Bir oturum dosyası yalnızca onu yazan qjs derlemesine yüklenir.” Bir motor sürümünün yazdığı bellek, bir yükseltmeden sonra ölü bir dosyadır; bir imleç ise bir dizedir. İkincisi: “Anlık görüntüler, bayt kodu gibi güvenilir girdidir” ve “kötü niyetli olanlar tespit edilmez.” Saklanan bir bellek, inceleyebileceğiniz bir şey değil, korumanız gereken bir şeydir; bir öneri ise bir kişinin onaylamadan önce okuduğu bir satırdır. Üçüncüsü, bir anlık görüntü betiğin okuduğu her şeyi, müşteri kayıtları dahil, içinde tutar. Yukarıdaki kayıtlar bunun tersine kurulmuştur: plan değerleri değil özetleri saklar ve öneri kaydı sağlayıcının yanıtını asla saklamaz.

Uyduğumuz kurallardan biri şudur: deterministik olan, zekice olanı yener. Döngünün ortasından devam eden bir bellek zekicedir. Bir imleç, bir öneri, bir kira ve bir plan ise sıkıcıdır, incelenebilir ve her motorda, her istemcide, her çöküşten sonra aynıdır.

Lütke doğru soruyu sordu. Durum nerede yaşıyor? Bir senkronizasyon için yanıt hiçbir zaman süreçte olmayacaktı. Her zaman kayıtlarda olacaktı, çünkü yazma işlemini onaylayan kişinin onu okuyabilmesi gereken yer orasıdır.