MCP Sunucuları: JSON Şemaları Context Bütçesini Nasıl Yer?

Arka Planda Çalıştığını Sandığın Araçların Gerçek Maliyeti#

Kodlama ajanına herhangi bir kaynak dosya eklemeden, tertemiz bir sohbet geçmişiyle yalnızca iki kelimelik "Run tests" komutunu verdiğinde API faturanda anında 28.400 giriş token'ı görebilirsin. Model henüz tek karakter bile üretmeden aktif context penceresinin neredeyse yüzde 15'i buharlaşır. Suçlu devasa bir kod tabanı indeksi değildir. Sorun, yapılandırma dosyana hevesle eklediğin Model Context Protocol (MCP) sunucularından kaynaklanır.

Birçok geliştirici, tanımlanan MCP araçlarının model onlara ihtiyaç duyana kadar arka planda sessizce beklediğini varsayar. LLM araç çağırma mekanizması böyle çalışmaz. Modelin hangi aracı ne zaman çağıracağını bilmesi için ana uygulamanın kayıtlı her aracın tam JSON Schema tanımını her API isteğinin sistem context'ine enjekte etmesi gerekir. Anthropic Tool Use API veya OpenAI Function Calling kullanırken tools parametresi üzerinden tüm bu şemalar her mesajda karşı tarafa gönderilir.

GitHub, Jira, Postgres, Sentry, Slack, Docker ve dosya sistemi gibi yedi farklı MCP sunucusunu aynı anda bağlamak ajanına süper güçler kazandırıyor gibi görünür. Gerçekte ise her konuşma turunda ödediğin ağır bir vergiye dönüşür. Üstelik bu yük ilk token üretim süresini (time-to-first-token) yavaşlatırken modelin akıl yürütme doğruluğunu da düşürür.

Tek Bir Şemanın Anatomisi ve Katlanan Token Yükü#

Kapsamlı bir GitHub veya bulut sağlayıcı MCP sunucusu kurduğunda eline bir iki araç geçmez. Karşına create_issue, update_pull_request, list_workflow_runs veya get_commit_status gibi 30 ila 60 ayrı uç nokta çıkar. Bu araçların her biri ağ üzerinden şu yükleri taşır:

• Aracın ne zaman kullanılıp ne zaman kullanılmayacağını anlatan uzun açıklamalar,
• Her parametreyi, filtreyi ve sabit listeyi (enum) tanımlayan iç içe geçmiş JSON Schema nesneleri,
• Özellik açıklamalarının içine gömülmüş doğrulama kısıtlamaları ve kullanım örnekleri.

Örneğin projedeki kayıtları aramaya yarayan search_project_issues_advanced adlı tek bir aracın şeması bile query, state, labels ve sortBy gibi alanların detaylı tanımlarıyla birlikte yaklaşık 180-220 token tutar. Rakam tek başına küçük görünebilir. Ancak gerçekçi bir geliştirici kurulumunda tablo hızla büyür:

• GitHub MCP sunucusu: Yaklaşık 35 araç (~8.500 token)
• Issue Tracker / Docs MCP: Yaklaşık 25 araç (~6.200 token)
• Veritabanı ve Observability MCP'leri: Yaklaşık 20 araç (~4.800 token)
• Tarayıcı / Dosya sistemi / Git MCP'leri: Yaklaşık 25 araç (~5.500 token)

Sen daha sorunun ilk harfini yazmadan on binlerce token sistem context'ine yerleşmiş olur.

Yapılandırma Dosyanı Nasıl Sadeleştirmelisin?#

Geliştirici veya öğrenci olarak kendi ajan kurulumunu yaparken her şeyi kapsayan hazır MCP paketlerini olduğu gibi açık bırakmaktan kaçınmalısın. Yapılandırma dosyanı bir yetenek listesi gibi görmek yerine her turda faturana ve modelin hafızasına yansıyan aktif bir maliyet kalemi olarak değerlendir.

Pratikte atabileceğin en doğrudan adım, aktif oturumda kullanmadığın MCP sunucularını yapılandırmadan çıkarmaktır. Sadece kod testi çalıştıracağın bir oturumda Issue Tracker, Slack veya gözlemlenebilirlik sunucularını açık tutmak binlerce token'ı boşa yakar. Her biri 30-60 uç nokta barındıran devasa entegrasyonları üst üste yığmak yerine yalnızca o anki görevine gereken araçları bağlı tutarak hem API bütçeni koruyabilir hem de modelin yanıt hızını ve akıl yürütme kalitesini artırabilirsin.

---

Bu konuyu derinlemesine öğrenmek istersen: Production MCP Entegrasyonu modülüne göz at.