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.

Yeni.NET fluent builder API: kod nasıl görünüyor?

.NET tarafına yeni bir fluent builder API gelmiş. NuGet’in son sürümünde varmış, ben de bakınca kodun biraz daha toparlandığını gördüm. Hani ilk izlenim şu: daha az gürültü, daha çok niyet.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

// Klasik trigger tabanlı tanım yerine,
// MCP App'i fluent şekilde compose edebiliyorsunuz
var app = builder.Services.AddMcpApp("invoice-helper")
.WithTool<GetInvoiceTool>()
.WithTool<ApproveInvoiceTool>()
.WithResource<InvoiceUiResource>()
.WithPrompt<ApprovalPrompt>()
.WithAuth(opts =>
{
opts.UseEntraId();
opts.RequireScopes("Invoice.Read", "Invoice.Approve");
});

Hani, Bak şimdi, ben fluent API’lere genelde mesafeli yaklaşırım. Debug ederken insanı biraz yoruyor, stack trace uzuyor, bazen de zincirin neresinde patladığını bulmak için gereksiz yere ekranla kavga ediyorsun — itiraf edeyim, beklentimin üstündeydi —. Ama burada durum farklı gibi, çünkü MCP zaten composition mantığıyla ilerliyor. Bu tarz bir akış oraya baya oturuyor.

İlk denediğimde IntelliSense desteği de idare ederdi. Evet, öyle aman aman bir sihir yok ama yeterince yol gösteriyor. Bir yerde durup “şey, buraya ne ekliyorduk?” demiyorsun en azından.

Açıkçası bu tip API’lerde en sevdiğim şey, niyetin koddan hemen okunması. Yine de kusursuz değil tabiî; zincir uzadıkça göz yorulabiliyor (özellikle auth kısmında), ama klasik dağınık kayıt yapısına göre daha derli toplu durduğu da ortada.

Türkiye’deki kurumsal projeler açısından durum nedir?

Şimdi asıl yere gelelim. Bütün bu yenilikler güzel, hatta baya ilgi çekici,. Türkiye’de bunu kim kullanacak, nasıl kullanacak, işte orası biraz karışık. Peki neden? Çünkü teori ayrı, saha ayrı; bir de üstüne regülasyon, veri yerelliği (evet, doğru duydunuz). Bütçe baskısı binince tablo hemen değişiyor.

Bankacılık ve finans: temkinli ama meraklı

BDDK regülasyonu ve veri yerelliği kaygıları yüzünden, finans kurumlarında MCP konuşmaları şimdilik “pilot proje” çizgisinde dolaşıyor. Görüştüğüm ekiplerin çoğu, MCP server’ı Azure West Europe ya da North Europe yerine, ileride açılması beklenen Türkiye region’larında host etmeyi tercih ediyor; yanı mesele teknikten çok biraz da bekleme hali, hani herkes hazır ama kimse ilk adımı tam basamıyor.

İlginç olan şu ki, Yine de Functions üzerinde MCP host etmenin fena olmayan bir tarafı var: aynı kodu, aynı mantıkla, Türkiye region açıldığında oraya taşıyabiliyorsunuz. Şimdi PoC’i Batı Avrupa’da yapıp sonra Türkiye’ye geçirmek teknik olarak oldukça rahat; açık konuşayım, mimariyi baştan buna göre kurmazsanız sonra ufak bir iş gibi görünen şey uzayıp gidiyor. Evet.

Bir dakika — bununla bitmedi.

Perakende ve e-ticaret: en hızlı benimseyen segment

Perakende tarafında işler daha farklı akıyor. Burada hız önemli, regülasyon yükü de finans kadar ağır değil; o yüzden MCP server’ı katalog sorguları, stok kontrolü. Fiyat hesaplama gibi işlerde kullanmak baya iş görüyor. Bir tool, bir resource, biraz prompt template derken, nasıl desem, bir haftada ayağa kalkabilecek bir prototip çıkarabiliyorsunuz; hatta bazen ekip kendi kendine şaşırıyor.

Az önce hızlı dedim ama aslında kritik nokta hızdan çok deneme cesareti. Çünkü perakendede kullanıcı davranışı çabuk değişiyor (kampanya var, stok bitiyor, fiyat oynuyor), MCP de tam bu tür dalgalı senaryolarda işe yarıyor; yanı işi çok süslü hâle getirmeden çözebiliyorsunuz. Bir bakıma, tam da öyle.

Kamu ve büyük kurumsal: “MCP nedir?” aşaması

Kamu kurumlarında durum biraz daha geriden geliyor. Önce “AI agent nedir?” sorusunu cevaplıyoruz, sonra “neden MCP?” sorusuna geçiyoruz. Zincirin başı daha yeni kuruluyor. Bu yüzden kamu projelerinde bu yıl ciddi MCP adopsiyonu beklemiyorum, hatta dürüst olayım 2027 bana daha gerçekçi geliyor (tabi bu tahmin %100 doğru olmayabilir ama mevcut ritim öyle söylüyor).

Durun, bir saniye. Copilot CLI’ın Yeni Terminal Arayüzü GA: Sekmeler Devri Başladı yazımızda bu konuya da değinmiştik. Daha fazla bilgi için OpenAI ve Broadcom’dan Jalapeño: LLM’e Özel Çip Geliyor yazımıza bakabilirsiniz.

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.

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. Bu konuyla ilgili 2026 ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.

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. Bu konuyla ilgili JetBrains Copilot Artık CLI Üzerinde Çalışacak: Ne Değişiyor? yazımıza da göz atmanızı tavsiye ederim.

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. Daha fazla bilgi için GitHub Copilot Modernization C++ İçin GA: MSVC Yükseltmesi Artık Kolay yazımıza bakabilirsiniz.

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:

1. 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)
2. Local’de çalıştırın. func start ile elinizde çalışan bir MCP server oluyor, ilk bakışta basit dürüyor ama işin tadı orada çıkıyor.
3. 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.
4. 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.
5. 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.
6. 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.

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Azure SDK Kasım 2025: Gerçekten Fark Yaratan Neler Geldi?17 Mar 2026

Agentic Cloud Operations: İçgörüden Eyleme Geçen Bulut Devri26 Haz 2026

C#’ta Bellek Güvenliği Neden Şimdi Daha Önemli?21 May 2026

Azure DocumentDB ile Bankalarda Customer 360: Dağınık Veriden Net Resme2 May 2026