Kodlama Ajanları için MCP Model Kataloğu: Model Seçimini Makine Tarafından Okunabilir Hale Getirin

Kodlama ajanları için bir MCP model kataloğu, bir ajanın kaynak koduna sabitlenmiş (hardcoded) model isimlerine güvenmek yerine, Model Context Protocol (MCP) aracılığıyla okuyabileceği, yapılandırılmış ve sorgulanabilir bir kullanılabilir modeller listesidir. Bu, bir ajanın, IDE eklentisinin veya orkestrasyon katmanının, bir geliştiricinin altı ay önce yazıp unuttuğu bir metin dizisi yerine; görev türüne, bağlam penceresine (context window) veya maliyet tavanına göre çalışma zamanında (runtime) bir model seçmesine olanak tanır.

Bu, kulağa geldiğinden çok daha önemlidir. Kodlama ajanları; otomatik tamamlama, çoklu dosya yeniden düzenleme (refactor), test oluşturma ve commit mesajı taslağı hazırlama gibi işlemler için sürekli olarak modelleri çağırır. Bu görevlerin her birinin ideal modeli farklıdır. Eğer ajan hangi modellerin var olduğunu ve ne işe yaradıklarını keşfedemezse, bir sağlayıcı her yeni sürüm yayınladığında birinin sürekli bir yapılandırma dosyasını düzenlemesi gerekir. Bu makale, bir model kataloğu girdisinin neleri içermesi gerektiğini, bu katalog için MCP tarzı isteklerin nasıl şekillendirildiğini ve hangi modellerin hangi kodlama görevlerine yönlendirileceğine nasıl karar verileceğini ele almaktadır.

Önemli Çıkarımlar

• Bir model kataloğu, model seçimini sabit kodlanmış bir diziden çalışma zamanı aramasına dönüştürür; bu da sağlayıcılar yeni modeller yayınladığında bakım yükünü azaltır.
• Kodlama ajanları, her şey için tek bir model kullanmak yerine farklı görev türlerini (otomatik tamamlama, yeniden düzenleme, test oluşturma, inceleme) farklı modellere yönlendirmekten fayda sağlar.
• Model kataloğu verileri için MCP istekleri genellikle resource-list veya tool-call şeklini izler; tam şema, üzerinde geliştirme yapmadan önce sağlayıcının kendi belgeleriyle doğrulanmalıdır.
• TokenLab, /models/data adresinde bir Model Veri Merkezi ve /models adresinde bir model dizini yayınlamaktadır; model serileri sık sık değiştiği için bu makaleyi değil, güncel model isimlerini doğrulamak için bu adresleri referans alın.

Kodlama Ajanları Neden Makine Tarafından Okunabilir Model Verisine İhtiyaç Duyar?

Çoğu kodlama ajanı entegrasyonu hala on yıl önceki API entegrasyonları gibi çalışıyor: bir geliştirici bir model ismi seçer, bunu bir yapılandırma dosyasına veya ortam değişkenine yapıştırır ve yayına alır. Bu, sağlayıcı modeli kullanımdan kaldırana, fiyatlandırmayı değiştirene veya ekibin benimsemek için hiçbir süreci olmayan daha iyi bir seçenek yayınlayana kadar çalışır.

Makine tarafından okunabilir bir katalog, hata modunu değiştirir. Bir ajan, model emekli edildiğinde sessizce bozulmak yerine, bir kataloğu sorgulayabilir, modelin gittiğini veya kullanımdan kaldırıldığını görebilir ve belgelenmiş bir alternatife geçiş yapabilir. Bir geliştiricinin her yeni sürümü manuel olarak kıyaslaması yerine, ajan (veya geliştiricinin araçları) geçiş yapmadan önce listelenen bağlam pencerelerini, modalite desteğini ve maliyet alanlarını karşılaştırabilir.

