MCP öldü. Yaşasın CLI

 (ejholmes.github.io)
36 puan yazan GN⁺ 2026-03-02 | 8 yorum | WhatsApp'ta paylaş
  • MCP sektörde hızla ilgi kaybediyor ve artık CLI tabanlı yaklaşım daha pratik
  • LLM'ler zaten komut satırı araçlarını kullanmakta yetkin; ayrı bir protokol olmadan da belge ve CLI ile işleri rahatça yapabiliyor
  • CLI, hem insanların hem de LLM'lerin aynı ortamda çalıştırıp hata ayıklayabilmesini sağlar; bu da sorunun nedenini bulmayı basitleştirir
  • Birleştirilebilirlik (composability), kimlik doğrulama yapısı ve kararlılık açısından da CLI, MCP'den daha verimli ve bakımı daha kolaydır
  • MCP; başlatma kararsızlığı, tekrarlayan yeniden kimlik doğrulama ve yetki kontrolünün eksikliği gibi nedenlerle pratikte sürekli sürtünme yaratır
  • Çoğu durumda CLI daha basit ve daha güvenilir bir seçenektir; şirketler MCP sunucularından önce API ve CLI sunmaya odaklanmalıdır

MCP'nin sınırları ve CLI'nin üstünlüğü

  • Anthropic'in Model Context Protocol (MCP) duyurusundan sonra sektör hızla MCP sunucuları kurmaya girişti, ancak OpenClaw ve Pi gibi önemli araçlar bunu desteklemiyor ve ortada kayda değer bir fayda da yok
    • LLM'ler zaten CLI ve belgeler üzerinden işleri yapabiliyor
    • MCP yeni endpoint'ler ve kimlik doğrulama yapıları ekliyor, ancak mevcut işlevleri tekrar ediyor
  • LLM'ler CLI araçlarını kullanmak için son derece uygundur ve bu konuda oldukça beceriklidir
    • Milyonlarca man page, Stack Overflow yanıtı ve GitHub shell script'i üzerinde eğitildiler
    • Örneğin Claude'a gh pr view 123 gibi bir komut verildiğinde bunu doğrudan çalıştırabilir
  • MCP daha temiz bir arayüz vaat etti, ancak pratikte her aracın açıklamasını, parametrelerini ve ne zaman kullanılacağını aynı şekilde belgelendirmeniz gerekir

CLI insanlar için de faydalı

  • CLI, insanların ve LLM'lerin aynı komutları paylaşmasına olanak tanır
  • Jira beklenmedik bir davranış sergilediğinde, aynı jira issue view komutunu doğrudan çalıştırarak durumu yeniden üretebilirsiniz
  • MCP'de araçlar yalnızca LLM konuşmasının içinde var olur; bir sorun çıktığında JSON aktarım günlüklerini kurcalamak gerekir
  • Hata ayıklama için protokol çözücüsü gerekmemelidir
  • CLI'de girdi ve çıktı nettir; bu yüzden sorunu izlemek kolaydır

Birleştirilebilirlik (Composability)

  • CLI, jq, grep, dosya yönlendirme gibi araçlarla pipeline içinde birleştirilebilir
  • Büyük bir Terraform planını analiz etme örneği:
    • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
  • MCP ile ya tüm planı context window'a dökmeniz gerekir (maliyetli ve çoğu zaman imkânsızdır) ya da özel filtrelemeyi doğrudan MCP sunucusuna uygulamanız gerekir
  • CLI yaklaşımı, zaten var olan ve iyi belgelenmiş araçları kullanır; hem insanlar hem de ajanlar tarafından anlaşılabilir

Kimlik doğrulama sorunları

  • MCP, kimlik doğrulama konusunda gereksiz ölçüde dayatmacı (opinionated)
  • CLI araçları zaten doğrulanmış kimlik doğrulama düzenlerini kullanıyor: aws profiller ve SSO kullanır, gh için gh auth login, kubectl için kubeconfig vardır
  • İster insan doğrudan kullansın ister Claude çalıştırsın, aynı kimlik doğrulama akışı geçerlidir
  • Kimlik doğrulama sorunu çıktığında aws sso login, gh auth refresh gibi mevcut yöntemlerle çözüm bulunabilir; MCP'ye özel sorun giderme gerekmez

