Uzaktan MCP sunucusu iş başında: Yapay Zeka çağında SaaS ürünleri için yeni bir giriş noktası

SaaS ürünlerinin uzun süredir devam eden bir sorunu var: değere ulaşma süresi çok yavaş. Birçok kullanıcı, “aha” anına ulaşmadan ürünü bırakıyor.

Logto'nun onboarding sürecinde defalarca iterasyon yaptık. Yardımcı oldu, ancak darboğaz ortadan kalkmadı. Yine de doküman okuman, eğitimleri gözden geçirmen, SDK'ları kurman, yapılandırmaları bağlaman, kod yazman ve sonunda çalışması için son %10'u hata ayıklaman gerekiyor.

Bu yüzden farklı bir yaklaşım denedik: Logto’nun IDE’ye özgü kontrol düzlemi olarak uzaktan bir MCP sunucusu. Yönetim panelinden tıklamak yerine, Logto’yu doğrudan app’i geliştirdiğin yerde bir sohbet üzerinden yapılandırıyor ve entegrasyon kodunu üretiyorsun.

Tek bir prompt ile sıfırdan çalışan bir entegrasyona ulaşabiliyorsun. Agent sadece kod üretmekle kalmıyor, aynı zamanda Logto uygulamasını tenant’ında oluşturup yapılandırıyor. Hem de doğrudan IDE'nin içinde. (Logto MCP Sunucusunu dene)

Bu yazıda, Logto MCP Sunucusunu geliştirirken yaşadıklarımızı ve düşüncelerimizi paylaşacağım. Şunları içerecek:

• MCP ve Agent Skills: Neden MCP seçtik
• Bir MCP sunucusu geliştirirken karşılaştığımız problemler ve nasıl çözdüklerimiz
• MCP araçlarını nasıl tasarladık, seninkini nasıl tasarlamalısın
• MCP'nin geleceğinden beklentilerimiz

MCP ve Agent Skills: Neden MCP’yi seçtik#

Yapay zekanın Logto'ya nasıl erişmesi gerektiğine karar vermeden önce iki seçeneği değerlendirdik: MCP sunucuları ve Agent Skills.

MCP sunucularının iki şekli var: yerel ve uzaktan.

Yerel MCP sunucusu kullanıcının makinesinde çalışır. Servis kurulumu, ortam ayarları, kimlik bilgileri veya özel giriş akışları gerektirir. Kullanım ve dağıtım açısından skills'e çok benzer.

Uzaktan MCP sunucusu sunucu tarafında barındırılır. Kullanıcılar bir URL ile bağlanır ve OAuth ile yetkilendirir. Bu model SaaS servis uzantısına daha yakındır.

Yapısal olarak bir Agent Skill, "iş mantığı + temel yetenekler" birleşimidir. Bu yetenekler araçlar, CLI'lar veya API çağrıları olabilir. MCP araçları bu katmanı bütünleşik biçimde taşıyabilir.

Yani asıl soru; yetenekler nasıl uygulanıyor değil, nasıl kullanıcılara ulaştırılıyor.

• Agent Skills ile: tüm yerel araç zincirini sunarsın (Skill paketi + yerel çalışma zamanı + API anahtarları/kimlik bilgileri + CLI araçları + kurulum, yapılandırma, güncelleme ve bakım akışı).
  Özünde, kullanıcıya kendi çalıştıracağı yeteneği verirsin.

• Uzaktan MCP sunucusu ile: uzak bir servis girişi sunarsın (URL + OAuth girişi).
  Özünde, yeteneği bir servis olarak sağlarsın.

Aşağıda, kullanıcı deneyimi, ekosistem erişimi ve dağıtım/bakım maliyeti açısından karşılaştırıyoruz.

Kullanıcı deneyimi#

Agent Skills genellikle platform API’si veya CLI’lara bağımlıdır. Kullanıcıların önce API anahtarı oluşturması veya CLI kurup giriş yapması gerekir. Bu adımlar karmaşık değil ama giriş barajını yükseltir.

