Ajana yetenek kazandırmanın üç yolu: MCP, beceriler ve CLI araçları

Bir ajan ancak ulaşabildiği şeyleri yapabilir. Bugün bu erişimin büyük kısmını üç mekanizma taşıyor: araçları bir protokol üzerinden tipli biçimde sunan MCP sunucuları; talimatları ve gerektiğinde betikleri paketleyen, ajanın yalnızca ilgili bir görevde yüklediği beceriler (skills); ve ajanın bir kabuk üzerinden çalıştırdığı sıradan komut satırı araçları. Ekipler bunları çoğu zaman birbirine rakip standartlar gibi tartışıyor. Oysa üçü, üç farklı soruya verilmiş üç ayrı yanıttır ve her biri yetkiyi başka bir yere taşır. Bu yazı her birinin ne olduğunu, ne zaman uyduğunu, izinlere ne yaptığını ve ajanın yetkisini fark ettirmeden genişletmeden nasıl birleştirileceğini anlatıyor.

Üç mekanizma, üç ayrı şey

MCP. Model Context Protocol, yapay zekâ uygulamalarını harici araçlara ve verilere bağlamak için geliştirilmiş açık bir protokoldür. Bir sunucu araçlarını ad, açıklama ve girdi şemasıyla tanımlar; bunlara ek olarak kaynaklar ve hazır istem şablonları da sunabilir. Kodlama ajanı ya da masaüstü asistanı gibi bir istemci bu araçları keşfeder ve model istediğinde çağırır. Sunucular yerelde standart girdi/çıktı üzerinden ya da uzakta HTTP üzerinden çalışır. Spesifikasyon modelcontextprotocol.io adresinde; kavramlar için MCP nedir yazısından başlayın.

Beceriler. Bir beceri, içinde SKILL.md dosyası bulunan bir klasördür: en üstte kısa bir ad ve açıklama, altında talimatlar, yanında da isteğe bağlı betikler, şablonlar ya da başvuru dosyaları. Ajan bir görev eşleşene kadar yalnızca açıklamayı görür, eşleşince gerisini okur. Beceriler yöntem bilgisi taşır: ekibinizin veritabanı göçünü nasıl yazdığı, bir sürümün adımları, haftalık raporun yapısı. Ayrıntılar ajan becerileri nedir yazısında.

CLI araçları. Komut satırı aracı, ajanın kabuk aracıyla çağırabildiği herhangi bir programdır: git, gh, kubectl, bir bulut sağlayıcısının CLI'ı, jq ya da kendi betikleriniz. Ajan bir komut yazar, metin çıktısını okur ve araçları birbirine zincirler; bir geliştiricinin yaptığına çok benzer biçimde.

Kabaca özetlersek: MCP bir arayüzdür, beceri bir kullanım kılavuzudur, CLI ise tezgâhta zaten duran bir alettir.

Hangisi ne zaman uyar

Seçimi iki pratik maliyet belirler. Birincisi bağlam. Birçok istemcide bağlı her MCP sunucusu, görev ihtiyaç duysun duymasın, araç tanımlarını modelin bağlamına yerleştirir; bir düzine sunucu bağladığınızda ajan dikkatini hiç kullanmayacağı açıklamalara harcar. Beceriler gerektiğinde yüklenecek şekilde tasarlanmıştır. CLI araçları çağrılana kadar hiçbir maliyet yaratmaz, ama ajanın önce --help çıktısını okuması gerekebilir. İkincisi çıktı. MCP araçları yapılandırılmış içerik döndürebilir; CLI'lar ise uzun ve gürültülü olabilen düz metin döndürür. --json gibi bayraklar ve bir satır sınırı, CLI çıktısını model için çok daha kullanışlı hâle getirir.

Yetki her durumda nereden gelir

Ekiplerin atladığı kısım burası. Seçtiğiniz mekanizma, ajanın izinlerinin gerçekte nereden geldiğini, dolayısıyla kısıtlamayı nerede yapmanız gerektiğini belirler.

• MCP: yetki, sunucunun elindeki kimlik bilgilerinden ve istemcinin onay ayarlarından gelir. Yönetici belirteciyle çalışan bir sunucu, araç açıklamaları ne kadar mütevazı görünürse görünsün, o belirtecin izin verdiği her şeyi yapabilir. Açıklamalar da modele giden girdinin parçasıdır; ele geçirilmiş ya da özensiz bir sunucu bunların içine talimat sızdırabilir. Uzak sunucular ayrıca bir ağ sınırı ve kendi yetkilendirme akışlarını getirir; bu dengeyi uzak ve yerel MCP sunucuları yazısı ele alıyor.
• Beceriler: bir beceri tek başına hiçbir yetki vermez; metindir. Ama ajanın neye kalkışacağını yönlendirir ve yanında gelen her betik, ajanın kabuğunun zaten sahip olduğu izinlerle çalışır. Topluluktan gelen bir beceri, bir yabancının yazdığı talimat ve koddur; onu bir bağımlılık gibi inceleyin. Nasıl yapılacağını topluluk becerilerini kurmadan önce incelemek yazısı anlatıyor.
• CLI araçları: bir CLI, çalıştığı ortamı devralır: açık oturumlar, bulut profilleri, SSH anahtarları, yapılandırma dosyalarındaki belirteçler. Terminaliniz canlı ortama giriş yapmışsa ajan da yapmıştır. Ajan çerçevesindeki komut izin listeleri ana denetimdir ve göründüklerinden daha kabadır: git komutuna izin vermek git push --force komutuna da izin vermek demektir.

