MCP Server Tasarımında Tool Routing ve Intent Lock Neden Önemli?

Model Context Protocol (MCP), bir dil modelinin dış sistemlerdeki araçları standart bir arayüz üzerinden çağırmasını sağlıyor. Pratikte protokolün kendisi değil, sunucu tarafındaki araç tasarımı belirleyici oluyor: araç isimleri, parametre şemaları ve hata mesajları modelin davranışını doğrudan şekillendiriyor.

Çok alanlı (multi-domain) bir MCP sunucusunu test ederken tipik bir sorunla karşılaşılır: kullanıcı bir alanda arama yaparken model, isim veya parametre benzerliği nedeniyle başka bir alana ait aracı çağırır. Buna intent drift denir. Örneğin şehirlerarası otobüs araması yapan bir kullanıcının isteği, parametre kümesi benzer olduğu için araç tahsisi yapan bir araca yönlenebilir. Bu, modelin hatasından çok arayüz tasarımının belirsizliğinden kaynaklanır.

Intent lock nedir? Oturumun aktif alanının sunucu tarafında tutulması ve her araç çağrısında bu alanla eşleşme kontrolü yapılmasıdır. Kullanıcı otobüs alanındayken araç kiralama aracına gelen bir çağrı reddedilir ve modele açık bir hata döner: alan uyuşmuyor, önce alan değiştirme aracını çağır. Böylece niyet değişimi örtük değil, açık bir adım haline gelir.

İkinci savunma hattı şemadır. Her istek ve yanıt nesnesine zorunlu bir alan (domain) bilgisi eklemek, modelin hangi bağlamda çalıştığını her çağrıda tekrar beyan etmesini sağlar. Beyan ile oturum durumu çeliştiğinde sunucu işlemi durdurur. Bu, istemci tarafı bir kurala güvenmek yerine doğrulamayı sunucuya taşır.

Üçüncü nokta isimlendirme disiplinidir. arama_yap, ara, sorgula gibi genel adlar yerine bus_search, flight_search, car_rental_search gibi alan öneki taşıyan adlar kullanmak, benzer araçlar arasındaki mesafeyi artırır. Açıklama metinleri de aynı netlikte olmalı; bir aracın ne yapmadığını yazmak, ne yaptığını yazmak kadar değerlidir.

Tarih ve zaman alanları ayrı bir hata kaynağıdır. Serbest metin tarih kabul eden bir araç, modelin yerelleştirilmiş biçimler üretmesine yol açar. ISO-8601 zorunlu kılmak ve saat dilimini açıkça istemek hem doğrulamayı hem de hata mesajlarını sadeleştirir. Aynı şekilde sayısal alanlarda birim beyanı (kişi sayısı, gece sayısı, para birimi) belirsizliği azaltır.

Güvenlik tarafında OTP veya benzeri doğrulama akışları, işlem başlatan araçlar için doğru bir yaklaşımdır. Ancak doğrulamanın araç seviyesinde değil, işlem seviyesinde bağlayıcı olması gerekir: doğrulanmış oturum kimliği olmadan rezervasyon, ödeme veya iptal çağrıları kabul edilmemelidir. Modelin ürettiği metne güvenerek yetki vermek, protokolden bağımsız bir güvenlik açığıdır.

Hata mesajları modelin öğrenme yüzeyidir. Genel bir 400 yanıtı yerine, hangi alanın eksik olduğunu ve beklenen biçimi söyleyen yapılandırılmış hatalar döndürmek, modelin bir sonraki denemede doğru çağrıyı üretme olasılığını belirgin biçimde artırır. Aynı şekilde hız limitleri ve yeniden deneme politikaları dokümante edilmeli; model, bekleme gerektiğini yalnızca hata metninden anlayabilir.

Güvenli tool routing için kısa kontrol listesi: alan bazlı araç isimlendirmesi, oturum düzeyinde intent lock, şemada zorunlu alan bilgisi, sunucu tarafı doğrulama, açık alan değiştirme aracı, ISO-8601 tarih biçimi, işlem seviyesinde yetki kontrolü, yapılandırılmış hata mesajları, limit ve yeniden deneme dokümantasyonu.

Bu maddelerin ortak noktası, modelin doğru davranmasını ummak yerine yanlış davranışı sunucu tarafında imkânsız kılmaktır. MCP sunucusu tasarlarken sorulacak soru şudur: modelin üretebileceği en makul yanlış çağrı hangisi ve sistem onu hangi katmanda durduruyor?