MCP ajanı API'ye ulaştırır, ancak alan düzeyinde erişime kendisi karar veremez

29 Eylül 2026'da The New Stack'te Apollo GraphQL kurucusu Matt DeBergalis'in makalesi yayımlandı: MCP ile bir sisteme erişmek bugün kolay, ancak ajanın bağlantıdan sonra neleri görebileceğine MCP kendisi karar vermiyor.

Erişilebilirlik bugün kolay, görünürlük değil

Makale operasyon ekibi örneğini kullanıyor: bir çalışan asistandan hangi siparişin gönderim süresini kaçıracağını belirlemesini, diğer depolardaki stoğu kontrol etmesini ve açığı kapatacak yerlere transfer talepleri oluşturmasını ister. Süreç mevcut siparişlere, kullanılabilir stoğa ve geri yazmaya ihtiyaç duyar.

Dahili API'yi ajan için erişilebilir kılmak bir MCP sunucusu kurarak mümkündür, ancak zor soru bağlantıdan sonra neyi görme hakkı olduğudur.

Bariz çözümler sorunu neden çözmüyor

Sipariş yönetimi API'si sipariş durumundan çok daha fazlasını döndürebilir: kişisel veriler, finansal ve sahtekârlık ayrıntıları, ayrıca güvenilen ağın dışına çıkmaması gereken operasyonel bilgiler. Normal bir uygulamada bunu sunucu belirler: yetkileri kontrol eder ve yalnızca uygun görünümü döndürür.

Ajan bu şemayı bozar: üst sistemden her şeyi aktaran araç bir güvenlik riskidir. Yanıtı filtrelemek ise ikinci bir sorun yaratır: finans departmanının siparişler için farklı bir görünüme, desteğin dahili notların bir kısmına ihtiyacı vardır, başka bir ekip stok sistemini bağlar ve onlarca örtüşen araç birikir.

Alan düzeyinde sözleşme

Yazarın görüşüne göre çözüm, her ajanın neyi görüp ne yapabileceğini tam olarak belirleyen alan düzeyinde bir sözleşmedir. MCP araçların keşfini ve çağrılmasını tanımlar, sözleşme ise erişim sınırlarını; her iki katman da gereklidir.

Pratik bir yol olarak yazar GraphQL öneriyor: sorgu yalnızca gereken alanları içerir, örneğin status ve shipBy, ve yanıtta da yalnızca onlar döner. Ajan internalFraudScore veya customerSSN gibi hassas bir alan isterse sunucu isteği reddedebilir veya bu alanları erişilemez kılabilir. Kural alanın kendisine aittir.

Yazma da aynı şekilde çalışır: yalnızca okuma izni işi yapmaya yetmez, sınırsız erişim ise ajanın stok değiştirmesine, siparişi iptal etmesine veya para iadesi yapmasına olanak tanır. Ayrı bir iş eylemi, örneğin requestInventoryTransfer, ayrı bir işlem olarak ortaya çıkar: izin çalışma zamanında kontrol edilir, stok bulunurluğu ve gerekli onaylar ise temel hizmet tarafından kontrol edilir. İş API'lerini değiştirmek gerekmez: katman mevcut REST, gRPC veya SOAP hizmetlerinin üzerine oturur.

Bu pratikte ne anlama geliyor

Öneri tarafsız değil: yazar GraphQL üreten bir şirketi yönetiyor. Argümanın kendisi belirli bir araçtan bağımsız olarak geçerlidir: ajan erişimi API ile araç arasında ayrı, açıkça tanımlanmış bir sınıra ihtiyaç duyar; her alan ve her eylem düzeyinde. Yazarın söylediğine göre böyle bir sözleşme on yıldan fazla süredir gerçek sistemlerde çalışıyor ve Shopify, Netflix, Airbnb, Expedia Group ve Walmart gibi şirketlerde milyarlarca işlemi destekliyor.