Yetkiyi genişletmeden birleştirmek

Gerçek kurulumlar üçünü birden kullanır. Şu desenler sağlam kalır:

1. Beceri artı CLI. Beceri bir CLI'ın nasıl kullanılacağını anlatır: hangi alt komutlar yalnızca okur, hangi bayraklar zorunludur, ne asla çalıştırılmaz. Bunu ajan çerçevesindeki izin listesi uygular. Beceri kuralı tarif eder; kuralın kendisi izin listesidir. Paketleme adımları için bir CLI'ı ajan becerisine dönüştürmek yazısına bakın.
2. Beceri artı MCP. Beceri birkaç MCP aracını bir prosedüre dizer; örneğin talebi oku, dokümanlarda ara, yanıt taslağı yaz, incelemede dur.
3. CLI'ın önünde MCP. Bir CLI teslim edilemeyecek kadar güçlüyse, kabuğu açmak yerine birkaç işlemini deployment_status ve list_releases gibi dar MCP araçları olarak sarın. Amaç tam da bu daraltmadır.
4. Her sonuç doğuran eylem için tek yol. Aynı eyleme hem kişisel kimlik bilgilerinizle çalışan bir CLI'dan hem de kapsamı daraltılmış belirteçli bir MCP aracından ulaşılabiliyorsa, geçerli olan zayıf denetimdir. Fazladan yolu kapatın.

İlk desen için küçük bir örnek. Beceri dosyası:

---
name: release-notes
description: Draft release notes from merged pull requests. Use when asked to prepare notes for a release.
---
1. List merged pull requests since the last tag with
   gh pr list --state merged --json number,title,labels
2. Group them by label. Put unlabeled ones under Needs a label; do not guess.
3. Write the draft to RELEASE_NOTES.draft.md. Never create a tag or a release.

Bunu gerçekten uygulayan politika ise şöyle; belirli bir aracın sözdizimi değil, düz bir sözde yapılandırma olarak yazıldı:

allow: gh pr list, gh pr view, git log, git diff
ask:   git push, gh pr create
deny:  gh release create, gh repo delete

Uygulayabileceğiniz bir karar sırası

1. Zaten güvendiğiniz bir CLI bu işi düşük yetkili bir profille yapabiliyor mu? Oradan, bir izin listesinin arkasında başlayın.
2. İş muhakeme ya da ekibe özgü bir prosedür gerektiriyor mu? Mevcut araçları kopyalamak yerine onlara işaret eden kısa bir beceri yazın.
3. Kullanıcı bazında yetkilendirme, paylaşılan bir servis ya da katı argüman denetimi mi gerekiyor? Bir MCP sunucusu kullanın ya da kurun; işe yalnızca okuyan araçlarla başlayın.
4. Eylem bir şey gönderiyor, siliyor, dışa aktarıyor, zamanlıyor ya da para harcıyor mu? Hangi mekanizma taşırsa taşısın önüne bir insan kararı koyun.

GoCux araçları, becerileri ve MCP'yi nasıl ele alır

GoCux aynı çizgileri çeker. Müşteri CLI'ı, kendi makinenizdeki araçların ve izinlerin sahipliğini elinde tutar. MCP araçları sizin yerel, uyumlu istemcinizde çalışır; GoCux barındırılan bir MCP uç noktası sunmaz, işe yalnızca okuma erişimiyle başlamayı önerir ve yapılandırılmış bir sunucuyu her görev için onaylanmış değil, yalnızca kullanılabilir sayar. Kurulum MCP hızlı başlangıç sayfasında.

GoCux bir iş emrinin ihtiyaç duyduğu becerileri seçerken bile beceri bir talimat olarak kalır, asla izin yerine geçmez. Bir ajan kendi talimatlarında değişiklik önerirse, değişiklik geçerlilik kazanmadan önce incelemeye alınır. Dışarıya bir şey göndermek, silmek, veri dışa aktarmak ve başka bir ajanı işe koşmak dâhil yedi sonuç doğuran eylem sınıfı, ekipten birinin kararını bekler. Ayrıntılar için ajan becerileri dokümantasyonuna ve yetkiyi genişletmeden araç bağlamak notuna bakın.

Ajana yeni bir yetenek vermeden önce kontrol listesi

• Her yolun hangi kimlik bilgisini kullandığını biliyorsunuz ve bu, işi gören en dar kimlik bilgisi.
• Önce yalnızca okuyan araçlar geliyor; yazan araçlar tek tek ve bilinçli olarak ekleniyor.
• Topluluk becerileri ve MCP sunucuları bağımlılık gibi inceleniyor, sürümleri sabitleniyor.
• Bir becerinin tarif ettiği her kural, bir izin listesi ya da onay ayarıyla da uygulanıyor.
• Her sonuç doğuran eylemin tek bir yolu var ve o yol bir kararı bekliyor.
• Kayıtlar hangi aracın, hangi argümanlarla, kimin adına çalıştığını gösteriyor.
• Araç açıklamaları, beceri metinleri ve komut çıktıları yanlış ya da kötü niyetli olabilecek girdi olarak ele alınıyor.