Operasyonel sorunlar: Hareketli parça yok (No Moving Parts)

  • Yerel MCP sunucuları için ayrıca bir sürecin başlatılması ve ayakta tutulması gerekir; Claude Code'da bunlar alt süreç olarak oluşturulur ve zaman zaman sorun çıkarır
  • CLI araçları ise yalnızca diskte duran ikili dosyalardır; arka plan süreci, durum yönetimi veya başlatma prosedürü gerekmez

Pratikte yaşanan sıkıntılar

  • Başlatma kararsızlığı: MCP sunucusu başlamadığı için Claude Code'u yeniden başlatmak sık görülür; durumu sıfırlayıp tekrar denemek gerekir
  • Tekrarlayan yeniden kimlik doğrulama: Birden fazla MCP aracı kullanıldığında her biri için yeniden giriş gerekir; buna karşılık SSO veya uzun ömürlü kimlik bilgileri kullanan CLI'de bu sorun yoktur
  • Yetki kontrolünün kabalığı: Claude Code içinde MCP araçlarına isim bazında izin verilebilir, ancak salt okunur kısıtı koymak veya parametre aralığı tanımlamak mümkün değildir
    • CLI'de gh pr view komutuna izin verip gh pr merge için onay istemek gibi ince ayarlı yetki kontrolü mümkündür

MCP'nin geçerli olduğu durumlar

  • Karşılığı olan bir CLI aracının hiç bulunmadığı durumlarda MCP uygun olabilir
  • Standartlaştırılmış bir arayüz olarak değer taşıdığı ve bazı kullanım senaryolarında CLI'den daha uygun olabileceği kabul edilebilir
  • Ancak çoğu işte CLI daha basit, hata ayıklaması daha hızlı ve daha güvenilirdir

Temel ders ve geliştiricilere çağrı

  • En iyi araç, hem insanlar hem de makineler için çalışan araçtır; CLI onlarca yıllık tasarım yinelemeleri sayesinde birleştirilebilir, hata ayıklaması kolaydır ve mevcut kimlik doğrulama sistemleriyle entegredir
  • MCP daha iyi bir soyutlama kurmaya çalıştı, ancak aslında zaten yeterince iyi bir soyutlama mevcuttu
  • MCP sunucularına yatırım yaparken resmî CLI'si olmayan şirketler stratejilerini yeniden düşünmeli;
    iyi bir API → iyi bir CLI sırasıyla sunulduğunda ajanlar bunları zaten kullanacaktır
  • Gereksiz protokol karmaşıklığı azaltılabilir ve üretkenlik ile bakım kolaylığı artırılabilir

İlgili okumalar

8 yorum

 
sonnet 2026-03-03

MCP'nin hiçbir avantajı olmadığı değil; mesele, MCP'nin avantaj sağlamadığı kullanım alanlarında onu ayrım gözetmeden kullanma yanılsamasından uyanmış olmamız. Mikro servisleri LLM için dışa açarken de CLI kullanmayacaksınız; sonuçta MCP bir 'API' protokolü.
 
brainer 2026-03-03

O zaman da API kullanmak yeterli olur. Aslında MCP kullanılmasının nedeni long context sınırıydı; artık bu sınır büyük ölçüde aşıldığı için.
 
jamsya 2026-03-03

Kesinlikle katılıyorum.
aws mcp kurulu olmasa bile Claude Code gerekli olanı aws cli ile kendi kendine çekip kullanıyor 😂
 
