- CLI, ajan araç arayüzleri için yeni trend olarak öne çıktı; ancak özel CLI’lar da MCP ile aynı bağlam sorunlarını yaşıyor ve yapılandırma ile çeşitli avantajlardan vazgeçmek zorunda kalıyor
- Yerel
stdio modundaki MCP ile Streamable HTTP tabanlı uzak MCP, tamamen farklı kullanım senaryolarına sahip; ancak bu ayrım mevcut tartışmalarda gözden kaçıyor
- MCP’nin Prompts ve Resources özellikleri, organizasyon genelinde standartlaştırılmış beceri ve belgeleri gerçek zamanlı dağıtma mekanizması olarak, vibe coding’den sistematik ajan mühendisliğine geçişte kritik önemde
- Merkezi MCP sunucuları, OAuth kimlik doğrulaması, telemetri, gözlemlenebilirlik konularını standartlaştırarak organizasyon ölçeğinde güvenlik ve araç etkinliği ölçümünü mümkün kılıyor
- Bireysel geliştiriciler için CLI uygun olabilir; ancak organizasyon ve kurumsal seviye için MCP, tutarlılık, güvenlik ve kaliteyi garanti eden bugünün ve geleceğin aracı
Influencer odaklı hype döngüsü
- Sadece 6 ay önce Model Context Protocol (MCP) sektörün en büyük gündem maddesiydi ve tüm satıcılar MCP ile ilgili ürünler çıkarmaya çalışıyordu
- O dönemde de “sonuçta sadece bir API, neden bir wrapper gerekli?” şeklinde şüpheci bir bakış vardı; nitekim MCP hype döngüsünü atlayıp REST API endpoint’lerinin üstüne basit araç wrapper’ları yazmayı seçen ekipler de vardı
- Çoğu kullanım senaryosunda MCP’nin, API’yi doğrudan çağırmaya kıyasla gereksiz bir ek yük olduğu yönündeki algı yaygınlaştı
- Şu anda sektördeki söylem MCP eleştirisine ve CLI övgüsüne kaymış durumda; bu da AI influencer’larının ilgiyi canlı tutmak için sürekli yeni trendler üretmesiyle ilgili
- Garry Tan ve Andrew Ng gibi önde gelen isimler bile kişisel deneyimlerini genelleştirme eğiliminde; FOMO ve hype üreten influencer kültürü bu alandaki söylemi çarpıtıyor
- CLI’ın ajan araç arayüzü olarak gerçekten daha uygun olduğu durumlar var, ancak her durumda böyle değil
CLI’ın token tasarrufu: gerçeklik ve sınırlar
Eğitim verisinde yer alan CLI araçları
jq, curl, git, grep, psql, aws gibi, LLM’nin eğitim veri setinde yer alan CLI yardımcı araçları ek talimat, şema veya bağlam olmadan ajan tarafından hemen kullanılabilir- MCP,
tools/list yanıtında araçları önceden bildirmek zorunda olduğu için, zaten bilinen CLI araçlarına kıyasla ek yük oluşturur
- Eğitim verisinde zaten bulunan CLI araçları, her zaman MCP’ye tercih edilerek kullanılmalıdır
Özel CLI’ların sınırları
- Özel (bespoke) CLI araçlarında LLM kullanım şeklini bilemez; bu nedenle
AGENTS.md veya README.md içinde açıklama sağlanmalıdır
/cli-tools dizini belirtilebilir ve açıklayıcı isimlere güvenilebilir; ancak ajanlar bu yaklaşımla sık sık hata yapar ve sonuçta daha fazla açıklama dokümanı gerekircurl gibi araçlar bile özel bir OpenAPI şemasını anlamak zorunda kaldığında token tasarrufu etkisini kaybeder
Zincirleme çıkarım ve dönüştürme
- CLI zincirleriyle veriyi alıp dönüştürerek bağlam penceresine giren veri miktarı azaltılabilir
- Ancak HTML, JSON, XML gibi biçimlendirilmiş içerikler DOM/CSS, JSONPath, XPath gibi seçicilerle de çıkarılabildiğinden, bu CLI’a özgü benzersiz bir avantaj değildir
Kademeli bağlam tüketimi
- MCP tüm araç setini ve şemayı baştan yüklerken, CLI
--help ile bağlamı kademeli olarak yükleyebilir
- Ancak özel CLI araçlarında ajanın birden çok tur boyunca help içeriğini keşfetmesi gerekir; sonuçta MCP şemasına benzer bilgileri yapısız biçimde yüklemiş olur
- Yeterince karmaşık akışlarda ajan sonunda ağacın büyük bölümünü yine keşfeder; dolayısıyla tasarruf etkisi sınırlı kalır
- Vercel’in araştırmasına göre, tüm dokümantasyon indeksinin
AGENTS.md içine yerleştirilmesi ajanların doküman kullanımını iyileştirdi; tüm şemanın önceden verilmesi doğru aracı seçme açısından daha avantajlı
- Anthropic’in şu anda 1 milyon token bağlam penceresi sunduğu düşünüldüğünde, token tasarrufunun hâlâ belirleyici bir argüman olup olmadığı tartışmalı
MCP’nin ikili doğası: stdio vs Streamable HTTP
stdio modunun sınırları
stdio modunda MCP sunucusu ajanla birlikte yerelde çalışır ve basit bir CLI yazmaya kıyasla gereksiz karmaşıklık ekler- Çoğu kullanım senaryosunda
stdio modundaki MCP gereksizdir
Streamable HTTP’nin dönüştürücü değeri
- Streamable HTTP taşıma biçimindeki MCP, aynı mantığın merkezi bir sunucuda çalışmasını sağlar; bu da organizasyon ve kurumsal benimsemede vibe coding’den ajan mühendisliğine geçişin temel unsurudur
- Influencer’ların çoğu bu iki mod arasındaki ayrımı yapamıyor
Merkezi MCP sunucularının avantajları
Zengin backend yetenekleri
- Merkezi sunucuda araçlar için Postgres instance’ı veya Apache AGE tabanlı Cypher grafik sorguları gibi zengin platform yetenekleri kullanılabilir
- Ajan tarafında yalnızca HTTP endpoint’i ve kimlik doğrulama token’ı tanımlamak yeterlidir; bu da dağıtımı kolaylaştırır
- SQLite gibi yerel veritabanları da mümkündür; ancak organizasyon genelinde durum paylaşımında sınırlıdır
Geçici (Ephemeral) ajan çalışma zamanları
- GitHub Actions gibi geçici çalışma zamanı ortamlarında, uzak MCP sunucusu üzerinden karmaşık backend gerektiren araçlar kurulum olmadan kullanılabilir
- Durumsuz (stateless) ortamlardaki durumlu (stateful) iş yükü yönetimi merkezi sunucuya devredilir
Kimlik doğrulama ve güvenlik
- CLI ile güvenli API’lere erişmek için tüm geliştiricilerin API anahtarlarına doğrudan erişmesi gerekir; bu da operasyon ekipleri için büyük yük oluşturur
- MCP sunucusunun arkasında merkezileştirildiğinde, geliştiriciler OAuth ile MCP sunucusuna kimlik doğrular ve hassas API anahtarları ile secret’lar sunucu arkasında kontrol edilir
- Bir ekip üyesi ayrıldığında yalnızca OAuth token’ını iptal etmek yeterlidir; ilgili kişi zaten diğer anahtarlara ve secret’lara hiçbir zaman erişmemiştir
Telemetri ve gözlemlenebilirlik
- Merkezi MCP sunucusunda OpenTelemetry trace’leri ve metrikleri standart araçlarla toplanabilir
- Hangi aracın etkili olduğu, hangi ajan çalışma zamanlarının kullanıldığı ve araçların nerede başarısız olduğu görülebilir
- CLI araçlarıyla da bu mümkündür; ancak yerel dağıtım tüketici tarafında güncelleme gerektirir ve her CLI aracı için telemetri iskeletinin yeniden kurulması gerekir
Standartlaştırılmış anında dağıtım ve otomatik güncellemeler
- Dağıtık araçlar (paketler) API sürüm uyumluluğu sorunları yaratırken, MCP Subscriptions ve Notifications aracılığıyla sunucunun istemciyi güncellemelerden haberdar etmesini sağlar
- MCP Prompts, sunucudan iletilen
SKILL.md karşılığıdır; MCP Resources ise sunucudan gelen /docs karşılığıdır
MCP Prompts ve Resources’un organizasyonel değeri
- Dinamik içerik: Depodaki
*.md dosyaları manuel güncelleme gerektiren statik dosyalardır; buna karşılık sunucu tabanlı prompt’lar ve resources, gerçek zamanlı olarak dinamik biçimde üretilebilir
- Yalnızca belirli bağlamlarda yararlı olan belgeler, fiyat verileri veya mevcut sistem durumu, araç çağrısı olmadan dinamik olarak enjekte edilebilir
- Otomatik tutarlılık güncellemeleri: Repo veya paket üzerinden dağıtılan
*.md dosyaları senkronizasyon gerektirirken, MCP prompt’larıyla iletildiğinde her zaman güncel kalır
- Üçüncü taraf resmi dokümantasyon bile sunucu üzerinden proxy edilirse depoya manuel kopyalama ve güncelleme gerekmez
- Organizasyon geneli bilgi paylaşımı: Güvenlik, telemetri best practice’leri, altyapı dağıtımında dikkat edilmesi gerekenler gibi organizasyonun tamamına uygulanan içerikler, tüm repository’lere, tüm workflow’lara ve tüm ajan frontend’lerine (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode vb.) tutarlı şekilde dağıtılabilir
- Mikroservis ortamlarında bir ekibin başka bir servisin dokümantasyonuna erişmesi veya servis ekibinin her dağıtımda dinamik olarak beceri sunması da mümkündür
- OpenCode, Claude Code CLI gibi ortamlarda MCP prompt’ları ve resources’un gerçekten çalıştığı örnekler görülüyor; yalnızca MCP istemci yapılandırmasıyla dağıtımdan sonra ek yönetim gerekmez
Sonuç: organizasyon seviyesinde MCP bugün de gelecekte de geçerli
- 6 ay önce MCP en sıcak başlıktı, bugün ise bağlam şişmesinin başlıca nedeni olmakla suçlanıyor; ancak özel CLI’ların benzer ödünleşimleri ve tuzakları çoğu zaman göz ardı ediliyor
- Ekipler vibe coding’den ajan mühendisliğine nasıl geçileceğini düşündüğünde, doğal olarak MCP’nin tasarımına ve misyonuna ulaşıyor
- Amazon AWS birimindeki yakın dönem örneğinde olduğu gibi (AI destekli değişiklikler için kıdemli mühendis onayı istenmesi), ekipler sonunda AI ajanlarının ürettiği yazılım sistemlerini işletmek ve bakımını yapmak zorunda kalacak
- Garry Tan ve Andrew Ng’nin tavsiyeleri kişilerin homojen ortamlarında geçerli olabilir; ancak farklı teknik seviye ve deneyime sahip ekiplerin tutarlı kaliteye yakınsaması gereken organizasyon ortamlarına doğrudan uygulanması zordur
- Güvenilir ve bakımı yapılabilir yazılım yayımlamak için tutarlılık, güvenlik, kalite ve doğruluğu güvence altına alan mühendislik disiplini gerekir; bu nedenle MCP bugün organizasyonlar ve enterprise için uygun araçtır
6 yorum
cli yerel bir araç, mcp ise bir sunucu; bu yüzden kullanım amaçları fazlasıyla farklı.
CLI'yi sunucuda çalıştırırsak aynı şey olmaz mı?
Edo Tensei MCP !
İlgili belge: MCP öldü. Yaşasın CLI
Mobil uygulamalarda da CLI araçlarının kullanılabilmesi için bir tür CLI sandbox özelliğine dair tartışmaların daha da ilerlemesi iyi olurdu; gerçekten mobille uyumluluk sağlamaya çalışınca sonuçta darboğazın sandboxing olduğu öne çıkan konu gibi görünüyor.
Hacker News görüşleri
Bu aralar çıkan AI entegrasyon özelliklerinin çoğunun tasarımının zayıf olduğunu düşünüyorum
En temel komutlar bile standartlaşmamışken, ortalık dokümantasyon yerine LLM’lerin ürettiği hatalı yardım metinleriyle dolu
Sonuçta “AI standardı” denilen şeylerin tekrar tekrar ortaya çıkıp kaybolacağını düşünüyorum. LLM’ler doğası gereği metin tabanlı olduğu için ağ protokolleri gibi hassas çalışmaları zor. Bu tür metin merkezli mühendislik en sonunda dengesiz bir soyutlama piramidi yaratıyor
AI araçları arasında en kullanışlı olanın, olasılıksal ajanları deterministik kapılarla sarmalayan yapı olduğunu düşünüyorum
Bu yüzden MCP’yi HTTP üzerinde kullanıyorum. Örneğin NanoClaw, WhatsApp mesajlarını deterministik olarak filtreleyip API anahtarları için proxy görevi görerek güvenliği artırıyor. Bu yapı AI’ı daha güvenilir hale getiriyor
Bu yapı güvenlik ve yönetilebilirlik açısından güçlü; ayrıca araç kataloğundan CLI’ı otomatik olarak üretebiliyorsunuz
Uygulama örneğini smith-gateway içinde görebilirsiniz
Açık kaynak çekirdeğe tenuo üzerinden bakabilirsiniz
MCP, AI’ın karar verme süreci ile sistemin deterministik yürütmesini net biçimde ayırıyor. Ben Claude Code ile MCP sunucularını birlikte kullanıyorum; yaratıcı problem çözmeyi AI yapıyor, yürütme ise öngörülebilir bir yol üzerinden ilerliyor, bu da çok verimli oluyor
MCP, AI uygulamaları arası iletişim için sabit bir protokol spesifikasyonu
Mevcut “entegrasyon” yaklaşımındaki gibi uygulamalar arası API’leri zorla birbirine bağlamak yerine, HTTP·FTP·SMTP gibi yeniden kullanılabilir bir iletişim soyutlaması sunuyor
AI’ın farklı servislerle etkileşime girmesi için böyle ortak bir dile ihtiyaç olduğunu düşünüyorum
Spesifikasyona modelcontextprotocol.io/specification/2025-11-25 adresinden bakabilirsiniz
Aslında ihtiyaç duyulan şey yeni bir protokol değil, kademeli olarak keşfedilebilir CLI veya API tanımları. İddiaya göre MCP, ilk dönem ajanların CLI çalıştıramadığı zamanlardan kalma geçici bir çözüm
Bu bakış açısına göre MCP sonuçta teknolojik olgunlaşmamışlığın geçici çözümü
MCP ilk çıktığında bana aşırı tasarlanmış bir çöp gibi göründüğü için ilgilenmemiştim
Hâlâ da pişman değilim. LangChain için de aynısı geçerli. Sırf popüler diye peşinden gitmek riskli
Çok küçük bir zaman yatırımıyla büyük verim almak mümkün
Bazen kaba saba araçlar, karmaşık entegrasyon sorunlarını basitleştirerek hayatta kalabiliyor
Bir şeyi baştan çirkin diye küçümserseniz, sonradan standart altyapıya dönüşebilecek bir fırsatı kaçırabilirsiniz
Aşırı tasarım değil, açık ve sezgisel bir yapı olarak görülüyor
Uzak MCP, kimlik doğrulamanın otomatik yürütülmesi sayesinde servislere erişimi kolaylaştırdığı için fena değil
Ama CLIs + Skills kombinasyonuna kıyasla bağlam yükü (context bloat) daha fazla ve Unix CLI’ın pipeline işleme ya da heredoc girişi gibi avantajlarını kaybettiriyor
CLI,
--helpçıktısından otomatik skill üretilebildiği için verimliMCP kalıcı bir süreç gerektirirken, CLI yalnızca gerektiğinde çalıştırılabiliyor
Ben hâlâ MCP’nin gereksiz bir katman olduğunu düşünüyorum
CLI > MCP olduğuna katılıyorum, ama dokümantasyon ve merkezileştirme avantajları başka yollarla da çözülebilir
Örneğin Skills kullanılırsa hem CLI hem de API için talimatlar tutulabilir ve bunlar yalnızca gerektiği anda yüklenir
Merkezi MCP’nin avantajları da aslında mevcut proxy’ler veya AWS SSO ile yeterince uygulanabilir
Sonuçta dokümantasyonu Skills ile yapmak, gerçek etkileşimi ise CLI veya REST API üzerinden yürütmek bana daha mantıklı geliyor
İddiaya göre Skills içeriği sonuçta bağlama eklenerek yük oluşturuyor ve proxy ile MCP’nin sunduğu işlevlerin tamamı ikame edilemiyor
MCP,
/komutu ve@referanslarıyla prompt ve kaynakları etkinleştirebiliyor; bu da proxy ile yapılamıyorİlgili demoları yazının sonundaki .gif’lerde ve MCP spesifikasyonunda görebilirsiniz
Bence MCP, tüketici odaklı ortamlar için daha uygun
Geliştirme ortamında karmaşık ve verimsiz olabilir, ama genel kullanıcılar MCP sayesinde modelin hangi işleri yapabildiğini daha kolay anlayabilir
Ortam kurulumu gerektirmez ve GUI içinde Siri veya Google Assistant benzeri yanıt görselleştirmeleri de sunulabilir
Kurum içinde geliştirici olmayan kullanıcılara AI araçları sunma açısından, merkezi MCP yaklaşımı bizim için çok faydalı oldu
Marka tonu, iç terminoloji, ortak veri erişimi ve alan bağlamı gibi unsurları tutarlı biçimde yönetebildik
MCP’nin resource method’ları üzerinden standartlaştırılmış “skills” sunup veri bağlantı kalıplarını kontrol ediyoruz
Yazının yazarı kavramlara farklı açılardan bakıyor ama sanki Token Notation (TOON) gibi mevcut kavramları bilmiyor
Sanki böyle bir şeyin var olmasını istiyormuş gibi bir izlenim veriyor
MCP’nin asıl sorunu bakım yükü
Örneğin GitHub entegrasyonu gerekiyorsa, zaten iyi belgelenmiş API yerine npm wrapper’ına bağımlı kalıyorsunuz
Ben doğrudan
ghCLI ya dacurlkullanıyorum. API değişirse ajan yeni dokümantasyonu okuyup uyum sağlıyorMCP’de ise aradaki wrapper güncellenene kadar beklemek gerekiyor
Güvenlik iddiası da çelişkili — ilk çıktığında kimlik doğrulama bile yoktu, şimdi ise güvenliği avantaj olarak öne çıkarıyor
Gerçekte chroot ya da scoped token gibi eski yöntemler bu sorunu zaten çözmüştü
MCP’nin gerçekten avantaj sağladığı tek alan geliştirici olmayanlar için OAuth akışı. Geliştirici araçları tarafında ise bence yapılması gereken şey sadece daha iyi CLI’lar üretmek