SaaS'ınız İçin MCP Sunucusu Nasıl Yayımlanır

Bu bir entegrasyon angaryası değil, dağıtım kararıdır

Ürününüzün insanlar için arayüzü, geliştiriciler için API'si vardır. MCP sunucusu üçüncü bir yüzey ekler: müşterinizin zaten açık olan asistanı. Ticari fark önemlidir, çünkü sizi çağırıp çağırmayacağına karar veren artık sekme karşılaştıran bir insan değil, araç açıklamalarını karşılaştıran bir modeldir.

Bu çerçeve değişimi aşağıdaki tasarım kararlarının çoğunu belirler. Bir entegrasyon yazmıyorsunuz; hepsini aynı anda görebildiği alternatifler listesinden, araştırma yapmayacak bir okuyucu tarafından seçilmesi gereken bir şey yazıyorsunuz.

Kod yazmadan önce neyi açacağınıza karar verin

İçgüdü REST API'nizi aynalamaktır. Direnin. API, dokümantasyon okuyup çağrı kuran bir geliştirici için tasarlanmıştır; MCP sunucusunu ise tek bir aracı çağıran, sonuca bakan ve sonra ne yapacağına karar veren bir model tüketir.

Üç soru seçimi hızla daraltır. Müşteriler bir asistandan gerçekte hangi işleri istiyor — hangi uç noktalar var değil? Bu işlerden hangileri dört çağrı yerine tek çağrıyla bitiyor? Ve hangi sonuçlar bağlam penceresinde işe yarayacak kadar derli toplu, 400 satırlık bir JSON dökümü değil?

İyi bir ilk sunucu, her biri bir işi bitiren üç ila altı araçtır: şeyi bul, durumunu özetle, küçük ve güvenli değişikliği yap. Yalnızca okuma yapan araçlar meşru bir v1'dir ve bir hafta daha erken yayına girer.

İzinleri dokümantasyon sayfası gibi değil, API anahtarı gibi sınırlayın

MCP sunucusu, ikna edilebilen bir sisteme gerçek yetenek açar. Yayımladığınız her aracın er ya da geç, göremediğiniz bir konuşmadan, beklemediğiniz argümanlarla çağrılacağını varsayın.

Pratikte: bağlantıyı hizmetinize genel olarak değil belirli bir hesaba kimlik doğrulayın. Her araca çalışmasına yetecek en dar kapsamı verin — güncelleme aracı varken arama aracının yazma izni gerekmez. Argümanları modelin şemaya uyduğuna güvenmek yerine sunucu tarafında doğrulayın. Ve geri alınamaz eylemleri, prompt içindeki bir talimatın değil, kendi uygulamanızın sahip olduğu bir onay adımının arkasına koyun.

Bağlantı başına hız sınırı koyun. Yeniden deneme döngüsündeki bir model alışılmadık ölçüde hevesli bir istemcidir.

Araç açıklamalarını ürünmüş gibi yazın

Sunucuların çoğu burada başarısız olur ve başarısızlık sessizdir: model sizi hiç çağırmaz. Aracınızın doğru araç olduğunu keşfetmesinin, sizin yazdığınız cümleden başka yolu yoktur.

Araç başına tek iş adlandırın. Ne zaman kullanılacağını ve ne zaman kullanılmayacağını yazın: 'faturalar için kullanın; abonelik değişiklikleri için billing_update kullanın' cümlesi, her türlü parametre ayarından daha çok yanlış çağrıyı önler. Modelin var olmayan bir durum uydurmaması için serbest metin yerine enum tercih edin. Ve açıklamaya örnek bir argüman koyun; bir örnek üç cümlelik şartnameye bedeldir.

Sonra müşterilerinizin gerçekten kullandığı asistanlarla test edin. Aynı sunucu istemciden istemciye farklı davranır ve 'benim terminalimde çalışıyor', alıcılarınızın bulunduğu yüzey hakkında kanıt değildir.

İlk günden ölçün

Her çağrıyı loglayın: hangi araç, hangi argümanlar, ne döndü, ne kadar sürdü. Bu olmadan yalnızca önemli olan soruları yanıtlayamazsınız: hangi araçlar kullanılıyor, hangileri çağrılıp sonucu kullanılamadığı için bırakılıyor ve hangileri hiç seçilmiyor.

En öğretici olanlar bırakılanlardır. Çağrılan ama sonucu hiçbir yere varmayan bir araç genelde çok fazla, çok az ya da yanlış biçimde veri döndürür; bunu düzeltmek, kimsenin istemediği özellikleri eklemekten ucuzdur.

Önce ne yayımlamalı

Tek hesaba kapsanmış, loglanan ve iki istemcide test edilmiş, iyi açıklanmış üç araçlı salt okunur bir sunucu. Bu bir haftalık iştir, yayımlaması güvenlidir ve müşterilerin neyi otomatikleştirmek istediğini bir çeyreklik planlamadan daha iyi öğretir.