MCP öldü mü?

(quandri.io)

1 puan yazan GN⁺ 5 시간 전 | 2 yorum | WhatsApp'ta paylaş

MCP, LLM’leri harici araçlara bağlar; ancak geliştirme iş akışlarında bağlam maliyeti, operasyonel kararlılık ve CLI/API tekrarları büyük bir yük olarak ortaya çıkıyor
Quandri’nin ölçümüne göre Linear, Notion, Slack ve Postgres için 77 araç tanımı yaklaşık 21.077 token tutuyor; bu da Claude 200K bağlamının %10,5’ine denk geliyor
Linear issue sorgulamada MCP yaklaşımı 42 araç tanımını her zaman taşıdığı için, yaklaşık 200 tokenlık CLI yaklaşımına kıyasla çok daha yüksek olan yaklaşık 12.957 token tüketiyor
MCP’ye ayrı sunucu süreçleri ile kimlik doğrulama, başlatma, çakışmalar ve harici gidiş-dönüş gecikmesi eklenirken, CLI/API terminalde yeniden üretmesi, hata ayıklaması ve birleştirmesi kolay bir yapı sunuyor
Quandri, mevcut CLI’leri Skills ile sararak yaklaşık 21K tokenlık alan kazandı ve MCP’yi yalnızca CLI olmayan durumlarda veya ekip düzeyinde yetki kontrolü gerektiğinde kullanıyor

MCP’nin ortaya çıkardığı temel maliyetler

MCP(Model Context Protocol), LLM’leri GitHub, Linear, Notion, Slack gibi harici araçlara bağlar; ancak gerçek geliştirme iş akışlarında bağlam kullanımı, operasyonel kararlılık ve mevcut CLI/API’lerle çakışma başlıca sorunlar haline geliyor
2024 sonlarında yayımlandıktan sonra “yapay zeka ekosisteminin USB-C’si” diye anılsa da, bunu günlük kullanan geliştiriciler için önce başka maliyetler görünür hale geldi
Claude Code’a ölçümden sonra Tool Search with Deferred Loading eklendi; bu sayede MCP araç şemaları gerektiğinde yükleniyor ve bağlam kullanımı %85’ten fazla azaltılıyor
Bugün Claude Code’da bağlam şişmesi sorunu önemli ölçüde hafiflemiş olsa da, performans, hata ayıklama ve mimari sorunlar hâlâ duruyor

Bağlam penceresini büyük ölçüde tüketiyor

Bağlam penceresi, LLM’in iş için kullandığı alandır; MCP sunucuları bağlandığında asıl iş içeriğinden çok araç tanımları bu alanın büyük bölümünü kaplayabiliyor
Quandri ortamında bağlı MCP sunucularının gerçek araç tanımları çıkarılıp ölçüldüğünde, 4 sunucu birlikte bağlandığında yalnızca araç tanımları bağlam penceresinin %10,5’ini kullanıyor
Araç tanımı boyutları:
- Linear: 42 araç, yaklaşık 51.229 karakter, yaklaşık 12.807 token
- Notion: 14 araç, yaklaşık 16.156 karakter, yaklaşık 4.039 token
- Slack: 12 araç, yaklaşık 15.168 karakter, yaklaşık 3.792 token
- Postgres: 9 araç, yaklaşık 1.755 karakter, yaklaşık 438 token
- Toplam: 77 araç, yaklaşık 84.308 karakter, yaklaşık 21.077 token
Modele göre bağlam kullanımı:
- Claude 200K bağlamında araç tanımları %10,5 yer kaplıyor
- GPT-4o 128K bağlamında araç tanımları %16,5 yer kaplıyor
Yalnızca Linear bile 42 araç tanımını her zaman yüklüyor ve yaklaşık 12.800’den fazla token kaplıyor; pratikte sadece get_issue ve save_issue kullanılsa bile tüm tanımlar birlikte yükleniyor
Büyük araç tanımı örnekleri:
- linear/save_issue: 2.479 karakter, yaklaşık 619 token
- slack/search_public: 1.614 karakter, yaklaşık 403 token
- linear/list_issues: 1.588 karakter, yaklaşık 397 token
- notion/fetch: 1.379 karakter, yaklaşık 344 token
- slack/send_message: 1.248 karakter, yaklaşık 312 token