Bu aynı zamanda ciddi bir model yönlendirme stratejisi için de bir ön koşuldur. Eğer ucuz ve yüksek hacimli tamamlamaları DeepSeek V4 Flash veya Gemini 3.5 Flash gibi düşük maliyetli bir modele göndermek ve Claude Sonnet 5 gibi daha güçlü bir modeli çoklu dosya yeniden düzenlemeleri için ayırmak istiyorsanız, yönlendirme mantığının hangi modellerin güncel olduğu, ne kadara mal olduğu ve neleri desteklediği konusunda bir doğruluk kaynağına ihtiyacı vardır. Bu olmadan, yönlendirme kuralları sabit kodlanmış model isimleri gibi çürür.

TokenLab, bu sorunu doğrudan, model bilgisini bir insanın elle yeniden doğrulaması gereken bir şey olmaktan çıkarıp ajanın güvenebileceği bir şeye dönüştürme bağlamında ele almıştır. Daha geniş bir "ajan tarafından okunabilir model doğruluğu" argümanı için agent-readable model truth makalesine ve birincil çağırıcının insan geliştirici yerine bir ajan olduğu durumlarda API tasarımının nasıl değiştiğini görmek için agent-first API makalesine göz atın.

Bir MCP Model Kataloğu Girdisinde Neler Bulunmalıdır?

Kodlama ajanı için yararlı bir katalog girdisi, bir model isminden fazlasına ihtiyaç duyar. En azından, bunu oluşturan veya tüketen geliştiriciler şunları görmeyi beklemelidir:

• Model tanımlayıcısı: API'nin beklediği tam dizi; sağlayıcılar genellikle sürüm isimlerini hassas bir şekilde belirler (buradaki bir uyumsuzluk, en yaygın entegrasyon hatalarından biridir).
• Sağlayıcı: Bir katalog birden fazla sağlayıcıyı topladığında, modelin hangi şirket veya platform tarafından sunulduğu önemlidir.
• Modalite desteği: metin, kod, görsel veya video. Kimi K2.7 Code gibi kodlama modellerini Nano Banana Pro gibi görsel modellerle karıştıran bir katalog, ajanın gerçekten ihtiyaç duyduğu şeye göre filtreleme yapmasını sağlayan bir alana ihtiyaç duyar.
• Bağlam penceresi: büyük depolarda çalışan kodlama ajanları için token limitleri son derece önemlidir.
• Maliyet alanları: kodlama ajanları genellikle asimetrik, girdi ağırlıklı iş yüklerine (büyük dosya bağlamı, küçük fark çıktısı) sahip olduğundan, girdi ve çıktı token fiyatlandırması ideal olarak ayrı tutulmalıdır.
• Durum: güncel, kullanımdan kaldırılmış veya emekli edilmesi planlanmış. Bu, sessiz bozulmaları önleyen alandır.
• Görev uygunluk etiketleri: ajanın her modelin özelliklerini önceden bilmeden filtreleme yapabilmesi için "kodlama", "düşük maliyetli yönlendirme" veya "açık ağırlıklı" (open-weight) gibi isteğe bağlı ancak yararlı meta veriler.

Bu alanların hiçbiri her sağlayıcının katalog formatında bulunmak zorunda değildir. Bir entegrasyon oluşturmadan önce, kullandığınız sağlayıcıda belgelenen gerçek şemayı kontrol edin. Özellikle TokenLab tarafından sunulan modeller için, mevcut alan seti ve güncelleme sıklığı, yeni modeller ve modaliteler eklendikçe katalog şemaları değiştiğinden, bu makaleden varsaymak yerine /models/data adresinden doğrulanmalıdır.

Örnek: MCP Üzerinden Model Kataloğu İsteme

