6 puan yazan GN⁺ 20 일 전 | 6 yorum | WhatsApp'ta paylaş
  • 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
  • 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 .env dosyası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.md dosyası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 (fnox kullanım şekli gibi) gibi prosedürel bilgi paylaşımı
  • 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/skills klasö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

 
jujumilk3 20 일 전

Bunlar zaten tamamen farklı iki şey, neden bu tür konuşmalar sürekli ortaya çıkıyor ki?

 
xguru 20 일 전

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

 
jjw9512151 19 일 전

Skills kılıç ustalığıdır, MCP ise kılıcın kendisidir.. Kullanım amaçları farklı ve ikisi de gerekli.

 
ide127 20 일 전

Skills ile MCP zaten farklı rollere sahip şeyler; bence bu tür yazılar yüzünden kafa karışıklığı sürekli devam ediyor.

 
ide127 20 일 전

Zaten sahtekar evangelistlerin cirit attığı fırtınalı yapay zeka sektöründe de

 
GN⁺ 20 일 전
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

    • MCP tartışmasının fazla çok kavramı birbirine kattığını düşünüyorum. Asıl mesele oturum kalıcılığı
      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
    • MCP ile skill birbirini tamamlar. Bunları karşıt şeyler gibi görmek bir yanlış anlama
    • Mevcut LLM araç zinciri hâlâ standartlaşmamış bir geçiş dönemi gibi görünüyor. Bilgiyi .md ya da skill gibi farklı yerlere koymak yerine, otomatik öz değerlendirme döngüleriyle en uygun yere yerleştiren bir standarda ihtiyaç var
    • Ben de benzer bir yaklaşım kullanıyorum. CLI araçlarının çoğunu Claude doğrudan yaptı ve neredeyse hiç IDE kullanmıyorum
      JetBrains 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
    • MCP'nin avantajı yetki kontrolü. Örneğin AI'ın git'e yazma yetkisi olmamasını istiyorsanız, MCP ile maruz bırakılan kapsamı sınırlayabilirsiniz. Sadece READ_ONLY_SKILL bunun için yeterli değil
  • 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

    • Organizasyonlarda MCP erişim kontrolünün zor olması diye bir sorun var. İnsan yanlışlıkla sadece iki şeyi silebilir ama ajan bir anda binlercesini silebilir. CLI, erişim kapsamını sınırlayabildiği için daha güvenli
    • Bağlam israfı istemci implementasyonu sorunu. Kademeli yükleme, spesifikasyon değişmeden de mümkün
    • MCP ile CLI farklı amaçlara sahip araçlar ve birlikte kullanıldıklarında en güçlüler
  • 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

    • Ben de custom API çağırmak için doğrudan skill içine curl komutları koyuyorum. LLM bunu iyi yapıyor
    • Ama gizli anahtar yönetimi açısından MCP daha güvenli. Önce MCP sunucusunu ayağa kaldırırsanız anahtarlar ajan ortamına açığa çıkmaz
    • MCP, ajan ile dış dünya arasında bir güvenlik sınırı katmanı işlevi görüyor. Her zaman gerekli değil ama faydalı
    • Bazı ortamlarda LLM'in CLI erişim yetkisi olmayabilir. O zaman skill tabanlı CLI çağrıları işe yaramaz
    • Kimlik doğrulama (authn) ve yetkilendirme (authz) sorunları da var. MCP bunları middleware ile kontrol etmeyi mümkün kılıyor
  • 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

    • MCP sonuçta CLI'ı paketleyen bir yapı. Hatta MCP'nin bağlam overhead'i daha yüksek
    • Bazı ücretli MCP'ler gerçekten değerli. Örneğin web araması için bir MCP, doğrudan crawler çalıştırmaktan daha kullanışlı
    • Cloud üzerinde barındırılan ajanlarda Skill + MCP kombinasyonu temel yapı. Kimlik doğrulama ve bağımlılık yönetimi daha kolay
    • Yazının yazarı da bu kombinasyonu destekliyor. MCP'nin taşınabilirliği yüksek; ChatGPT, Claude, Perplexity gibi yerlerde aynı şekilde kullanılabiliyor
    • Skill, LLM tarafından yok sayılabilir ama MCP politikaları sunucu tarafında zorlayıcıdır
  • 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

    • Ama bazıları MCP'yi sadece gürültülü bir API wrapper'ı olarak görüyor
      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
    • “Kullanıcıların çoğu yerel ajan kullanmıyor” iddiasına kanıt gerektiğini söyleyenler de vardı
    • agronomic yazım hatasını ergonomic diye 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

    • Birçok kişi JIRA MCP'nin kararsızlığı yüzünden MCP'ye olumsuz bakıyor. acli tabanlı Skill daha stabildi
    • Ben şirket içi kullanım için doğrudan bir MCP kurdum. Google Workspace kimlik doğrulamasını bağladım ve Claude'un iç verileri sorgulamasını ya da uygulama dağıtmasını güvenli hale getirdim
      MCP güncelleme ve dağıtımı kolaylaştırdığı için teknik olmayan kişiler için de erişilebilirliği yüksek
    • Şirketlerin zaten kendi iç kimlik doğrulama sistemleri olduğu için CLI'ın daha iyi olduğu da savunuluyor
      MCP sonuçta API'nin bir alt kümesini yapılandırmaktan ibaret
    • MCP hızlıca ayağa kaldırılabiliyor. Codex → LiteLLM → VLLM → MCP şeklindeki kurulum birkaç dakikada tamamlanabiliyor
    • Ben mevcut SaaS sistemlerini legacy olarak görüyorum. Veriye erişmesi zor API'ler yerine yerel SQL DB çok daha verimli
      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

    • Ben de katılıyorum. Bir çalışma arkadaşının ajanı işbirliğini üstlenebilseydi, organizasyonların dijitalleşmesi çok daha kolay olurdu. MCP bu kablolama karmaşıklığını gizlediği için iyi
  • 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

    • Buna karşılık “o zaman neden doğrudan HTTP isteği kullanmıyoruz?” tepkisi de geldi
    • Yazının yazarı, en güncel MCP'nin bunu zaten araç keşfi tabanlı lazy loading ile çözdüğünü söylüyor. Claude Code, log taşmasını önlemek için sub-agent kullanıyor
    • Ben bunu yerel MCP'yi bir memory cache ile sarmalayarak çözdüm. Her araç çıktısına bir ID veriyorum, sonra diğer araçları o ID ile çağırıyorum. Token tasarrufu ve hız artışı sağlıyor
  • 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

    • Süreçlerin çoğu scriptlerle ön işlenmeli, LLM ise sadece planlama ve doğrulamaya dahil olmalı
      Yani mümkün olduğunca çok şeyi scriptlerle ön işlemek asıl nokta
    • Script'i doğrudan skill içine de koyabilirsiniz. Skill kod da içerebilir
    • Orijinal metnin yazarı, bunun AI tarafından değil, uçuş sırasında gerçek bir insan tarafından yazıldığını belirtti
    • Bazıları skill'i tekrar eden işler için de kullandığını söyledi; bunun üzerine MCP'nin API sözleşmesi açısından bir açıklama geldi
      Küçük bir script ise doğrudan bağlama koyup “bunu kullan” demek yeterli olabilir