Operasyonel kararlılık ve performans yükü

MCP, ayrı bir sürecin başlatılıp ayakta tutulmasını gerektirdiği için başlatma hataları ve tekrarlanan kimlik doğrulama sorunları ortaya çıkabiliyor
Her araç çağrısında harici sunucuya gidiş-dönüş gerektiğinden yapay zeka yanıt hızı yavaşlıyor
MCP sunucu süreci çökerse oturumun ortasında araçlar kaybolabiliyor
Her aracın gerçekte hangi yetkilere sahip olduğu belirsiz olduğundan yetki görünürlüğü düşük kalıyor
MCP is dead. Long live the CLI içindeki Jira MCP kıyaslamasında, doğrudan REST API çağrısına göre MCP çağrı başına 3 kat daha yavaştı; başlatmayı da içeren ilk çağrı ise 9,4 kat daha yavaştı
Bu performans farkı yalnızca Jira’ya özgü değil; LLM ile temel API arasına MCP sunucusu şeklinde bir süreç katmanı eklenmesinden kaynaklanıyor
Aynı ek yük, Quandri yığınındaki Linear, Notion ve Slack sunucuları için de geçerli

Mevcut CLI/API ile çakışıyor

CLI/API, insanların ve LLM’lerin aynı komutları kullanmasına izin verirken MCP yalnızca LLM diyaloğunun içinde var oluyor
CLI/API, pipe, jq, grep ile serbestçe birleştirilebilir; MCP ise sunucunun döndürdüğü biçime bağlı kalıyor
CLI/API terminalde anında yeniden üretilebilir ve hata ayıklanabilir; MCP ise yalnızca konuşma bağlamı içinde yeniden üretilebiliyor
LLM’ler CLI/API kullanımını zaten man page’ler ve StackOverflow üzerinden öğrenmiş durumda; MCP ise ayrı araç tanımları gerektiriyor
CLI/API çoğu zaman zaten kurulu gelirken, MCP ek olarak sunucu kurulumu, kimlik doğrulama ve süreç yönetimi gerektiriyor

Linear issue sorgulamanın token maliyeti

Aynı Linear issue sorgulanırken MCP yaklaşımı, CLI yaklaşımına göre yaklaşık 65 kat daha fazla token tüketiyor
CLI yaklaşımı yaklaşık 200 token kullanıyor:
- curl komut istemi: yaklaşık 50 token
- Yanıt: yaklaşık 150 token
MCP yaklaşımı yaklaşık 12.957 token kullanıyor:
- Her zaman yüklenen 42 Linear araç tanımı: yaklaşık 12.807 token
- Araç çağrısı ve yanıt: yaklaşık 150 token
CLI örneği, Linear GraphQL API’sini doğrudan çağırıyor:

curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \  
  -H "Content-Type: application/json" \  
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \  
  https://api.linear.app/graphql

Alternatif: CLI öncelikli strateji ve Skills