MCP sunucuları OAuth destekler. Kullanıcılar kendi SaaS hesaplarıyla giriş yapar. Deneyim "Google ile Giriş" gibidir.

Kullanıcı için MCP sunucusu kullanmak çok basit: bir URL gir, giriş yap, bağlan. Sunmak istediğimiz deneyim bu.

Ekosistem erişimi#

MCP web sitesinde halihazırda MCP destekleyen 104 AI uygulaması mevcut; aralarında VS Code, Cursor ve Windsurf gibi araçlar var.

Agent Skills hala platforma özgüdür. Pek çok platform onları desteklemeye başlasa bile, biz bir MCP sunucusu geliştirdiğimizde, kullanıcılar hemen kullanabilir. Skill yayınladığımızda ise yalnızca o platform kullanıcıları kullanabilir.

MCP aynı zamanda Agentic AI Foundation (AAIF) standardı kapsamında. Protokol seviyesinde bir standart. Ekosistem büyümeyi sürdürecek. Bizim için MCP uzun vadeli yatırım yapmaya değer.

Dağıtım ve bakım maliyeti#

Agent Skills platform API’si veya CLI’lara bağlıdır ve hızla sorunlar getirir:

• API değişirse ne olur?
• CLI uyumluluk bozulursa ne olur?
• Skill’i nasıl günceller ve dağıtırsın?

Ayrıca CLI’ları dağıtmalı, dağınık kimlik bilgilerini yönetmeli, farklı platformlara uyum sağlamalı ve kullanıcıları güncellemeye yönlendirmelisin. ROI çok düşüktür.

MCP sunucular ise çok daha basittir. Kullanıcılar bir URL’ye bağlanır. Her zaman en güncel versiyonu gösterir. MCP sunucusunu güncellediğimizde, kullanıcılar bir sonraki bağlantıda en yenisini alır. Güncelleme gerekmez. API’ler değişirse, MCP sunucusunda güncellersin.

Çoğu SaaS ürünü zaten sağlam altyapıya sahip: güçlü API’lar ve olgun kimlik doğrulama sistemleri. MCP sunucusu API’nin “AI arayüzü” olarak doğal bir biçimde oturur; tıpkı yönetim panelinin aynı API’lar üzerinde başka bir arayüz olması gibi.

Logto için MCP sunucusu tercihi mimarimize uyuyor ve güçlü kaslarımızı kullanmamızı sağlıyor.

Ayrıca tüm istekleri tek bir giriş noktasında merkezileştiriyor. Log ve denetim daha kolay. Yetkilendirme net: Yapay Zeka yalnızca kullanıcının izin verdiğini yapabiliyor. Bu model kurumsal ve uyum senaryoları için yapısal olarak daha temizdir.

Bir MCP sunucusu geliştirirken karşılaştığımız problemler ve çözümlerimiz#

MCP kusursuz değil. Çoğu sorun ekosistemin olgunlaşmasıyla ilgili. Zamanla düzelecekler. O zamana kadar gerçek ihtiyaçları karşılamak için geçici çözümler üretiyoruz.

Parçalanmış MCP özellik desteği#

MCP standardı birçok özellik tanımlar, fakat istemci desteği değişkendir:

• Araçlar: yaygın destekleniyor
• OAuth: VS Code’da iyi destekleniyor; Cursor gibi araçların köprü olarak mcp-remotea ihtiyacı var
• Diğer özellikler (Kaynaklar, Prompts, Talimatlar): tutarsız destek

