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ı.
Bakın, MCP (Model Context Protocol) sunucusu zaten VS Code’da, Cursor’da falan kendine yer buldu. Ama işin tadı, bu sunucuları bir AI agent’ın arkasına koyunca çıkıyor; agent düşünüyor, plan yapıyor, hangi aracı ne zaman çağıracağını kendi seçiyor. Sız sadece araçları tanımlıyorsunuz. Geri kalanını o toparlıyor.
MCP Sunucusu Neden Azure Functions Üzerinde?
Neden Azure Functions? Çünkü serverless olunca iş değişiyor. Aylık sabit sunucu parası yok, kullandığın kadar ödüyorsun; Türkiye’deki kurumsal müşterilerimde gördüğüm kadarıyla, özellikle AI yatırımının geri dönüşünü henüz net kanıtlayamayan ekipler için bu baya önemli bir avantaj. “Biz daha deneme yapıyoruz, her ay 500 dolar sabit fatura istemiyoruz” diyen ekip sayısı az değil. Functions tam burada devreye giriyor.
Evet, doğru duydunuz.
Eh, Bir de built-in authentication tarafı var, o da fena değil. Entra ID entegrasyonu, function key’ler, OAuth… Hepsi kutudan çıktığı gibi geliyor (ben de ilk duyduğumda şaşırmıştım). Geçen yıl bir e-ticaret şirketinde MCP sunucusu kurarken authentication kısmını 2 saatte bitirdik; kendi başımıza nginx reverse proxy üstüne JWT validation yazsaydık, en az bir hafta giderdi. Hatta muhtemelen daha da uzardı (ki bu çoğu kişinin gözünden kaçıyor)
Ama dürüst olayım: Functions’ın cold start meselesi hâlâ can sıkabiliyor. Premium plan kullanmıyorsanız ilk çağrıda 3-5 saniyelik gecikme görebiliyorsunuz. Agent tarafında bu gecikme timeout’a dönüşebilir. Ben bunu yaşadım; çözümü birazdan geleceğim yerde anlatacağım.
Foundry Agent ile MCP: Büyük Resim
Bi saniye — Microsoft Foundry, AI agent’lar kurmak için kullanılan bir platform. Agent’ınız bir model üzerinde çalışıyor — GPT-4o mu kullanırsınız, GPT-4.1 mini mi seçersiniz, orası size kalmış —. Model tek başına yetmiyor. Dış dünyaya dokunması lazım. İşte MCP sunucusu burada sahneye çıkıyor.
Şöyle düşünün: agent beyinse MCP sunucusu eller gibi davranıyor. Veritabanını sorgula, API çağır, dosya oku, hesaplama yap… Agent bu araçları keşfediyor, hangisini ne zaman kullanacağını tartıyor ve sonucu kullanıcıya geri veriyor. Kağıt üstünde iyi dürüyor; pratikte de çoğu zaman gayet iş görüyor.
MCP sunucunuzu bir kere yazdığınızda hem IDE’lerden hem de Foundry agent’larından kullanabilirsiniz. Aynı kodu iki farklı yerde koşturmak — işte asıl yeniden kullanılabilirlik bu.
Ha, burada küçük bir not düşeyim: daha önce Azure MCP Araçları Visual Studio 2022’de Yerleşik Geldi yazısında MCP’nın IDE tarafını anlatmıştım. Neden önemli bu? Şimdi konuyu agent tarafına taşıyoruz; yanı sahne biraz büyüdü (bizzat test ettim)
Authentication Seçenekleri: Hangisi Ne Zaman?
Şöyle ki, Bu bölüm bazen kafa karıştırıyor, o yüzden tabloyu direkt koyuyorum. Müşterilerime de genelde bunu gösteriyorum:
| Yöntem | Ne Zaman Kullanmalı? | Güvenlik Seviyesi | Kurulum Zorluğu |
|---|---|---|---|
| Function Key (Varsayılan) | Geliştirme, PoC aşaması | Orta | Kolay |
| Microsoft Entra (Agent Identity) | Production ortamları | Yüksek | Orta |
| Microsoft Entra (Project Managed Identity) | Sadece geliştirme | Orta-Yüksek | Orta |
| OAuth Identity Passthrough | Kullanıcı bazlı erişim gereken production | Çok Yüksek | Zor |
| Unauthenticated | Sadece public veri, geliştirme | Yok | Çok Kolay |
Açık konuşayım: Türkiye’deki çoğu kurumsal müşteri doğrudan Entra ID istiyor. Bankacılıkta da böyle, sigortada da böyle, telekomda da böyle — “function key ile production’a çıkalım” cümlesi genelde kapıdan dönüyor (eh, fena değil). Haklılar mı? Evet, büyük ölçüde haklılar. Function key’i paylaşılan şifre gibi düşünün; biri ele geçirirse büyük çoğunluk MCP araçlarınıza erişebilir.
Function Key ile Hızlı Başlangıç
Geliştirme aşamasındaysanız en kolay yol bu (evet, doğru duydunuz). Azure Functions’ınızı deploy — itiraz edebilirsiniz tabi — ettikten sonra function key’i alıp Foundry agent’a tanımlıyorsunuz; birkaç dakika içinde bağlantı hazır oluyor. Ama — bunu özellikle söylüyorum — bu key’i sakın GitHub’a commit etmeyin. 2023’te bir müşteride tam olarak bunu gördük; key repo’ya girmişti ve biz 3 gün sonra fark ettik. Neyse ki ciddi hasar olmadı ama herkesin yüzü bembeyaz öldü.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Entra ID ile Production Kurulumu
Bunu yaşayan biri olarak söyleyeyim, Production’a çıkacaksanız agent identity kullanın. Agent kendi managed identity’siyle MCP sunucusuna bağlanıyor; arada token exchange dönüyor ve kullanıcı hiçbir şey hissetmeden iletişim güvenli şekilde akıyor.
Araya gireyim: Hmm… bir de project managed identity var tabiî ama önü production’da ben önermem. Çünkü o kimlik tüm Foundry projesine ait oluyor; yanı projedeki bütün agent’lar aynı identity’yi paylaşıyor. Least privilege açısından bakınca bu pek hoş değil. Her agent’ın ayrı kimliği olması daha doğru geliyor. Copilot CLI’da Auto Model Seçimi: Ne İşe Yarıyor? yazımızda bu konuya da değinmiştik.
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. Bu konuyla ilgili MSVC 14.51 RC Çıktı: Derleyici Tarafında Neler Var? yazımıza da göz atmanızı tavsiye ederim.
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-key olarak 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.
“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 Bulut Maliyet Optimizasyonu: Hâlâ Geçerli Prensipler yazısına bakabilirsiniz.
Küçük ekipseniz (startup ya da 3-5 kişi gibi), function key ile başlayın derim. Hızlıca prototype çıkarın, demo gösterin, yatırımcıyı ikna edin. Sonra production’a geçerken Entra ID’ye taşırsınız. Büyük kurumsal yapılarda işe en baştan Entra ID ile başlamak daha doğru olur; güvenlik ekibi zaten function key’e sıcak bakmaz (evet, doğru duydunuz)
Karsilaştigim Sorunlar ve Çözümleri
Bunu ilk denediğimde SSE (Server-Sent Events) bağlantısında timeout hatası aldım. MCP sunucusu Functions Consumption planında çalışıyordu ve cold start 4-5 saniye sürüyordu; agent tarafı işe bu kadar bekleyemiyordu.
Çözüm basit değildi. Netti: iki seçenek var — ya Functions Premium plan’a geçip always warm instance kullanırsınız ya da warm-up endpoint ekleyip periyodik ping atarsınız (evet, doğru duydunuz). Ben ikinci yolu seçtim; Logic Apps ile her 5 dakikada bir health check çağrısı yaptırıyorum. Ucuz,sessiz,işe yarıyor. Kubernetes AI Gateway WG: AI Trafiği Artık Standart yazımızda bu konuya da değinmiştik.
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.
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
20+ 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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
4 comments