CLI → API → dokümantasyon sırasıyla sunulan yaklaşım daha hafif ve daha doğrudan
LLM’ler CLI kullanımını zaten man page’lerden ve StackOverflow’dan öğrendiği için ayrı araç tanımlarını sürekli bağlamda taşımaya gerek kalmıyor
Mevcut CLI doğrudan kullanıldığında araç tanımları için bağlam harcanmıyor; ayrıca insanlar ve yapay zeka aynı arayüzü kullandığı için hata ayıklama kolaylaşıyor
Boru hatları sayesinde başka komutlarla serbestçe birleştirilebiliyor
MCP “masadaki tüm menüyü peşinen açmak” gibiyse, Skills “yalnızca gereken kitabı görevliye istemek” yaklaşımına daha yakın
MCP bağlantı sırasında tüm araç tanımlarını yüklüyor ve bağlamı sürekli işgal ediyor; Skills ise yalnızca gerektiğinde yükleniyor ve yalnızca kullanım sırasında bağlam kaplıyor
Sunucu sayısı arttıkça MCP’nin bağlam baskısı büyürken, Skills sahip olunan skill sayısı kadar sürekli bağlam işgal etmiyor
Buradaki kilit nokta, CLI kullanım yönergelerini Skills içine koymak; bu da CLI öncelikli stratejiyle birleştiğinde en verimli yaklaşımı oluşturuyor
Linear Skill örneği yalnızca API URL’sini, kimlik doğrulama yöntemini, issue sorgulamak için curl komutunu, GraphQL arama yöntemini ve JSON’un jq ile ayrıştırılacağını içeriyor:

# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq

Bu yaklaşımda LLM, ilgili skill çağrıldığında yalnızca bu içeriği bağlama yüklüyor
42 Linear araç tanımını sürekli taşımak yerine, yalnızca gerekli CLI komutları yükleniyor

MCP’nin hâlâ geçerli olduğu durumlar

Servisin bir CLI’si yoksa, MCP tek bağlantı yöntemi olabilir
Terminal kullanmayan geliştirici olmayan kullanıcılar için MCP daha erişilebilir olabilir
Basit istek-yanıt modelinin ötesine geçen gerçek zamanlı çift yönlü iletişimde MCP uygun olabilir

Veritabanı erişiminde seçim ölçütleri

Veritabanı erişimi sonuçta sorgu çalıştırmaktır ve LLM’ler SQL ile MongoDB sorgularını zaten iyi biliyor
DB bilgileri ile CLI kullanımını bir Skill içine koyup şemayı verirseniz, LLM MCP olmadan da sorgu yazabilir
Postgres Skill örneği yalnızca host’u, tablo şemasını ve psql CLI kullanımını içeriyor:

# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."

Veritabanlarında MCP’nin bazı avantajları da var:
- Sorgu güvenliği: MCP sunucusu salt okunur modu zorunlu kılabilir ve tehlikeli sorguları sunucu seviyesinde engelleyebilir
- Kimlik bilgilerini koruma: CLI yaklaşımında bağlantı dizesi istemde görünebilirken, MCP sunucusu kimlik bilgilerini içeride yönetebilir
Yerel geliştirme veya kişisel DB’lerde Skills + CLI daha hafif, daha hızlı ve hatalardan toparlanması daha kolay bir çözüm
Üretim veritabanları veya paylaşımlı ekip ortamlarında ise MCP daha uygun olabilir; sunucu seviyesinde sorgu doğrulama ve erişim kontrolü gibi güvenlik önlemleri önem taşır
Geliştiricilerin çoğu günlük iş akışında MCP kolayca aşırı tasarlanmış bir çözüme dönüşebilir

Quandri’nin kullanım biçimi

Quandri, hizmete göre Bash + CLI, Skills ve MCP’yi birlikte kullanıyor
gh, psql, aws gibi her gün kullanılan araçlarda Bash + CLI tercih ediliyor:
- Bağlam maliyeti yok
- Esneklik yüksek
- Terminalde anında hata ayıklama mümkün
Commit yazma ve PR inceleme gibi tekrarlayan çok adımlı iş akışlarında Skills kullanılıyor:
- Yalnızca çağrıldığında yükleniyor
Slack, Linear, Notion gibi güçlü bir CLI’si olmayan servislerde MCP kullanılıyor
Üretim veritabanı erişimi gibi ekip düzeyinde kimlik doğrulama veya yetki kapsamının önemli olduğu durumlarda da MCP kullanılıyor
Zaten bir CLI varsa ve yerel kimlik doğrulama mümkünse, genellikle en hafif yaklaşım bu oluyor
Servisin CLI’si yoksa veya ekip genelinde tutarlı kimlik doğrulama gerekiyorsa MCP değer kazanıyor

