Foundry Agent’a MCP ile Özel Araç Bağlamak
Geçen ay bir finans kuruluşundaki müşterimiz için AI agent mimarisi çizerken, kafamda aynı soru döndü durdu (ben de ilk duyduğumda şaşırmıştım). Agent şirket içi veritabanlarına erişecek, birkaç API çağıracak, sonra da çıkan sonucu kullanıcıya düzgünce anlatacaktı; ilk refleksim şu öldü: mevcut MCP sunucularını Foundry agent’a bağlayabilir mıyız? Cevap evet, hem de beklediğimden daha az uğraştırdı.
📋 İçindekiler
-
OAuth Identity Passthrough: En Güçlü Ama En Karmaşık
Eğer her kullanıcının kendi kimliğiyle MCP araçlarına erişmesi gerekiyorsa — mesela kullanıcı sadece kendi kayıtlarını görebilmeliysa — OAuth passthrough şart oluyor. Agent kullanıcıyı sign-in ettiriyor, aldığı token’ı MCP sunucusuna iletiyor ve MCP tarafı yetkilendirmeyi bu token üzerinden yapıyor.
Ve işler burada ilginçleşiyor.
Logosoft’ta bir bankacılık projesinde bunu uyguladık. Sonuç şaşırtıcıydı diyebilirim; kurulum 3 gün sürdü ama sonrasında kullanıcı bazlı audit trail ve yetkilendirme neredeyse kendiliğinden geldi. İlk kurulum acıtıyor, evet; ama uzun vadede doğru hamle olduğu çok net görülüyor.
Adım Adım: MCP Sunucusunu Foundry Agent’a Bağlama
Peki nasıl bağlıyoruz? Elinizde deploy edilmiş bir MCP sunucusu ve bir Foundry agent olduğunu varsayıyorum. Eğer elinizde henüz MCP sunucusu yoksa Python, TypeScript,.NET ya da Java ile kısa sürede ayağa kaldırabilirsiniz.
Foundry portalında agent’ınızı açın ve Tooling bölümüne gidin. “Add MCP Server” seçeneğine tıklayın. Burada sizden MCP sunucunuzun URL’sını isteyecekler; Azure Functions URL’si buna benzer görünür:
https://<function-app-name>.azurewebsites.net/runtime/webhooks/mcp/sseKullandığınız authentication yöntemine göre gerekli bilgileri giriyorsunuz. Function key kullanıyorsanız header’a
x-functions-keyolarak key’i eklemek yeterli oluyor; Entra ID tarafında işe App Registration bilgilerini. Scope’ları tanımlamanız gerekiyor.Bunun ardından bağlantı kuruluyor ve agent MCP sunucunuzdaki araçları otomatik keşfediyor. Bu kısım gerçekten ilginç; agent hangi araçların mevcut olduğunu görüyor, description alanından ne işe yaradığını anlıyor (ciddiyim). Kullanıcı sorusu geldiğinde hangisini çağıracağına karar veriyor.
💡 Bilgi: MCP sunucunuzdaki tool descriptions alanını ne kadar düzgün yazarsanız agent o kadar işabetli karar veriyor.
“Veritabanını sorgular” yerine “Müşteri tablosunda sipariş geçmişini tarihe göre filtreler” gibi net açıklamalar yazın.Türkiye’deki Şirketler İçin Pratik Öneriler
Bunu Türkiye’deki şirketler açısından düşününce birkaç nokta öne çıkıyor. İlk konu veri lokasyonu meselesi. Foundry projesi West Europe ya da başka bir bölgede olabilir ama MCP sunucunuzu barındıran Azure Functions’ı Türkiye’ye yakın bir region’a (mesela West Europe veya France Central) koymak latency açısından mantıklı dürüyor; çünkü henüz Azure’un Türkiye region’u yok. Bu konu ayrı bir tartışma başlığı zaten.
Maliyet tarafında işe Azure Functions Consumption planındaki ilk 1 milyon çağrı ücretsiz geliyor ve bir MCP sunucusu için başlangıçta baya yeterli oluyor bu rakamlar. TL bazında düşündüğünüzde aylık 200-300 TL civarında ciddi sayılabilecek bir AI agent altyapısı kurabiliyorsunuz. Tabi model maliyeti ayrı mesele — GPT-4o token bazlı ücretleniyor — ama MCP sunucusu kısmı gerçekten ucuz kalıyor. Hani ne farkı var diyorsunuz, değil mi? Daha detaylı maliyet hesabı için
Bir de şu var: MCP sunucusunda birden fazla araç tanımlıysa isimleri fazla genel tutmayın. “getData” gibi isimler agent’i sasirtabiliyor. “getCustomerOrderHistory” gibi spesifik isimler çok daha iyi sonuç veriyor. Bunu deneye deneye öğrendim; ilk versiyonda agent sürekli yanlış aracı çağırıyordu.
Ayrıca Foundry agent’larının MCP araçlarıyla etkileşimi konusunda Foundry Local GA Öldü: Bulut Olmadan Yerel AI yazısına da göz atmanızı öneririm — yerel geliştirme ortamı kurarken isiniza yarayacak notlar var orada (kendi tecrübem)
Bence Bu Doğru Yönde Ama Eksikler Var
Toptan baktığımda MCP + Foundry + Azure Functions üçlüsü baya iş gören bir kombinasyon oluyor. Ama birkaç şey beni rahatsız ediyor, açık konuşayım. Birincisi debugging meselesi: Agent MPC aracını çağırınca ortalık karışırsa hatanın nerede patladığını bulmak zorlaşıyor; sorun agent tarafında mı, Functions’ta mı, yoksa protocol katmanında mı? Uçtan uca trace’leme hâlâ istediğim seviyede değil.
İkinci konu SSE bağlantısının güvenilirliği. Uzun süre açık kalan bağlantılarda kopmalar olabiliyor, bu da agent’ı ortada bırakabiliyor. Microsoft’un bunun üstünde çalıştığını biliyorum ama şu an sistem biraz ham dürüyor. Biraz daha pişmesi lazım.
Üçüncüsü — beni en çok geren kısım burası — dokümantasyon. Her şey ayrı sayfalara dağılmış durumda;MCP ayrı,Functions ayrı,Foundry ayrı. Uçtan uca tek parça bir rehber pek yok. Bu yazıyı biraz da o boşluğu doldurmak için kaleme aldım aslında.
İlgili: Bu konunun Microsoft tarafındaki resmi karşılığını anlamak için Microsoft Agent Framework 1.0: Ajanlar Artık Ciddileşti yazımıza bakabilirsiniz — agent framework’ün üretimde nasıl konumlandığını detaylı anlatıyor.Sıkça Sorulan Sorular
MCP sunucusunu Azure Functions dışında başka yerde çalıştırabilir mıyım?
Evet, Container Apps, App Service ya da herhangi bir HTTP endpoint’te barındırabilirsiniz. Ama aslında Azure Functions’ın serverless fiyatlandırması ve built-in auth desteği ciddi avantaj sağlıyor. Bence küçük-orta ölçekli projeler için en maliyet-etkin seçenek genellikle Functions oluyor.
Foundry agent birden fazla MCP sunucusuna bağlanabiliyor mu?
Evet, bir agent’a istediğiniz kadar MCP sunucusu ekleyebilirsiniz. Agent, hani tüm sunuculardaki araçları otomatik keşfediyor ve ihtiyaca göre hangisini çağıracağına kendisi karar veriyor. Mesela ben bir projede 3 farklı MCP sunucusu bağladım — veritabanı, e-posta ve dosya sistemi için ayrı ayrı kullandım, gayet güzel çalıştı.
Function key authentication production ortamında güvenli mi?
Açıkçası hayır, production için pek önerilmiyor. Function key yanı paylaşılan bir sır gibi çalışıyor; rotate etmek ve güvenli saklamak tamamen sizin sorumluluğunuza kalıyor. Tecrübeme göre production ortamları için Microsoft Entra ID tabanlı authentication’a geçmenizi büyük ihtimalle tavsiye ederim.
Cold start problemi agent performansını nasıl etkiliyor?
Doğrusu, Consumption planında ilk çağrı 3-5 saniye gecikebiliyor. Bu sürede agent timeout alabilir, yanı işler biraz karışabiliyor. Premium plan kullanarak ya da periyodik warm-up çağrıları yaparak bu sorunu aşabilirsiniz. Kritik production workload’larında bence Premium plan çok daha güvenli bir seçim.
Evet, doğru duydunuz.
MCP sunucusunu Python dışında başka dillerle de yazabilir mıyım?
Tabiî ki! Azure Functions üzerinde MCP sunucusu Python, TypeScript/Node.js,.NET (C#) ve Java ile yazılabiliyor. Hani her dil için Microsoft’un hazır şablonları da mevcut. Ekibinizin ne bildiğine göre seçim yapın, zaten hepsi aynı MCP protokolünü destekliyor.
Kaynaklar ve İleri Okuma
Give your Foundry Agent Custom Tools with MCP Servers on Azure Functions — Azure SDK Blog
Azure Functions MCP Bindings — Microsoft Learn
Microsoft Foundry Agents Overview — Microsoft Learn
Aşkın KILIÇYazar20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Berk N.
MCP entegrasyonunu Azure Functions üzerinde serverless kurmanın maliyeti nasıl etkiliyor tam merak ediyordum, kurum içi veritabanlarıyla konuşturmak gerçekten pratik görünüyor. Biz şu an benzer bir şeyi REST API üzerinden manuel yapıyoruz ama bu yaklaşım çok daha temiz.
Serkan D.
MCP entegrasyonunu Azure Functions üzerinden serverless yapmak gerçekten akıllıca bir yaklaşım, maliyeti düşünmek şart çünkü agent’lar sürekli ayakta durmak zorunda değil. Peki kimlik doğrulama tarafında Managed Identity mi kullandınız, yoksa başka bir yol mu tercih ettiniz?
Gökhan İ.
Tam aradığım şeydi bu, teşekkürler. Biz de dahili bir envanter sistemini agent’a bağlamaya çalışıyoruz, Azure Functions tarafını merak ediyordum özellikle. Serverless kurulumda cold start süresi sorun çıkarıyor mu acaba?
Deniz R.
Azure Functions üzerinden serverless kurulum kısmı çok işe yarar, özellikle maliyeti kontrol altında tutmak isteyenler için. Veritabanı entegrasyonunu merak edenler için de şu yazıya bakmaları iyi olur: SQL MCP Server: Veritabanını Ajanlara Açmanın Yolu — https://www.askinkilic.com.tr/sql-mcp-server-veritabanini-ajanlara-acmanin-yolu/ Peki kimlik doğrulama tarafında Managed Identity mi öneriyorsunuz, yoksa başka bir yol mu izlediniz?
Yorumlar kapalı.
4 comments