Azure Functions MCP Extension Build 2026: Yenilikler ve Saha Notları
Vallahi, Microsoft Build 2026 bitti, ben de kafamda kalanları toparlamaya çalışıyorum. Açık konuşayım, bu yılki duyurular içinde en çok dikkatimi çeken şey, herkes Foundry. Agent Framework tarafını konuşurken biraz arada kalan Azure Functions MCP Extension güncellemeleri öldü. Neden mi? Çünkü kurumsal müşterilerde son altı ayda önüme en çok çıkan soru şu: “Bu MCP server denen şeyi production’a nasıl koyacağız, kim host edecek, auth ne olacak?”
Cevap, en azından Microsoft tarafında, yavaş yavaş netleşiyor: Functions üzerinde. Evet.
Bu yazıda hem yeni gelen özelliklere bakacağım, hem de — bence asıl mesele bu — bunların Türkiye’deki kurumsal projeler için ne ifade ettiğini konuşacağım. Teknik doküman zaten Microsoft Docs’ta dürüyor, oradan açıp okursunuz; benim derdim biraz başka,. Işin sahadaki karşılığı. Neyse, peki neden?
Önce işin özüne inelim: MCP server’ı kim host edecek?
Model Context Protocol, yanı MCP, etrafında dönen kafa karışıklığını ben de çok görüyorum. Aslında mesele basit; bir AI agent ile araçlar ya da veri katmanı arasında standart bir köprü kuruyorsunuz,. Işin içine “server” tarafı girince konu bir anda uzuyor, biraz da dağılıyor açıkçası.
Ve burada düğüm atılıyor. Container’a mı koyacaksın? App Service mi daha mantıklı? Kubernetes mi devreye girecek, yoksa şey, direkt serverless mi diyeceğiz? Peki neden bu kadar seçenek var?
Azure Functions MCP Extension bence bu soruya gayet net bir yerden yaklaşıyor: serverless. Hani çok süslü bir fikir gibi durmuyor ama baya iş görüyor; çünkü MCP server’lar çoğu zaman event-driven çalışıyor, agent gelir tool çağırır, sonra ortalık sakinleşir (hatta uzun süre hiçbir şey olmaz), Functions da tam burada oturuyor. Üstelik scale-to-zero sayesinde, kullanılmadığı zamanlarda boş yere para da akmıyor.
MCP server’ı kendi VM’inizde host etmek, 2010’da WCF servisini IIS’te tutmaya benziyor. Çalışır, evet. Ama bakım yükü, scaling, auth, log aggregation — hepsi sizin başınızın belası olur. Functions tarafında bu yüklerin çoğu zaten halledilmiş durumda.
Build 2026’da ne değişti?
İlk preview çıktığında iş biraz dar bir çerçevedeydi. Sadece tool trigger vardı, yanı bir fonksiyonu MCP tool gibi expose edebiliyordunuz, o kadar. Şimdi durum değişmiş, baya açılmış.
Ve işler burada ilginçleşiyor.
Tüm MCP primitive seti tamamlandı
Artık üç temel MCP primitive’ının üçü de destekleniyor:
- Tool triggers — fonksiyonu çağrılabilir bir araç olarak sunuyor. Agent “şu hesabı kapat” diyor, sizin fonksiyon çalışıyor.
- Resource triggers — fonksiyonu okunabilir bir context kaynağı gibi veriyor. Dosya içeriği, DB şeması, UI bileşeni… agent karar vermeden önce bilmesi gereken şeyler bunlar.
- Prompt triggers — istemci, sizin sunucudan hazır prompt template’leri alıyor. Bu kısım çok sık kullanılmıyor gibi dürüyor ama enterprise tarafta fena iş görür. Çünkü “prompt yönetimi” dediğimiz mevzu, çoğu kurumsal projede şu an bir Confluence sayfasında dönüyor. Trajik biraz.
Tuhaf ama, Üçü de.NET, Java, Python, TypeScript ve JavaScript’te çalışıyor. Çoklu dil desteğinde Microsoft bu kez geç kalmamış; açık konuşayım, bu hoşuma gitti. Normalde ilk.NET gelir, Java biraz kenarda bekler, sonra biz müşteriye “biraz daha sabredin” deriz. Burada öyle olmamış.
MCP Apps: tool’lar artık UI dönebiliyor
Peki burada asıl ilginç olan ne? MCP Apps, tool çağrılarının düz metin yerine interaktif UI bileşenleri döndürmesine izin veriyor. Tool trigger ile resource trigger’ı birlikte kullanıp agent’a sadece “işi yaptım” demek yerine, render edilebilir bir arayüz de verebiliyorsunuz.
Bunu daha önce
Neyse, çok dağıttım gibi öldü. Konu yine aynı yere çıkıyor: kurumsal tarafta teknoloji hazır olsa bile kurumun olgunluğu hazır olmayabiliyor. Sız ne dersiniz? En çok da büyük yapılarda önce eğitim mi lazım, yoksa direkt küçük bir PoC ile mi başlamak daha mantıklı? Bu kadar mı? Değil tabiî. Başlangıç için bence en sağlıklı yol bu.
Maliyet analizi: ne kadar tutar?
Azure Functions üzerinde MCP server host etmenin maliyeti, seçtiğiniz plana göre epey değişiyor. Kabaca bakınca tablo netleşiyor, ama işin içine trafik, çalışma süresi. Küçük gibi görünen ek kalemler girince hesap bir anda kayıyor; yanı “ucuzdur” demek de, “kesin pahalıdır” demek de biraz sallama olur.
| Plan | Tipik Kullanım | Aylık Tahmini (~) | Notlar |
|---|---|---|---|
| Consumption | PoC, düşük trafik | 0 — 500 TL | Scale-to-zero, soğuk başlangıç var |
| Flex Consumption | Orta seviye prod | 2.000 — 8.000 TL | Daha hızlı scale, VNet entegrasyonu |
| Premium | Yüksek trafik, düşük latency | 15.000 TL ve üzeri | Always-on instance, soğuk başlangıç yok |
Consumption tarafı PoC için baya iş görüyor. Hatta çoğu senaryoda başlangıçta başka bir şeye gerek bile kalmıyor. Ama dur bir saniye — soğuk başlangıç mevzusu bazen can sıkabiliyor, özellikle kullanıcı tarafında ilk istek bekleyince insanın morali bozuluyor; yine de düşük trafikliyse bu bedel gayet kabul edilebilir.
Flex Consumption işe bana daha dengeli geliyor. Hem maliyet hâlâ makul kalıyor hem de prod ortamında elinizi biraz rahatlatıyor (özellikle VNet entegrasyonu lazım olduğunda), (yanlış duymadınız). Tabiî burada da “her derde deva” diye bakmamak lazım. E sonra? Trafik yükseldikçe fatura da sessizce yukarı tırmanıyor.
Premium kısmı? Açık konuşayım, ancak gerçekten ihtiyacınız varsa mantıklı. Yüksek trafik, düşük latency beklentisi ve always-on çalışma isteği varsa tamam, ama sırf “garanti olsun” diye oraya atlamak gereksiz pahalıya kaçabiliyor; ben olsam önce daha hafif planlarda denerim.
Rakamlar yaklaşık değerlerdir; USD/TL kuru ve gerçek tüketim hesabı değiştirebilir. Ama genel resmî görmek için yeterli. Benim pratik yaklaşımım şu: PoC’i Consumption ile açın, iş oturmaya başlayınca Flex Consumption’a geçin, Premium’a işe ancak gerçekten latency derdiniz varsa bakın. Tam da öyle.
Küçük ekip vs büyük kurum: hangisi neyi yapmalı?
İtiraf edeyim, Bu ayrımı ciddiye alıyorum, çünkü sahada iş biraz böyle bölünüyor. Küçük ekipte hız var, büyük kurumda işe onay kuyruğu var; ikisi de ayrı dert, açık konuşayım.
Küçük ekip / startup iseniz: Ben olsam doğrudan Consumption planında bir tool ile başlarım. Auth’u ilk anda atlayabilirsiniz, hatta private endpoint arkasına koyup bir süre öyle götürmek çoğu senaryoda iş görüyor; MCP server ayağa kalktıktan sonra Entra ID entegrasyonunu eklersiniz, resource ve prompt trigger’ları da sistem oturduktan sonra devreye alırsınız. Önce minimal, sonra zenginleştir — yanı işin aslı bu.
Büyük kurumsal yapıdaysanız: Burada tersine dönüyor iş. Auth ve OBO flow’u en başta masaya koymak lazım, çünkü güvenlik onayı bazen teknik kısmın önüne geçiyor ve orada zaman kaybediyorsunuz. Pilot tool basit kalsın, mesela read-only bir sorgu yeter; ama altyapı tarafı production-grade olsun: VNet integration, private endpoint, Key Vault entegrasyonu, Log Analytics, distributed tracing… hepsini gün bir düşünün. Hani biraz fazla mı geldi? Belki. Ama sonra geri dönüp yamamak daha yorucu oluyor. Bu arada Microsoft Agent Framework: Katmanlı SDK Tasarımının İç Yüzü yazısındaki katmanlı yaklaşım da fena olmayan bir mental model veriyor.
Evet.
Eksik bulduğum yerler
Her şeyi övecek değilim. Birkaç noktada canım sıkıldı.
Hani, Bir, dokümantasyon hâlâ dağınık (şaşırtıcı ama gerçek). MCP spec’i bir yerde dürüyor, Functions extension başka tarafta, Azure Apps blog’unda ayrı örnekler var, GitHub’da da farklı sample’lar dönüyor; yanı yeni başlayan biri için “nereden başlasam?” sorusu boşlukta asılı kalıyor, açık konuşayım Microsoft’un bir MCP on Functions: Getting Started landing page’ine gerçekten ihtiyacı var.
İki, observability tarafı biraz zayıf kalmış. MCP çağrılarının trace’ını Application Insights’ta görmek mümkün, evet, ama “hangi tool çağrıldı, hangi resource döndü, OBO token kimden geldi” gibi MCP’ye özel sorgular için custom dashboard kurmanız gerekiyor; hani iş görüyor ama built-in bir MCP monitöring view bekliyordum, gelmedi (şaşırtıcı ama gerçek)
Üç, MCP Apps tarafı kağıt üstünde baya iyi dürüyor ama hangi client’ın hangi UI’ı render edebildiği konusunda standart henüz oturmadı. Bir tool yazıyorsunuz, Copilot Chat’te güzel görünüyor, başka bir client’ta hiç görünmüyor; o yüzden bu iş biraz daha olgunlaşana kadar UI dönmek yerine markdown’da kalmak daha güvenli gibi.
İşte tam da bu noktada devreye giriyor.
Aksiyon planı: nereden başlamalı?
Eğer MCP tarafına Functions üzerinden girecekseniz, ben olsam işi şöyle başlatırım:
- aka.ms/remote-mcp reposundan dilinize uygun sample’ı alın..NET var, Python var, TypeScript de var; yanı seçenek böl, kafa karıştırıyor ama kötü değil. (bu kritik)
- Local’de çalıştırın.
func startile elinizde çalışan bir MCP server oluyor, ilk bakışta basit dürüyor ama işin tadı orada çıkıyor. - MCP Inspector ya da Claude Desktop ile bağlanıp tool’ları çağırın. Önce protokolün nasıl nefes aldığını görün, sonra gerisi daha net geliyor.
- Kendi tool’unuzu ekleyin — mümkünse domain’inizden minicik bir şey. Mesela “sipariş durumunu sorgula” gibi; küçük başlayın, yoksa konu dağılıyor.
- Azure’a deploy edin. Önce auth’suz deneyin, sonra Entra ID ekleyin; bu geçiş ilk anda biraz uğraştırıyor, ama yapılabiliyor.
- OBO flow’a en son geçin. Çünkü en çetrefilli yer orası, açık konuşayım.
Bu sırayı izlerseniz, bir hafta içinde eli yüzü düzgün bir MCP server ayağa kaldırırsınız. Daha önce bu tip entegrasyonlar yapanlar için çok yabancı bir yol değil aslında; sadece protokolün adı değişmiş oluyor (kendi tecrübem)
Doğrusu, Peki neden böyle? Çünkü önce zemini görmek lazım. Hemen kimlik doğrulama ve OBO’ya dalarsanız, işler gereksiz yere düğümleniyor.
Vallahi, Evet.
Bence, Benim gördüğüm kadarıyla en sağlıklı yaklaşım bu. Biraz sade ilerleyin, sonra güvenlik katmanını ekleyin (özellikle Entra ID tarafında), en sonda da OBO’yu oturtun; o zaman hem neyin kırıldığını daha kolay anlarsınız hem de debug ederken saç baş yoldurmaz.
Sıkça Sorulan Sorular
MCP server’ı illâ Azure Functions’ta mı host etmem lazım?
Ne yalan söyleyeyim, Hayır, hiç gerek yok (ki bu çoğu kişinin gözünden kaçıyor). MCP açık bir protokol,. Herhangi bir runtime üzerinde çalıştırabilirsiniz: Container Apps, AKS, kendi VM’ınız, hatta on-premise bir sunucu bile olur. Functions, aslında sadece serverless. Event-driven senaryolarda işleri kolaylaştıran bir abstraction katmanı sunuyor — ama zorunlu değil.
MCP Apps gerçekten production’a hazır mı?
Açık konuşayım, Server tarafı, yanı Functions extension, hazır sayılır. Ama client tarafındaki render desteği henüz tam olgun değil. Mesela UI dönen bir tool yazsanız bile, hangi client’ın bunu doğru render edeceği konusunda garantiniz yok (en azından benim deneyimim böyle). Bence şimdilik markdown veya yapılandırılmış JSON dönen tool’larla gitmek çok daha güvenli bir tercih.
İşte tam da bu noktada devreye giriyor.
OBO flow tam olarak ne işe yarıyor, neden bu kadar önemli?
On-Behalf-Of flow, MCP tool’unuzun çağıran kullanıcının kimliğiyle aşağıdaki API’lere erişmesini sağlıyor. Yanı agent, sadece o kullanıcının görme yetkisi olan veriye ulaşabiliyor — başkasına ait hiçbir şeye dokunamıyor. Bu, “agent her şeyi görebilir” güvenlik sorununun temel çözümü aslında. Kurumsal projelerde tecrübeme göre olmazsa olmaz bir şey.
Türkiye’den Azure West Europe’a bağlanan MCP server’ın latency’si sorun olur mu?
Şahsen, İstanbul’dan West Europe’a tipik latency 35-50 ms civarında geziyor. Tool çağrıları genelde tek seferlik request/response olduğu için bu rakam pratikte pek sorun yaratmıyor. Ama streaming senaryolarda dikkatli olun. North Europe biraz daha yüksek, hani 45-65 ms gibi. Türkiye region’ları açıldığında bu rakam 10 ms’nın altına inecek, açıkçası o zaman çok daha rahat ederiz (şaşırtıcı ama gerçek)
Hangi dili seçmeliyim:.NET mi Python mı?
Tool’larınız ağırlıklı olarak veri işleme veya ML modeli çağırma gibi şeyler yapacaksa Python zaten doğal bir tercih. Kurumsal entegrasyon. Business logic ağırlıklı işler için işe.NET çok daha güçlü bir tooling sunuyor — yeni fluent builder API mesela gerçekten kullanışlı. Karma ekiplerde bence TypeScript de gayet iyi bir orta yol.
Kaynaklar ve İleri Okuma
Azure SDK Blog: Functions MCP Updates at Build 2026 — Lily Ma’nın orijinal duyuru yazısı, teknik detayları içeriyor.
Azure Functions Resmî Dokümantasyonu — Trigger. Binding modelini iyi anlamak için temel kaynak.
Bakın, Model Context Protocol Spesifikasyonu — Protokolün kendisini derinlemesine anlamak isteyenler için (evet, doğru duydunuz)
Bunu yaşayan biri olarak söyleyeyim, aka.ms/remote-mcp Sample Repository — Birden fazla dilde hazır örnekler. Klonlayıp başlamak için ideal.
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.
2 comments