Sonuç ve ölçüm yöntemi

Her şeyi birbirine bağlamaktan daha önemli olan şey iyi öğretmek
Quandri, mevcut CLI’leri saran Skills ile MCP sunucularının yerini alarak yaklaşık 21K tokenlık bağlam alanı kazandı
Günlük iş akışlarında başlatma hataları ortadan kalktı ve hata ayıklama terminalde kaldı
Gerekli araçları yalnızca gerektiğinde, CLI yönergeleriyle birlikte yüklemek daha verimli bir yaklaşım
MCP gelecekte bu sorunları çözecek şekilde evrilebilir; ancak bugünün koşullarında Skills daha iyi bir seçenek olarak öne çıkıyor
Ölçüm yöntemi:
- Claude Code ortamında gerçekten yüklenen MCP sunucularının her bir araç JSON şeması çıkarıldı
- Boyut, araç adı, açıklama ve parametreler temel alınarak ölçüldü
- Token tahmini için yaklaşık her 4 karaktere 1 token sezgisel kuralı kullanıldı
- Toplam sunucu tahminleri, örnek araçların ortalamasından dışa vurum yapılarak hesaplandı

Seçilmiş teknoloji başlıklarını almaya devam etmek ister misiniz? Telegram kanalını takip edin. @GeekNewsTR

2 yorum

aer0700 3 시간 전

Bence insan kendi durumuna uygun teknolojiyi seçse yeter. Öldü demek zor; zaten hâlihazırda fazlasıyla kullanılıyor.

GN⁺ 5 시간 전

Hacker News görüşleri

OpenAI’de ChatGPT App Store, Codex eklentileri ve genel olarak MCP’den sorumlu ekibe liderlik ediyorum; “MCP öldü” diyen yazıların gözden kaçırdığı nokta, MCP’nin bir taşıma protokolü olarak kullanılıp kullanılmadığının fiilen çok da önemli olmaması
MCP’nin ölmemesinin nedeni, dünyadaki neredeyse tüm şirketlerin MCP sunucuları yapıyor olması ve bunu onlarla doğrudan temas ettiğimiz için biliyor olmamız
Bu şirketlerin çoğunda CLI yok, hatta dış API bile yok; ama MCP sunucusu yapıyorlar
İçeride tüm MCP sunucularını CLI’a dönüştürebilir, kod modunu kullanabilir ya da araç keşfini uygulayabiliriz; ama bunlar sadece uygulama ayrıntıları ve asıl mesele yapay zeka ajanlarının normalde erişemeyeceği servislere erişebilmesi
Modelin doğrudan konuştuğu iletişim katmanı olarak MCP’nin ölüp ölmediği tartışmalı olabilir ama protokol olarak MCP’nin öldüğü kesinlikle söylenemez
Codex uygulamasının bilgisayar/tarayıcı kullanımı özelliği yüzünden bu iddia eskisine göre zayıfladı; henüz denemediyseniz gerçekten şaşırtıcı düzeyde
- MCP’nin büyük olasılıkla öleceğini düşünüyorum
  En büyük neden, gerçek uygulama API, web ya da CLI ne olursa olsun bunun üstüne senkronizasyonu bozulabilecek bir katman ve bir insan daha eklemesi
  Yapay zeka, insanların eriştiği, bildiği ve kullandığı şeyden farklı bir protokol ya da talimat kümesi kullanmamalı
  Şu anda şirketler moda olduğu için MCP sunucusu açığa çıkarmak istiyor ama gerçekte yapılan şey, Claude ile mevcut API’nin üstüne MCP sunucusu yapmak ve ara sıra herkese açık belgelere uyacak şekilde tekrar güncellettirmek
  API dokümantasyonu zaten açık ve Claude Code da internetteki herkese açık dokümanları okuyup MCP sunucusu oluşturduğuna göre, MCP mevcut model sınırlamalarına karşı geçici bir dolambaçlı çözüm gibi geliyor
