MCP üretime geçiyor: gateway ödünleşimleri ve gerçek bir Django sunucusundan dersler

MCP sahada olgunlaşıyor

Aynı gün yayınlanan iki dev.to yazısı aynı dönüşü iki karşıt yönden yakalıyor: Model Context Protocol demo aşamasını geride bırakıp üretim mühendisliğine giriyor. Yazılardan biri, Anthropic'nin Claude Code'unu kurumsal çapta çalıştıran ekiplerin agent ile MCP sunucuları arasına bir gateway koyması gerektiğini savunuyor; diğeri bir geliştirme ekibinin müşteri Django uygulamaları için aylarca MCP sunucusu geliştirmekten çıkardığı pratik dersleri derliyor.

Claude Code önünde gateway savunusu

Gateway odaklı dev.to yazısına göre, geliştirmenin erken aşamasında Claude Code'un MCP sunucularına birkaç doğrudan bağlantısı sorunsuz çalışıyor; ancak kurumsal ölçekte üç sorun ortaya çıkıyor.

İlk sorun context maliyeti. Her MCP sunucusu araçları için JSON şemaları yayımlar ve client'lar bunların tamamını her turun başında prompt'a yükler. On beş ila 20 araç sunan beş sunucu, model proje kodunun tek satırını okumadan context'e 75-100 şema iter; şema başına 150-300 token'la, yalnızca araç tanımları istek başına 15.000-30.000 token tüketir ve bu, çok adımlı bir kodlama döngüsünün her adımında tekrarlanır.

İkinci sorun kimlik bilgileri. GitHub token'ları, veritabanı bağlantı dizeleri ve dahili API anahtarları ~/.claude veya .mcp gibi geliştirici makinelerindeki düz metin yapılandırma dosyalarında son buluyor; güvenilmeyen web içeriğini işleyen araçlar ise yıkıcı veritabanı eylemlerine giden bir prompt-injection yolu oluşturuyor.

Üçüncü sorun denetlenebilirlik. SOC 2, ISO 27001 ve HIPAA gibi uyum rejimleri otomatik eylemlerin izlenebilir kayıtlarını bekliyor; terminal oturumlarına ve tek tek sunucu süreçlerine dağılmış log'lar bunları sağlayamıyor.

Karşılaştırma ne öneriyor

Yazı, gateway'leri şu ölçütlerle değerlendiriyor: stdio, SSE ve HTTP sunucularının tek bir bağlantıda toplanması; filtreleme veya isteğe bağlı yükleme yoluyla token optimizasyonu; sanal anahtarlar ve bütçelerle kimlik doğrulama; routing overhead; çok sağlayıcılı model routing; ve secret tespiti ile PII maskeleme gibi guardrail'ler.

Yazarın ilk tercihi, Maxim AI tarafından Go ile yazılmış açık kaynak bir gateway olan Bifrost; milisaniyenin altında routing overhead ve araç tanımı token maliyetlerini yüzde 92,8'e kadar düşürdüğü söylenen bir Code Mode yürütme yaklaşımıyla övülüyor. Docker MCP Gateway container izolasyonu için, IBM ContextForge çok protokollü federation için, LiteLLM ise Python tabanlı proxy'leme için konumlandırılıyor. Bu sıralamalar yayımlanmış benchmark'lar değil yazarın değerlendirmesidir ve yazının kendisi Bifrost'u öne çıkarıyor; dolayısıyla ekipler bu sıralamayı bir hüküm değil başlangıç noktası olarak görmeli.

Django MCP sunucusu geliştirmekten dersler

Aylardır müşteri Django uygulamaları için MCP sunucuları geliştiren bir ekibin yazısı, beklentileri kısarak başlıyor: MCP araçların, kaynakların ve prompt'ların stdio ya da HTTP/SSE üzerinden JSON-RPC ile nasıl sunulacağını standartlaştırıyor; ancak kimlik doğrulama, erişim kontrolü, rate limiting veya iş mantığı sunmuyor. Protokol transport'tır; operasyonel olan her şey onun üstünde yer alır.

Sunucuları, bir Django view'unun içinde yaşamak yerine Django modellerini ve servislerini import eden bağımsız bir Python süreci olarak çalışıyor ve öne çıkan birkaç ders var.

Araç açıklamaları asıl prompt engineering yüzeyidir. Bir aracın ne zaman çağrılacağını, hangi girdileri beklediğini ve ne döndürdüğünü söyleyen açıklama, arkasındaki koddan güvenilirlik açısından daha fazla işe yarar ve bir system prompt kadar özen ister.

Açığa çıkarılan her araç, bir agent'ın gerçekleştirebileceği bir eylemdir. Ekip bir send_email aracını erken yayınladı ve agent bunu kimsenin öngörmediği bir bağlamda kullandı: altta yatan veri tamamlanmadan müşteriye bir özet e-postası gönderdi ve bu bir destek talebi üretti. Çözüm aracı kaldırmak değil, canlı çağrı öncesinde zorunlu bir onay eklenmiş bir dry_run parametresi oldu.

Yazma amaçlı araç çağrıları, çalıştırılmadan önce araç adı, argümanlar, sonuç ve çağıranı kaydeden dayanıklı bir kayda yazılmalı; böylece başarısız ya da çöken çağrılar bile iz bırakır.

Async MCP SDK ayrıca Django'nun senkron ORM'iyle çatışıyor: doğrudan sorgular SynchronousOnlyOperation hatası veriyor, bu yüzden ORM işleri sync_to_async ile sarılmalı. DJANGO_ALLOW_ASYNC_UNSAFE ayarı sorunları geliştirme sırasında görünür kılmaya yarar ama yazının uyardığı gibi asla üretime gitmemelidir. Stdio transport'u yerel masaüstü client'larına uygundur; ağ bağlantılı üretim agent'ları ise bunun yerine HTTP/SSE kullanmalıdır.

Neden önemli

İki yazı da aynı sonucu hattın iki karşıt ucundan veriyor: MCP birlikte çalışabilirliği çözer, operasyonları değil. Token bütçeleri, kimlik bilgisi yönetimi, denetim izleri ve yazma yeteneğine sahip araçların etki alanı, birçok sunucuyu bir gateway ile mi öne çıkarırsınız yoksa tek bir sunucuyu dikkatlice mi kurarsınız, benimseyenin sorunu olarak kalıyor. Kodlama agent'ları gerçek iş sistemlerine yazma erişimi kazandıkça, üretim hazırlığı protokolün kendisinde değil bu operasyonel katmanda belirlenecek.