GN⁺ 2026-03-02
Hacker News yorumları

  • Bunu uzun zamandır söylemekten kaçınıyordum ama artık MCP’nin pratikte kayda değer bir avantajı olmadığına eminim
    Tüm geliştirme iş akışımı kabuk komutlarıyla kontrol eden AI ajanları çalıştırıyorum; bunlar bir CLI bayrağını ilk kez görseler bile sadece --help çıktısıyla ne yaptığını gayet iyi kavrıyor
    Buna karşılık MCP sunucuları sürekli kırılgan oldu ve bakım gerektirdi
    CLI ise jq, grep, dosya yönlendirme gibi araçlarla birleştirilebilirken MCP, sunucunun döndürdüğü biçime hapsoluyor
    Sonuçta MCP benim gözümde teknik nedenlerden çok ‘AI-first’ pazarlama sinyali niteliğinde

    • MCP 2024’te hızla büyüdü ama 2025’in başında terminal ajanlarının (Claude Code) ortaya çıkmasıyla meta’nın hızla değiştiği bir örnek olduğunu düşünüyorum
    • Ben tersine MCP’yi tercih ediyorum. CLI’ye göre hata işleme ve hata ayıklama çok daha temiz, ayrıca tehlikeli bayrakları kısıtlayabiliyor veya sonuçları sayfalama ile bölebiliyorsunuz
      MCP’yi REST ya da gRPC gibi basit bir sarmalayıcı olarak düşünmek yeterli
    • Ben de MCP’den kaçınıyorum. JIRA MCP’yi denedim ve berbattı. Onun yerine LLM’in API’yi doğrudan çağırmasına ve betikler yazmasına izin verince çok daha verimli oldu
      Şu an zirvenin LLM CLI araçları olduğunu düşünüyorum
    • Bizim şirkette iç wiki gibi yalnızca web’e özel araçları MCP üzerinden açıp Claude’un log’ları ve metrikleri doğrudan sorgulamasını sağlıyoruz
      Yine de MCP sonuçlarının her zaman bağlam penceresine girmesi rahatsız edici. Keşke dosya sistemine dökülebilse
    • MCP sunucuları, LLM’lerin daha az gelişmiş olduğu dönemde ortaya çıkmış geçiş ürünü gibi geliyor. CLI verileriyle eğitimin çok daha iyi olduğunu düşünüyorum

  • MCP, kurulum ya da kaynak sağlama gerektirmeden doğrudan çağrılabilen bir kara kutu API gibi
    CLI ise yerel ortama erişebildiği için çok daha hassas
    jq, duckdb CLI kullanarak büyük veri dosyalarından örnekleme yapıyorum ve Opus 4.6 sorguları otomatik ayarlayarak keşif yapıyor
    CLI’nin gerçek zamanlı tepkiselliği yüksek olduğu için keşifsel veri analizi için özellikle faydalı
    Sık kullandığım CLI’lar arasında showboat, br, psql, roborev var

    • Ben de aynı deneyimi yaşadım. CLI’nin metin girdi/çıktısı, LLM’lerin eğitim biçimiyle en iyi eşleşen şey
      duckdbyi ChatGPT ile kullanırken çok keyif almıştım; sistem isteminde yerel DB’yi korumasını ayarlayıp ayarlamadığınızı merak ediyorum
    • CLI yerine komutları Docker container içinde çalıştırırsanız kurulum sorunlarından kaçınabilirsiniz. Bu yaklaşımı otomatikleştiren bir ‘skill’ bile yapılabilir
    • İngilizce ana dili olmayan biri olarak MCPs gibi çoğul kullanımlar bana eğlenceli geliyor

  • MCP, CLI’de olmayan araçları keşfetmek ve onları bağlama göre çağırmak gerektiğinde anlamlı
    Örneğin benim yaptığım echomindr, podcast’lerden kurucu kararlarını çıkaran bir veritabanını MCP olarak sunuyor
    Claude, startup’larla ilgili soru aldığında gerçek kurucu deneyimlerini arayıp buna göre yanıt veriyor
    CLI, insanın hangi aracı kullanacağını zaten bildiği durumlar için uygunken MCP keşfe dayalı araç seçimi için daha uygun

  • Yazının yazarı AI kullanımına fazla geliştirici merkezli bakmış gibi
    Kullanıcıların çoğu LLM’leri ChatGPT gibi web tabanlı arayüzler üzerinden kullanıyor
    Şirketler açısından bakıldığında pazarlama, satış ve proje yönetimi araçlarını bağlamak için MCP çok daha uygun

  • MCP’nin kendisi kötü değil ama stdio MCP aşırı tasarlanmış
    Bunun yerine Streamable HTTP + OAuth Discovery yaklaşımı bugünlerde AI entegrasyonu için en verimli yol
    Örneğin Sentry MCP, tek bir URL ile kimlik doğrulama ve veri erişimi sağlayabiliyor
    Sorun MCP’nin uygulanış biçimi. Bash ile çağırmak yerine MCP’yi bir HTTP endpoint olarak açarsanız çok daha esnek çalışır

    • İster CLI ister MCP olsun, yetki sistemi API seviyesinde tutarlı şekilde tasarlanmalı. Streamable HTTP kısmı biraz daha açıklama gerektiriyor
    • Ben de aynı noktadayım. Merkezileştirilmiş kimlik doğrulama ve telemetri çok daha basit. Yalnız doğru kullanım senaryolarıyla sınırlı kalmalı

  • Bazı müşterilerimde MCP sunucusu yok ama geliştiriciler bunu talep ediyor
    Sonunda Postman API’yi JSON olarak dışa aktarıp verdik ama geliştiriciler yine de MCP sunucusu istiyor
    MCP desteği bir pazarlama kontrol listesi maddesi gibi işliyor

  • Bu blog geliştirici merkezli bakışa fazla yaslanıyor gibi
    Geliştirici olmayanlara yönelik araç ve servislerle bağlantı kurarken MCP çok daha doğal

    • Evet. Sohbet arayüzlerinde CLI çalıştırmak mümkün değil ve geliştirici olmayanlara yönelik servislerin zaten CLI’si de yok
    • ChatGPT ya da LeChat gibi web ve mobil arayüzlerde CLI çalıştırmanın mümkün olup olmadığını ben de merak ediyordum
    • Geliştirici olmayanlara yönelik arayüzler zaten OpenClaw, Claude Cowork gibi biçimlere evriliyor

  • “MCP’de 5 yıl deneyimli eleman aranıyor” tarzı iş ilanları da sonuçta anlamsız bir memee dönüşmüş oldu

  • CLI’nin MCP’den daha iyi olmasının nedenlerinden biri, bilgi kuramı açısından optimize edilmiş bir biçime sahip olması
    Unix araçlarının çıktısında ilgili bilgiler birbirine yakın yerleştirilir; bu da LLM’lerin dikkat mekanizmasının verimli çalışmasını sağlar
    JSON parse etmesi kolay olsa da okuyup akıl yürütmek için elverişsiz
    CLI biçimi hem insanlar hem LLM’ler için sezgisel
    İlgili okuma: Entropy and Information Layout

  • MCP ile CLI karşılaştırması biraz OpenAPI ile string’leri (JSON) karşılaştırmaya benziyor
    MCP biçimsel olarak tanımlıyken CLI (String, List String, Map Int Stream) -> PID düzeyinde soyut bir arayüz
    Sonuçta ikisi de birer API; önemli olan hedefe ulaşmak için doğru aracı seçmek

    • Ama CLI, --help ile tam dokümantasyon sunduğu için LLM bunu anlayabiliyorsa MCP standardizasyonunun daha iyi olduğunu söylemek zor
    • Teoriden çok gerçek kullanım deneyimi önemli. MCP ile CLI’nin aynı olduğunu söylemek için mesela Playwright CLI ile MCP’nin aynı token kullanımı ve yapılandırılabilirlik sunduğunu gösteren bir örnek üretmek gerekir
      Aksi halde pratikte bu iki yaklaşımın farklı olduğunu bizzat hissedersiniz
 
develosopher 2026-03-03

Birisi bir SaaS geliştirmişse ve yapay zeka entegrasyonu için cli ile mcp arasında birini seçmeyi düşünüyorsa, muhtemelen önce mcpyi seçer. CLI desteği vermek, yönetim noktalarının artması anlamına geliyor çünkü. Birlikte var olabilirler ama ortadan kalkacaklarını sanmıyorum.
 
hanje3765 2026-03-03

Görünüşe göre, llm'nin zekası arttıkça mcp'ye olan ihtiyaç belirsizleşmiş diyorlar.
Ben de gerçekten böyle hissediyorum.
 
m00nlygreat 2026-03-03

Görünüşe göre uzaktan çalıştırma için mcp, yerel çalıştırma içinse skills kullanılacak.
 
hulryung 2026-03-03

Ben de MCP yerine araçları doğrudan CLI ile kendim yapıp kullanmaya başladım.