- MCP sonuçta “büyük dil modellerinin kullanabildiği API” için bir marka adına daha yakın
  Bunun sonucu olarak teknik odaklı olmayan şirketler bile ajan çağında araçlarının eski görünmemesi için API yapıyor
  Hedefin kendisini destekliyorum ama bunun için protokol olarak bunu seçer miyim, o ayrı konu; yine de insanların duyduğu ve gerçekten kullandığı bir protokol haline geldi
- “Dünyadaki neredeyse tüm şirketler MCP sunucusu yapıyor” sözü tam bir echo chamber gibi geliyor
- MCP gerçekte var olmayan bir problemi çözerken hâlâ kıymetli olan bağlam penceresini tüketiyor
  MCP olmadan servislerin ajanlara erişilemeyeceği iddiası, en iyi ihtimalle yanıltıcı; makalede dendiği gibi komut satırı araçları ve onların girdi/çıktılarıyla da erişim mümkün
  Sırf teknik açıdan bakıldığında bile MCP, komut satırı araçlarına kıyasla birleştirilebilirlik açısından daha zayıf ve birleştirilebilirliği önemsemeyen tarafın sonunda bunun bedelini ödeyeceğini düşünüyorum
  Düz konuşmak gerekirse burada yatırım yanlılığı var ve sayısız şirkete MCP satıyor olmak bu yanlılığı çürütmüyor
  Sadece Microsoft’a bakınca bile fayda ve tekniğin ne kadar derine gömüldüğüyle çok ilgisi olmadığı, hatta bazılarına göre tam tersinin doğru olduğu görülüyor
  OpenAI’nin şu anda MCP’yi bu kadar zorlamasında da büyük ölçüde kurumsal etkenler olduğundan şüpheleniyorum; içeriden bakınca bunu görmek zor olabilir
- CLI olmayan yerlerde MCP yapılıyor olması epey kaygı verici
  Mevcut CLI işlevlerini daha iyi ajan entegrasyonu için kopyalamakla, herkesi daha sonra daha iyi olduğuna karar verilebilecek bir spesifikasyona bağlayan tek arayüz haline getirmek aynı şey değil
  Böyle olursa ileride MCP borcu ödemek gerekir ve sonunda hiç yapmamak daha ucuz olabilir
Bu yazı yapay zeka tarafından yazılmış gibi duruyor
MCP özünde, birkaç özel alan içermesi gereken bir JSON-RPC’ye yakın
JSON-RPC ile ilgili kaygılar var ama büyük dil modellerinin entegre olabileceği bir servis keşif katmanı gerekli
Bunun web sitelerinde, masaüstü uygulamalarında, arka uç servislerinde ve başka yerlerde mümkün olması gerekiyor; CLI bu tür sistemlerle buluşma noktalarından sadece biri
MCP’nin yerine ne konursa konsun, iletişim protokolünü ya da araç keşif alanlarını farklı tanımlasa bile muhtemelen benzer bir şekle bürünecek
- MCP ile ilgili bir şey okuduğum her seferinde internetin ya da HN’in tamamı topluca kriz geçiriyormuş gibi geliyor
  API’nin MCP’den daha iyi olduğu söyleniyor ama MCP zaten sadece, yapay zekanın nasıl kullanılacağını keşfedebilmesi için biraz yönlendirme eklenmiş bir API
  Bir de CLI kullanalım deniyor ama bunun tam olarak ne anlama geldiğini bilmiyorum
  Büyük dil modellerinin ffmpeg gibi yaygın CLI araçlarını iyi kullanabilmesi, o bilginin ağırlıklarının içine işlemiş olmasından kaynaklanıyor
  Yeni bir CLI aracı yaparsanız yine de yapay zekaya nasıl kullanılacağını öğretmeniz gerekir; bu “öğretme” kısmını sunucudan vermek istiyorsanız MCP, yerelde statik biçimde tutmak istiyorsanız skill olur
  Bu kadar basit bir kavram etrafında neden bu kadar tartışma döndüğünü anlamıyorum
