Yapay zekâ destekli araçların hızla yaygınlaştığı günümüzde, geliştiriciler farklı yaklaşımlarla karşı karşıya kalıyor. Geçtiğimiz haftalarda, AI ajanlarına özel olarak tasarlanmış JSON odaklı, etkileşimsiz bir Jira komut satırı aracı geliştiren bir yazılım mühendisi, takım arkadaşlarıyla yaşadığı tartışmayı paylaştı. Projeyi basit bir CLI aracı olarak başlatan mühendis, takımındaki bazı üyelerin MCP sunucuları kullanmayı önerdiğini gördü. Peki, hangi yaklaşım gerçekten daha verimli?
CLI’ların Basitliği ve Gücü
Geliştirilen araca "kubectl’in Jira versiyonu" olarak adlandırılan bu CLI, sadece JSON çıktı veren ve AI ajanlarının veriyi doğrudan jq, grep ya da wc gibi araçlarla işlemesini sağlayan bir yapıya sahipti. Projenin temel amacı, etkileşimli menülerden veya karmaşık ASCII tablolarından kaçınarak, ajanların veriyi kolayca parse edebilmesiydi.
Ancak takım arkadaşları, bu yaklaşımın modern LLM çağına uygun olmadığını savunuyordu. Onlara göre, MCP sunucuları ajanlar için çok daha doğal bir çözümdü. Peki, neden?
MCP’nin Avantajları: Yapılandırılmış Veri ve Token Verimliliği
Takımın argümanları oldukça mantıklıydı. Öncelikle, MCP ekosisteminde Jira için zaten sunucular mevcuttu. Bu sunucular, LLM’lerin doğrudan kullanabileceği şekilde tasarlanmıştı. Bir ajan --help komutunu çalıştırıp komut parametrelerini tahmin etmek yerine, MCP sunucuları tarafından sunulan yapılandırılmış şemalara doğrudan erişebiliyordu. Ayrıca, HTTP ya da standart I/O üzerinden çalışan MCP hizmetlerine erişim, her komut için yeni bir işlem başlatmaktan çok daha hafifti.
Eğer ajanınız sürekli açık kalan bir sohbet oturumuna bağlıysa ya da komut satırı erişimi olmayan bir ortamda çalışıyorsa, MCP’nin sunduğu avantajlar tartışılmazdı. Özellikle token sayısını en aza indirmek için ideal bir çözümdü.
CLI’nın Dayanıklılığı: Token, Esneklik ve Hata Ayıklama
Ancak geliştirici, bu argümanlara rağmen CLI yaklaşımında ısrar ediyordu. Üç temel nedeni vardı:
1. MCP’nin "Şema Vergisi" Token Sayısını Artırıyor
MCP’nin en büyük dezavantajı, JSON şema yükünün aşırı token tüketmesiydi. Ajan her başladığında, MCP sunucusu tüm araçların adlarını, açıklamalarını ve parametrelerini içeren ağır bir JSON yükünü bağlam penceresine gönderiyordu. Eğer geliştirici, search_tool(query: string) gibi dinamik yetenekleri elle kodlamak istemiyorsa, 40-50 araç sunan bir sunucu, ajanın asıl görevi için tokenlarından ödün vermesine neden oluyordu.
CLI’larda ise durum farklıydı. LLM’ler komutların temel sözdizimini zaten biliyordu. Ajan sadece bir komut çalıştırıyor, küçük bir JSON yanıtı alıyor ve bağlam penceresinin %95’ini gerçek düşünme için kullanabiliyordu.
2. Unix Ekosistemi: Hazır Araçlar ve Komut Zincirleme
MCP sunucuları, ajanların isteklerini karşılamak için özel API uç noktaları gerektiriyordu. Örneğin, bir ajanın bir bilet aramasını, durumuna göre filtrelemesini ve sonuç sayısını saymasını istiyorsanız, bunu destekleyen özel bir uç nokta oluşturmanız gerekiyordu.
CLI’larda ise Unix felsefesi devreye giriyordu. Ajan, standart kabuk komutlarını zincirleyerek sorunu çözebiliyordu:
jira search jql "assignee = currentUser()" | jq -r '.[].key' | wc -lÖzel API uç noktaları yazmaya gerek yoktu. Terminal, zaten ajanların bildiği bir araç setiydi.
3. Hata Ayıklama ve Geçmiş Yönetimi
MCP sunucularında bir hata meydana geldiğinde, sorunu çözmek zorlaşabiliyordu. Geliştirici, JSON-RPC taşıma katmanındaki logları incelemek, istemci durumunu analiz etmek ve hata ayıklama sürecini karmaşıklaştıran unsurları takip etmek zorunda kalıyordu.
CLI’larda ise durum çok daha basitti. Geliştirici kabuk geçmişine bakıyor, ajanın çalıştırmaya çalıştığı tam komut dizesini kopyalıyor ve sorunu birebir yeniden oluşturabiliyordu. Ayrıca, güvenlik için Kubernetes tarzı yerel bağlam yönetimi de eklenmişti:
jira context set --project PROJBu komut, varsayılan projeyi yerel bir dosyaya kaydederek, ajanın çalışma alanını sınırlıyor ve güvenliği artırıyordu.
Peki, Hangi Yaklaşım Geleceğe Dönük?
Geliştirici ve takım arkadaşları arasındaki tartışma, CLI’ların geçici bir çözüm mü yoksa kalıcı bir tercih mi olduğu sorusunu gündeme getiriyor. Bazıları, MCP’nin bağlam yönetimini geliştireceğini ve ajanların daha akıllı hale geleceğini savunurken, diğerleri basit API görevleri için daemon çalıştırmaya gerek olmadığını düşünüyor.
Kendi Yaklaşımınızı Belirleyin
- CLI mı, MCP mi? İş akışlarınız için hangi yaklaşımı tercih ediyorsunuz?
- Token optimizasyonu: MCP’nin şema yüküyle karşılaştınız mı? Bu sorunu nasıl çözdünüz?
- Hibrit çözümler: Yerel geliştirme için CLI’ları, üretimde ise MCP’yi kullanmayı düşündünüz mü?
Geliştirilen @888aaen/jira-cli aracı, hem geliştiricilerin hem de AI ajanlarının kullanabileceği şekilde tasarlanmıştı. Aracı kurmak için:
npm install -g @888aaen/jira-cli
npx skills@latest add AndersSpringborg/jira-agent-cliBu komutlar, CLI’nın yerel olarak kurulmasını ve AI ajanlarının aracı kullanabilmesi için gerekli yetenek dosyasının eklenmesini sağlıyordu.
Teknolojinin hızla geliştiği bu dönemde, hem basitlik hem de modernlik arasında doğru dengeyi bulmak kritik önem taşıyor. Hangisi sizin için daha uygun? CLI’ların sağlamlığı mı, yoksa MCP’nin yapılandırılmış dünyası mı?
Yapay zeka özeti
Yapay zekâ ajanlarına özel Jira CLI ile MCP sunucuları arasındaki avantajları karşılaştırın. Token optimizasyonu, esneklik ve hata ayıklama gibi kritik faktörleri keşfedin.