Şu anda, araçlar en güvenilir ortak katman (her istemcinin hangi özellikleri desteklediğine bakmak için MCP Topluluk Sayfası'na göz atabilirsin).

Yani stratejimiz basit: araçlar üzerine inşa et.

LLM araçlarını nasıl kullanacağını bilmiyor#

Bu, iş katmanında bir sorun.

Agent Skills ile iş mantığı ve bağlam birlikte paketlenir. LLM nasıl kullanacağını bilir. MCP yalnızca araç sunar. Bağlandıktan sonra LLM şunları bilmez:

• Kullanım senaryoları
• Çağrı sırası
• İş kısıtlamaları

MCP'nin Talimatlar kavramı var, fakat her istemci desteklemiyor. Ayrıca Talimatlar, tüm içeriği bağlantı anında bağlama yükler, bu da gereksiz token harcar.

Bir başka fikir de, talimat rehberini araç açıklamalarına eklemek. Ama burada da iki sorun oluşur:

• Açıklamalar karmaşıklaşır. Çoklu araç iş akışları karışık mantık üretir ve sürdürmek zordur.
• Araç sayısı arttıkça, açıklamalar bağlam penceresinin büyük bir bölümünü tüketir.

Geçici çözümümüz: bir getInstructions aracı sunmak

Fikir basit: Talimatlar iyi desteklenmiyorsa, onu araca dönüştür.

LLM gerektiğinde getInstructions çağırabilir.
Görev A için, getTaskAInstructions çağırır. MCP sunucusu, görevi nasıl tamamlayacağı ve diğer araçlarla nasıl birleştirileceğini anlatan bir prompt döndürür.

Karmaşık iş mantığı talimat araçlarının arkasında kalır. Diğer araçlar sade kalır. Araç açıklamaları sadece kendi fonksiyonuna odaklanır.

Bu, Agent Skills'e benzer: prompt'lar gerektiğinde yüklenir. Ayrıca Talimatları bağlamsal olarak yüklemekten daha verimlidir çünkü her şeyi bağlama yığmak yerine talep üzerine çağrılır.

LLM sırlarını sızdırabilir#

Birçok SaaS ürünü için, bazı sırlar asla ifşa edilmemelidir (ör. client secret, API anahtarları, webhook imzalama anahtarları). Sızarlarsa başkaları seni taklit edebilir ya da kaynağa doğrudan erişebilir.

LLM'lerde risk, sohbetin güvenli bir kanal olmamasıdır. Sohbetler kaydedilebilir, kopyalanabilir, iletilebilir veya hata ayıklama loglarına düşebilir. "Yalnızca ben ve model bunu görebilir" varsayamazsın. LLM’ye uzun ömürlü bir sır vermek veya kullanıcıya kopyalaması için çıkışını istemek, yüksek risktir.

Bu, geleneksel web uygulama entegrasyonlarında da yaygındır: geliştiriciler sıkça bir sır ister, onu sunucu ortam değişkenine veya konfig dosyasına koyar, ardından SDK başlatma gibi adımları tamamlar.

Onboarding’i kolay tutup, sır güvenliğini zayıflatmadan kalmak için üç şey yapıyoruz:

• Entegrasyon sırasında geçici sırlar kullan

  Sohbet tabanlı kurulum sırasında MCP sunucusu yalnızca kısa ömürlü geçici sırlar döner (ör., 1 saat geçerli). Bunlar entegrasyonun çalışması için yeterli ve genelde canlıya geçmeden önce sona eriyor. Canlıya geçmeden önce, geliştirici bunları sohbet dışında uzun ömürlü prodüksiyon sırlarıyla değiştirir.

• Güvenlik sınırını net belirt

  Kullanıcıyı açıkça uyarıyoruz: prodüksiyon sırası oluşturma, yapıştırma veya sohbette kaydetme. Ayrıca geliştiriciyi de uyarıyoruz: ortam değişkenleri ya da konfig dosyaları, bir agent/LLM araçlarla dolaylı şekilde okuyabiliyorsa sızabilir. Prod sırlarını yalnızca AI destekli entegrasyon kullanılmayan ortamlara koy.

• Sohbet ile prod sırlarını yönetme; kullanıcıyı konsola yönlendir

  Uzun ömürlü sırlar sohbette oluşturulmaz veya dağıtılmaz. Konsol kimlik bilgileri sayfasında oluşturulup yönetilir. Sohbette yalnızca doğrudan konsola gidecek bir bağlantı sunuyor ve kullanıcıya prod sır ayarlarını orada tamamlatıyoruz.

MCP araçlarını nasıl tasarladık#

Yolumuz#

Logto’nun tam kapsamlı Yönetim API’si var. İlk fikrimiz basitti: her API endpoint’ini MCP aracı olarak dışa açmak.

Bu fikir hızlıca başarısız oldu.

Birincisi, bağlam patlaması. Logto’da çok fazla API var. Hepsini bire bir eşlemek bağlam penceresini dolduruyor. Her araç açıklaması token’a mal oluyor.

İkincisi, anlam kaybı. API’ler geliştiriciler için atomik yapı taşlarıdır. Ama Logto MCP Sunucu kullanıcıları sistem kurmuyor. Sadece belirli bir işi tamamlamak istiyorlar. Kaç API olduğu umurlarında değil.

Örnek: Logto’da ‘sign-in-experience’ API’si var – markalama, giriş yöntemleri, kayıt yöntemleri, güvenlik politikalarını kapsıyor.
Başta tüm parametreleri LLM’ye nasıl açacağımızı, çağrı kombinasyonunu nasıl öğreteceğimizi düşündük.

Ama bu yanlış bakış açısı. Kullanıcı API çağırmıyor. Markalamayı değiştirmek veya giriş yöntemini ayarlamak istiyor.

Bu nedenle araçlar updateBranding, updateSignInMethod, updateSignUpMethod olmalı. API birleşimini MCP sunucusu kendi içinde halledecek.

Logto MCP Sunucusu bir ürün gibi ele alınmalı, API sarıcı gibi değil. "Bir başka yönetim paneli" gibidir.

MCP aracı nasıl tasarlanır#

Kural netleşiyor:

• Kullanıcılar servisini doğrudan kullanıyorsa (konsol gibi), araçlar işi odaklı (business-oriented) olmalı.
• Başkalarının üstüne kuracağı temel yetenekler veriyorsan, araçlar atomik ve sade olmalı. Örneğin: bir dosya sistemi MCP sunucusunda read_file, write_file; kodlama agent'ları bunları birleştirir.

Ek ilkeler:

• Araç mantığı ve açıklamaları bağlamı korumak için sade tut.
• Karmaşık iş akışları için, rehberi gerektiğinde yükleyecek getInstructions araçları kullan; onların açıklamasını da sade tut.

MCP’nin geleceğine dair beklentilerimiz#

MCP sunucusunu geliştirirken ekosistemi iyileştirebilecekleri de düşündük.

Skill seviyesinde yetenek aktarımı#

Bazen MCP sunucusunun yalnızca araç değil, bunların iş akışına nasıl dönüşeceği konusunda rehberlik de sunması gerekir, tıpkı Agent Skills gibi.

Bu SaaS’ta yaygın. Örneğin GitHub MCP Sunucusu, Logto MCP Sunucusu veya analiz platformları. Kullanıcı atomik çağrı değil iş akışı ister.

getInstructions aracı geçici bir çözüm. Protokol seviyesinde destek daha iyi olurdu.

Oturum (session) seviyesinde MCP etkinleştirme#

İstemciler aynı anda birçok MCP sunucusuna bağlanıyor ancak her oturumda tümüne ihtiyaç yok. Oturum bazlı etkinleştirme/kapama bağlam israfını azaltabilir.

MCP araç çağrılarında bağlam yalıtımı#

Araç çağrıları çok bağlam (context) tüketir. MCP etkileşimleri alt-agent’larca işlenirse, ana sohbet yalnızca özetlenmiş sonucu alabilir.

Sonuç#

Uzaktan MCP sunucusu geliştirme deneyimimiz bu şekilde.

Sen de bu yönde araştırma yapıyorsan, Logto MCP Sunucusu'nu dene veya toplulukla gerçek uygulama deneyimi paylaşmak için Discord'umuza katıl.

Mimari tasarım ve OAuth akış detaylarını da ileride paylaşacağız.