MCP genellikle JSON-RPC 2.0 üzerinden iletişim kurar. Bir sunucudan mevcut model kaynaklarını listelemesini isteyen bir istemci, buna benzer bir istek gönderebilir. Bu örnek, genel MCP kaynak listesi modelini göstermek içindir ve herhangi bir sağlayıcının canlı şeması hakkında bir iddia değildir; üretim kodu yazmadan önce tam yöntem isimlerini ve yanıt alanlarını https://docs.tokenlab.sh adresinden veya MCP sunucunuzun kendi belgelerinden doğrulayın.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {
    "filter": {
      "modality": "text",
      "tag": "coding"
    }
  }
}

Doğrulanmış bir şemadan ziyade açıklayıcı olması amaçlanan makul bir yanıt şekli:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "id": "claude-sonnet-5",
        "provider": "Anthropic",
        "modality": ["text", "code"],
        "context_window": "sağlayıcı belgelerinden doğrulayın",
        "status": "current",
        "tags": ["coding", "review"]
      },
      {
        "id": "deepseek-v4-flash",
        "provider": "DeepSeek",
        "modality": ["text", "code"],
        "context_window": "sağlayıcı belgelerinden doğrulayın",
        "status": "current",
        "tags": ["low-cost", "coding"]
      }
    ]
  }
}

Bağlam penceresi değerlerini, tam alan isimlerini veya yukarıda listelenen belirli modelleri herhangi bir canlı API hakkında doğrulanmış gerçekler olarak kabul etmeyin. Bunlar burada fiyatlandırma veya kapasite sayılarını belirtmek için değil, bir istek ve yanıtın şeklini göstermek için bulunmaktadır. Bu sayıları her zaman sağlayıcının kendi güncel belgelerinden veya geliştirme yaptığınız sırada /models/data adresinden alın.

Göreve Göre Model Seçimi: Bir Karar Kontrol Listesi

Bir model kataloğu, yalnızca ajanın (veya ajanı yapılandıran geliştiricinin) görev türünü modelle eşleştirmek için bir kuralı varsa yararlıdır. Aşağıdaki tablo bir benchmark sonucu değil, başlangıç çerçevesidir. Üretimde bir yönlendirme kuralına karar vermeden önce güncel fiyatlandırmayı ve kapasite iddialarını sağlayıcı belgeleri ve /models ile doğrulayın.

Kodlama ajanı görevi	En önemli olan	Değerlendirilecek örnek modeller
Otomatik tamamlama / satır içi öneriler	Düşük gecikme, çağrı başına düşük maliyet	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
Çoklu dosya yeniden düzenleme	Daha geniş bağlam penceresi, güçlü kod muhakemesi	Claude Sonnet 5, DeepSeek V4 Pro
Test oluşturma	Tutarlı biçimlendirme, orta düzey muhakeme	Kimi K2.7 Code, Claude Sonnet 5
Kod inceleme / PR özetleme	Güçlü muhakeme, farkları (diffs) doğru referanslama yeteneği	Claude Sonnet 5, Gemini 3.5 Flash
Yüksek hacimli toplu görevler (linting, doc yorumları)	Ham kapasiteden ziyade token başına maliyet	GLM-5.2, Qwen3.7 Plus, MiniMax M3
Açık ağırlık gereksinimi (kendi kendine barındırma veya lisans kısıtlamaları)	Açık ağırlıklar, yönetilen bir API dışında dağıtılabilir	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

Yönlendirme mantığını oluşturmak için pratik bir kontrol listesi:

1. Katalog girdisi bir durum (status) alanı içeriyor mu, böylece bir çağrı başarısız olmadan önce kullanımdan kaldırmayı tespit edebilir misiniz?
2. Katalog, kodlama yeteneğine sahip modelleri genel metin veya görsel modellerden ayırıyor mu, böylece filtreleme sabit kodlanmış listeler gerektirmiyor mu?
3. Görev türü başına bir maliyet tavanı belirleyebilir ve ajanın her zaman en yetenekli (ve en pahalı) seçeneğe varsayılan olarak dönmek yerine, bunu karşılayan en ucuz modeli seçmesini sağlayabilir misiniz?
4. Birincil seçeneğin kullanılamaması veya hız sınırına takılması durumunda her görev kategorisi için tanımlanmış bir yedek model var mı?
5. Kataloğu sadece ilk entegrasyonda değil, model serileri zamanla değiştiği için düzenli bir programla yeniden kontrol ediyor musunuz?