- Sorun şu ki MCP bağlamı nispeten kalıcı biçimde işgal ediyor ve bununla birlikte temiz bir kurma/kaldırma ve keşif sistemi gelmiyor
  Skill’lerin hepsi MCP tabanlı olmalı, yalnızca gerektiğinde çağrılmalı ve insanlar ile yapay zeka tarafından kolayca yönetilip keşfedilebilirse ancak o zaman düzgün çalışır
  Gerçek uygulama alanına bakınca ilk kapsam fazla dardı ama bunun üstüne bir şey konulursa hâlâ yeniden canlanabilir
“Sorun 1: bağlam penceresini yutuyor” iddiası konusunda, sırasıyla linearcli --help, notioncli --help, slackcli --help çalıştırmaktan ne farkı olduğunu anlamıyorum
Hatta MCP’de yürütme ortamı her aracın yalnızca başlığını bağlama koyabilir ve tüm belgeyi de gerektiğinde MCP sunucusu ve araç bazında ekleyebilir
CLI ile aynı etkiyi elde etmek için tüm CLI’ların --short-descr gibi bir komut sunması gerekir
“Sorun 2: düşük operasyonel güvenilirlik” de araç REST API kullanıyorsa protokol benzer olduğu için MCP’nin daha yavaş olması için bir neden yok
Yavaşsa, bunun nedeni muhtemelen API’nin üstüne MCP eklenmesi ve uzak bir veri merkezindeki taşeron sunucuya kurulmuş olması gibi uygulama sorunlarıdır
MCP sunucularının çoğu berbat olabilir ama bu protokol değil, sektör sorunudur
“Sorun 3: mevcut CLI/API ile çakışıyor” ifadesi, zaten bir CLI aracı varsa doğru; SQL MCP sunucusu ya da curl MCP de token israfı gibi görünüyor
Ama çoğu organizasyonda CLI yoktur; varsa da bunlar büyük dil modelleri için değil, programların kullanması için tasarlanmış API’lardır
“Önce CLI → API → dokümantasyon sırasıyla sunun” demek, yavaş ve israfçı bir web sitesi yerine şirketin önce masaüstü yerel istemcisiyle mobil yerel istemcisini sunmasını istemek gibi geliyor
- Bu alanı derinlemesine incelemedim ama en yeni Claude Code sürümü dışında MCP’nin bağlama önceden yüklendiğini biliyorum
  Sık gerekmiyorsa kapatıp ihtiyaç olduğunda yeniden açmak gerekiyor
  Beceri dosyasına kullanım örnekleri koyarsanız ilk --help çağrısını da azaltabilirsiniz; CLI ise ayrı bağlama sahip alt ajan başlatıp yalnızca sonucu geri almak da kolay görünüyor
Yazıda tarih yok ama gecikmeli araç yüklemenin yazı yazıldıktan sonra çıkan yeni bir güncelleme olduğu söyleniyor
Oysa gecikmeli araç yükleme 2025 Kasım’ında eklendi: https://www.anthropic.com/engineering/advanced-tool-use
Dolayısıyla bu sayılar en az 7 aylık ve bunun neden şimdi paylaşıldığını anlamıyorum
- Bunun hâlâ tartışılıyor olması garip
  Gecikmeli araç yükleme, büyük bağlam ve prompt caching yüzünden 2026, 2025’ten tamamen farklı hale geldi
  CLI’nin token tasarrufu sağladığı tartışması da ilk adım --help çalıştırmaksa çöküyor
  Çağrı yöntemi parametre hafızasında değilse sonuçta bağlamın içinde olmak zorunda olması sorunu aynen kalıyor
- Bundan da eski bir yazı gibi duruyor ve sanki GPT-4o en güncel modelmiş gibi ima ediyor
- Gecikmeli araç yükleme MCP’nin bir parçası değil
  Bu, diğer büyük dil modeli API’lerinin çoğunun desteklemediği Claude API’ye özgü bir parametre
