Ben hâlâ Skills yerine MCP’yi tercih ediyorum
(david.coffee)- MCP, LLM’in aracın iç yapısını bilmeden iş talep edebilmesini sağlayan API soyutlamasına dayalı standart bir arayüzdür; uzaktan kullanım ve otomatik güncellemeleri destekler
- Zero-Install yapısı, OAuth kimlik doğrulaması ve sandbox güvenliği sayesinde kurulum yükünü ve yetki sorunlarını azaltır, ayrıca her platformda aynı ortamı sunar
- Buna karşılık Skills, CLI kurulumu bağımlılığı, kimlik doğrulama ve dağıtım karmaşıklığı, platformlar arası uyumluluk sorunları gibi nedenlerle gerçek çalışma ortamında ciddi sürtünme yaratır
- Skills bilgi katmanı, MCP ise bağlantı katmanı olarak ayrılmalıdır; LLM dış sistemlerle etkileşime girdiğinde MCP, prosedürel bilgi aktarımında ise Skills kullanmak uygundur
- MCP Nest gibi bulut tünelleme servisleriyle yerel MCP sunucularına uzaktan erişilebilir; bu da standartlaştırılmış yapay zeka entegrasyon ortamı kurmanın temel unsurlarından biri olarak görülür
MCP'nin avantajları
- Model Context Protocol (MCP), LLM’in bir aracın iç işleyişini anlamasına gerek kalmadan yalnızca istek göndererek işi yapabilmesini sağlayan API soyutlama yapısını temel alır
- Örnek: LLM, DEVONthink ile etkileşime gireceğinde
devonthink.do_x()çağrısını yapar ve tüm işlemi MCP sunucusu üstlenir
- Örnek: LLM, DEVONthink ile etkileşime gireceğinde
- Zero-Install uzaktan kullanım mümkündür; istemcinin yalnızca MCP sunucusunun URL’sini belirtmesi yeterlidir ve ek kurulum olmadan hemen çalışır
- Otomatik güncelleme desteklenir; uzak MCP sunucusu yeni araçlar veya kaynaklarla güncellendiğinde tüm istemciler anında en güncel sürümü kullanabilir
- OAuth tabanlı kimlik doğrulama ile güvenlik güçlenir ve kullanıcının token’ları doğrudan yönetmesi gerekmez
- Taşınabilirliği yüksektir; Mac, mobil veya web fark etmeksizin her ortamdan aynı MCP sunucusu üzerinden erişim mümkündür
- Sandbox yapısı sayesinde yerel ortamda doğrudan çalıştırma yetkileri sınırlandırılır ve yalnızca kontrollü arayüzler açığa çıkarılır
- Akıllı arama ve otomatik güncelleme özellikleriyle yalnızca gerekli araçlar yüklenir; yerel kurulum yapılsa bile çalıştırma anında otomatik güncelleme mümkün olur
Skills'in sınırlamaları ve sürtünme noktaları
- Skills, LLM’e belirli bilgi veya kullanım biçimlerini öğretmede yararlı olsa da, gerçek işlemleri yürütürken CLI bağımlılığı sorun yaratır
- Çoğu Skill ayrı bir CLI kurulumu gerektirir; ancak ChatGPT, Perplexity ve Claude’un web sürümlerinde CLI çalıştırılamaz
- Bunun sonucunda şu sorunlar ortaya çıkar
- Dağıtım karmaşıklığı: CLI’nin binary, NPM, uv vb. yollarla dağıtılması ve yönetilmesi gerekir
- Gizli bilgi yönetimi sorunu: Kimlik doğrulama token’ları düz metin olarak
.envdosyasına kaydedilir ya da oturum sıfırlanınca kimlik doğrulama kaybolur - Ekosistem kopukluğu: Skill kurma ve güncelleme yöntemleri platformdan platforma değişir; bu da uyumluluk sorunlarına ve YAML ayrıştırma hatalarına yol açar
- Bağlam israfı: LLM’in yalnızca tek bir fonksiyon çağrısına ihtiyacı olsa bile tüm
SKILL.mddosyasını yüklemesi gerekir
- “Önce CLI kurun” yönergesini içeren bir Skill, gereksiz karmaşıklık ekler; bunun yerine uzak MCP kullanmak daha verimlidir
Uygun araç seçimi için ölçütler
- MCP ne zaman kullanılmalı: LLM, web siteleri, servisler ve uygulamalar gibi dış sistemlere bağlandığında standart arayüz olarak kullanılmalıdır
- Örnek: Google Calendar, kimlik doğrulama ve yürütmeyi OAuth tabanlı uzak MCP ile ele almalı; CLI kurulumu gerektirmemelidir
- Chrome, Hopper, Xcode ve Notion gibi araçların da kendi işlevlerini kontrol etmek için yerleşik MCP endpoint'leri sunması ideal olurdu
- Skills ne zaman kullanılmalı: Saf bilgi aktarımı ve bağlam sağlamaya odaklanmalıdır
- Zaten kurulu araçların (
curl,git,gh,gcloud) nasıl kullanılacağını öğretmek - Kurum içi terimleri, iş akışlarını ve yazım üslubunu standartlaştırmak
- PDF işleme veya gizli bilgi yönetimi (
fnoxkullanım şekli gibi) gibi prosedürel bilgi paylaşımı
- Zaten kurulu araçların (
- Skills, bilgi katmanı; MCP ise bağlantı katmanı olarak ayrılmalıdır
Connector'lar ve kılavuzlar
- Skills ile MCP’nin rollerini net biçimde ayırmak için, Skills’in LLM kılavuzu (LLM_MANUAL.md), MCP’nin ise connector olarak adlandırılması öneriliyor
- Gerçekte çalışan örnekler
- mcp-server-devonthink: LLM’in DEVONthink’i doğrudan kontrol edebilmesini sağlayan yerel MCP sunucusu
- microfn:
mcp.microfn.devüzerinde uzak MCP sunuyor - Kikuyo:
mcp.kikuyo.devüzerinde uzak MCP sunuyor - MCP Nest: Yerel MCP sunucusunu buluta tünelleyerek uzaktan erişilebilir kılan servis (
mcp.mcpnest.dev/mcp)
- Bazı projeler CLI için Skill de sunuyor; ancak MCP kullanımını açıklayan bir Skill daha faydalı
- Skill, MCP’nin işlevlerini, araç ilişkilerini ve ne zaman kullanılacağını anlatan bir bilgi katmanı gibi çalışır
- MCP ise gerçek bağlantı ve yürütmeden sorumludur
- Bu kombinasyon sayesinde LLM, tekrar tekrar deneme-yanılma yapmadan MCP’yi verimli şekilde kullanabilir
MCP ile Skill'in birlikte kullanımı
- MCP kullanırken karşılaşılan tarih biçimi hataları veya arama kısıtları gibi sezgisel olmayan kalıplar, Skill olarak düzenlenip yeniden kullanılabilir
- Bu şekilde oluşturulan Skill, MCP için bir cheat sheet görevi görür ve LLM’in gereksiz token harcamadan doğru çalışmasına yardımcı olur
.claude/skillsklasörü üzerinden projeye özel yapay zeka davranış yönergeleri korunabilir, sık kullanılan prosedürler ise dotfiles biçiminde yönetilebilir- Yapay zeka entegrasyonunun geleceği standartlaştırılmış arayüzlere (MCP) bağlıdır; CLI tabanlı parçalı yaklaşım ise kaçınılması gereken bir yöntemdir
- Skyscanner, Booking.com, Trip.com ve Agoda.com gibi büyük servislerin resmî MCP desteği sunması bekleniyor
MCP Nest tanıtımı
- MCP Nest, yalnızca yerelde çalışan MCP sunucularını (Fastmail, Gmail vb.) bulut tünelleme ile uzaktan erişilebilir hâle getiren bir servistir
- Claude, ChatGPT ve Perplexity gibi MCP destekli istemcilerde aynı şekilde kullanılabilir
- Yerel makineyi doğrudan açığa çıkarmadan tüm cihazlarda aynı MCP ortamını korumayı mümkün kılar
6 yorum
Bunlar zaten tamamen farklı iki şey, neden bu tür konuşmalar sürekli ortaya çıkıyor ki?
Yazının sonunda MCP Nest’in tanıtımını yapmam gerekiyor da... haha Bir şekilde karşılaştırma içeren iddialar epey ilgi görüyor galiba
Skills kılıç ustalığıdır, MCP ise kılıcın kendisidir.. Kullanım amaçları farklı ve ikisi de gerekli.
Skills ile MCP zaten farklı rollere sahip şeyler; bence bu tür yazılar yüzünden kafa karışıklığı sürekli devam ediyor.
Zaten sahtekar evangelistlerin cirit attığı fırtınalı yapay zeka sektöründe de
Hacker News yorumları
Vurgulamak istediğim nokta, kişisel tercihlerden çok LLM'in en iyi şekilde çalışması için gereken araç tasarımına odaklanmamız gerektiği
MCP aslında ek sürtünme yaratıyor. Örneğin gömülü sistemlerle çalışıyorsanız, LLM'in doğrudan debug, reset, emülatör çalıştırma gibi işleri yapabileceği CLI tabanlı bir izleme arayüzü oluşturmasını sağlayabilir, kullanımını da bir skill dosyasında belgelendirebilirsiniz
Basit işler için MCP gereksiz. Örneğin git ya da AWS maliyet hesaplama gibi konuları LLM zaten iyi ele alıyor. Sadece karmaşık sistemler için doğrudan araç üretip bunları belgelendirmek daha verimli
Tek seferlik işlerde CLI ya da API yeterli ama kalıcı erişim gerekiyorsa MCP sunucusu faydalı
İyi kurgulanmış bir MCP, prompt israfı olmadan ajana nasıl kullanılacağını öğretir. Skill dosyasıyla kalıcı erişimi taklit etmek verimsizdir. MCP, harici araçları ajan oturumuna entegre etmenin en etkili yoludur
.mdya da skill gibi farklı yerlere koymak yerine, otomatik öz değerlendirme döngüleriyle en uygun yere yerleştiren bir standarda ihtiyaç varJetBrains refactoring özelliklerini de scriptlerle değiştirdim; böylece oturum süresi 5 dakikadan 10 saniyeye indi
Hâlâ hiç MCP kullanmıyorum. REST + Swagger + codegen + Claude + skill kombinasyonu yeterli
Bu tartışma sonuçta bireysel geliştirici vs organizasyon ölçeğinde işbirliği meselesi
Tek başınıza hızlı bir geri bildirim döngüsü istiyorsanız CLI daha iyi, organizasyon düzeyinde denetim ve tutarlılık gerekiyorsa MCP daha uygun
Şu anda MCP bağlamı fazla tüketiyor ama bunun kademeli ifşa yöntemiyle iyileştirilmesi planlanıyor
Ben API'den çok mevcut CLI araçlarını olduğu gibi kullanan bir ajan istiyorum
Yerelde CLI kullanıyorken ayrıca MCP eklemek için bir neden yok. Uzak modeller de istemiyorum
API çağrısı gerekiyorsa skill yeterli
MCP ile Skill sıfır toplamlı bir ilişki içinde değil
MCP altyapı katmanında standart bir arayüz sunarken, Skill proje bazlı davranış bağlamını üstleniyor
İkisi birlikte kullanıldığında hem istikrar hem esneklik elde edilebilir
Tartışmaların çoğu yerelde coding agent çalıştıran kişiler etrafında dönüyor
Böyle ortamlarda Skill daha rahat ama genel kullanıcılar ChatGPT gibi cloud tabanlı sistemler kullanıyor
Bu durumda varsayılan seçenek MCP oluyor. Gücü kimlik doğrulama ve uzak erişimden geliyor
Sunucu açmak gerekiyor ve LLM için ekstra yük oluşturuyor. Skill ise API dokümantasyonunu LLM dostu şekilde encode ettiği için daha basit
agronomicyazım hatasınıergonomicdiye düzelten bir şaka da vardıBen Skill'i tercih ediyorum. Çünkü insanların kullandığı CLI araçlarını aynen yeniden kullanabiliyor
Skill, insanın okuyup yazabildiği bir doküman; LLM ile insan aynı araçları paylaşıyor
Buna karşılık MCP'de LLM'e özel yeni bir API yapmak gerekiyor ve dokümantasyonun da ayrıca yönetilmesi lazım
Skill yalnızca gerektiğinde yükleniyor, böylece bağlam temiz kalıyor
“Sadece Skill” diyenler daha çok teknik olmayan kişiler, “sadece CLI” diyenler ise daha çok bireysel geliştiriciler
MCP, enterprise ortamları için uygun. Kimlik doğrulama ve arayüzü standartlaştırıyor
aclitabanlı Skill daha stabildiMCP güncelleme ve dağıtımı kolaylaştırdığı için teknik olmayan kişiler için de erişilebilirliği yüksek
MCP sonuçta API'nin bir alt kümesini yapılandırmaktan ibaret
MCP sadece başka bir RPC protokolü ve kimlik doğrulama sorunu da hâlâ çözülmüş değil
Bence MCP, insanların irrasyonelliği yüzünden gerekli
Birçok organizasyon hâlâ API ya da CLI sunmuyor. MCP bu dijital kopukluğu kapatıyor
Şirket içi raporlama zincirleri ya da politik yapılar otomasyonu engelliyor; MCP bunların etrafından dolaşabiliyor
Skill'de tüm dokümanı bağlama koymak gerektiğinden context bloat sorunu var
MCP'de de benzeri var ama araç keşfiyle kademeli yükleme mümkün
Daha büyük sorun, MCP çıktısının doğrudan ajan bağlamına girmesi. MCP servislerini CLI üzerinden çağırırsanız filtreleme ya da cacheleme yapılabilir
Skill, sezgisel bilgiyi taşımak için iyi; MCP ise tekrarlanabilir otomasyon için daha uygun
LLM aynı script'i defalarca yazıyorsa, onu bir araca dönüştürüp sabitlemek daha verimli
Yani mümkün olduğunca çok şeyi scriptlerle ön işlemek asıl nokta
Küçük bir script ise doğrudan bağlama koyup “bunu kullan” demek yeterli olabilir