TokenLab Bu İş Akışının Neresinde?

TokenLab, 14-07-2026 itibarıyla gözlemlendiği üzere /models/data adresinde bir Model Veri Merkezi ve /models adresinde bir model dizini tutmaktadır. Model katalogları doğası gereği zamana duyarlı olduğundan, herhangi bir statik makaleye güvenmek yerine güncel model listeleri için kontrol edilmesi gereken yüzeyler bunlardır. TokenLab'in https://docs.tokenlab.sh adresindeki API belgeleri, entegrasyon yapmadan önce tam istek ve yanıt şemalarını doğrulamak için doğru yerdir.

İnceleme görevleri için Claude Sonnet 5, ucuz yüksek hacimli tamamlamalar için DeepSeek V4 Flash ve test oluşturma için Kimi K2.7 Code gibi modeller arasında yönlendirme yapması gereken bir kodlama ajanı oluşturuyorsanız, pratik yöntem model tanımlayıcısını ajanın kaynak koduna derlenmiş bir sabit değil, istek anında bir kataloğa göre çözümlenen bir değişken olarak ele almaktır. /models/data adresindeki güncel listeleri inceleyerek ve yönlendirme mantığını üretime almadan önce MCP istemcinizin ihtiyaç duyduğu istek şeklini TokenLab API belgelerine göre doğrulayarak başlayın.

Sınırlamalar

Bu makale, MCP model katalogları ve kodlama ajanı yönlendirmesi için genel bir modeli açıklamaktadır. TokenLab dahil olmak üzere herhangi bir sağlayıcının yukarıda açıklanan her alanı (bağlam penceresi, maliyet alanları, durum, görev etiketleri) tam olarak bu şekilde sunduğunu onaylamaz. Şemalar, alan isimleri ve mevcut modeller sık sık değişir. Bu makaledeki JSON örneklerini herhangi bir canlı uç nokta için doğrulanmış bir şema olarak değil, MCP'nin genel istek ve yanıt modelinin açıklayıcısı olarak kabul edin. Yayına almadan önce, tam model tanımlayıcılarını, fiyatlandırmayı ve bağlam pencerelerini sağlayıcının güncel belgelerine ve /models/data adresine göre doğrulayın.

SSS

MCP'nin kendisi standart bir model kataloğu şeması tanımlıyor mu? MCP, JSON-RPC üzerinden kaynaklar ve araçlar için genel modeller tanımlar, ancak bir model kataloğundaki tam alanlar (fiyatlandırma, bağlam penceresi, durum), MCP'yi uygulayan sunucunun bu verileri nasıl sunmayı seçtiğine bağlıdır. Belirli şemayı entegre ettiğiniz sunucu veya sağlayıcı ile doğrulayın.

Bir kodlama ajanı her zaman mevcut en yetenekli modeli mi kullanmalıdır? Gerekli değil. Otomatik tamamlama gibi görevler gecikme ve maliyete duyarlıyken, çoklu dosya yeniden düzenlemeleri daha güçlü muhakeme ve daha geniş bağlamdan yararlanır. Görev etiketleri ve maliyet alanlarına sahip bir katalog, her şey için tek bir modele varsayılan olarak dönmek yerine göreve göre yönlendirme yapmanızı sağlar.

Ajanımın bağlı olduğu model kataloğunu ne sıklıkla yeniden kontrol etmeliyim? Model serileri, tek seferlik bir entegrasyonun yeterli olmayacağı kadar sık değişir. Yönlendirme mantığınızı model tanımlayıcılarını kalıcı olarak önbelleğe almak yerine kataloğu sorgulayacak şekilde oluşturun ve /models/data adresini veya sağlayıcınızın belgelerini düzenli bir programla kontrol edin.