- Yazı 29 Mayıs 2026 tarihli ve bu güncellemenin yazıdan sonraki “yakın tarihli” değişim olduğunu söylemeleri, kendilerini daha iyi göstermek için söylenmiş bir yalan
MCP’nin organizasyon düzeyinde, iç ajan araçlarını kullanan teknik olmayan çalışanlara kurum içi yardımcı API’lere birleşik ve güvenli erişim sağlamak gerektiğinde çok uygun olduğunu anlatan harika bir yazı vardı sanırım
İş akışları beceri olarak kodlanıp örnekler arasında paylaşılırken, bağlam farkındalığı gerektiren API erişimini MCP üstleniyordu
- Bu yazı mı? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- Öyleyse, ajanın doğrudan API’ye erişmesiyle karşılaştırıldığında MCP’nin avantajının ne olduğunu merak ediyorum
- Acaba bu, API’yi koruyan yetkilendirme yapısının yerini mi alıyor?
  Sonuçta API’nin bir şekilde izin mekanizmasına sahip olması gerekiyor gibi görünüyor
- Doğru
  Runlayer gibi şirketlerin hızla büyümesinin nedeni de tam olarak bu; merkezi bir kontrol düzlemi olmadan MCP mayın tarlasına dönüşür
Daha önce söylenenlerin dışında, uzak MCP sunucu taraflı olduğu için üretici tüm istemcilerin becerilerini ve CLI’larını güncellemeden yeni özellikler ekleyebilir
Ayrıca uzak MCP, yerel sistemde gerçek kod çalıştırma izni gerektirmediği için daha güvenlidir
Beceriler çoğu zaman betikleri npx/uvx ile paketliyor; bu da fiilen curl npm.com | bash kadar riskli
Ekipleri şirket içi yönetim sistemine bağlayan bir beceri uyguladım ve sonunda bunu MCP olarak kaydetmek zorunda kaldım
MCP yalnızca doküman grep’i ve API çağrılarını açığa çıkarıyor, bu yüzden tek başına tamamen işe yaramaz; ama bu yolu seçmemizin ana nedeni dağıtımdı
Teknik olmayan ekipler URL ekleyince her şeyin çalıştığı ve OAuth’un yönlendirildiği bir UI istiyor; MCP bunu Claude ya da ChatGPT içinde mümkün kılıyor
Sohbet arayüzünde MCP çağrılarının görünme şekli de daha iyi ve kullanıcı için daha net
MCP sunucularıyla uğraşıp tüm platformlar için CLI dağıtmak yerine, API’yi SSH üzerinden açmak nasıl olur diye düşünüyorum
SSH, büyük dil modelleri için mükemmel bir protokol
Kodlama ajanları bunu zaten kullanabiliyor ve ssh api@example.com list-users yeterli
Kullanıcıların %90’ında zaten ssh kurulu olma ihtimali yüksek ve hem girdi hem çıktı metin olduğu için büyük dil modellerine tam uygun
Açık anahtar kimlik doğrulamasını, akış halinde çıktıyı, etkileşimli giriş/çıkışı ve istenirse scp/rsync ile dosya aktarımını da hallediyor
Kullanıcı hesabını Github ya da GitLab’a bağladıysa ssh anahtarını çekip kimlik doğrulamayı önceden ayarlayabilir, böylece kullanıcı sadece bağlanıp doğrudan içeri girebilir
- Bunu tüm organizasyon ölçeğine yayarak düşünün
Restoran benzetmesi iyi değil
“Masada 10 menü açık duruyor, yemeği koyacak yer kalmıyor ve her siparişte menüyü yeniden çıkarmak gerekiyor” gibi bir şey ama tekrar sipariş vermek tapas restoranı dışında yaygın değil
Yemek menünün üstüne de konabilir ve genelde siparişten sonra menü kaldırılarak masa, yani bağlam boşaltılır
Benzetmeyle anlatılacaksa daha ilgili hale getirmek için biraz daha çaba gerek