Azure Functions’ta MCP Apps: TypeScript ile Hızlı Başlangıç

Geçen hafta bir tanıdık sordu: “Şu MCP olayı sadece metin döndüren API’ler mi? Yanı ChatGPT’ye bir tool bağladım, bana JSON attı, o da text’e çevirdi, olay bu mu?” Haklıydı aslında. Uzun süre MCP dünyası tam da böyleydi; düz metin, biraz markdown, en fazla ufak bir tablo. Şimdi iş değişiyor.

MCP Apps ile artık sunucu tarafında bir “widget” tanımlayıp bunu Copilot’ın, Claude’un ya da ChatGPT’nın içinde interaktif HTML olarak gösterebiliyorsunuz. Yanı kullanıcı hava durumunu sorunca dönen şey artık sadece “Ankara 12°C, parçalı bulutlu” cümlesi olmuyor; üstüne tıklanabilen, saatlik grafikleri olan mini bir uygulama geliyor. Garip ama güzel. Bunu Azure Functions üzerinde host etmek de, açık konuşayım, sandığınız kadar uğraştırmıyor.

Kısa bir not düşeyim buraya.

Bu yazıda hem konsepti anlatacağım hem de Türkiye’deki kurumsal projeler açısından bunun nereye oturduğunu paylaşacağım. Yer yer eleştirim de olacak, çünkü kağıt üstünde tatlı görünen bu mimarinin sahada bazı pürüzleri var. Evet, baya var.

MCP Apps aslında ne çözüyor?

Bakın şimdi, klasik MCP tool’ları şöyle çalışıyordu: model bir fonksiyon çağırıyor, sız JSON dönduruyorsunuz, model de önü kullanıcıya cümleye çeviriyor. Basit senaryoda fena değil. Ama iş biraz karışınca — mesela onay ekranı, grafik, harita — sistem hemen tökezliyordu.

MCP Apps burada devreye giriyor. MCP sunucusu artık iki tür şey döndürebiliyor:

• Tools — klasik iş mantığı, veri döndüren fonksiyonlar
• Resources — HTML/JS kodu, yanı doğrudan client’ta render olacak arayüz parçaları

Eh, Widget içinde çalışan JS, aynı sunucudaki tool’ları çağırabiliyor. Hani ne farkı var diyorsunuz, değil mi? Yanı mimarı şöyle kuruluyor: sunucu hem veri kaynağı hem de UI paketleyici gibi davranıyor (evet, biraz ikili rol), model işe sadece orkestrasyonu yapıyor; hangi widget’ın çağrılacağına karar veriyor ve geri kalan iş client ile sunucu arasında akıyor.

Ne zaman gerçekten gerekli?

Kendi deneyimimden konuşuyorum, Açık konuşayım: her senaryoya MCP App gerekmiyor. Kullanıcıya “faturayı ödedim” demek için widget’a ihtiyaç yok. Peki neden? Ama şu durumlarda baya iş görüyor:

• Etkileşimli veri: Liste yerine tıklanabilir harita, zoom yapılabilen grafik
• Karmaşık form: Onlarca soruyu tek ekranda toplamak — modele soru sordurmaktan kat kat hızlı
• Canlı panolar: Yeni prompt beklemeden güncellenen dashboard
• Çok adımlı iş akışı: Onay süreçleri, wizard tarzı ekranlar, state korunması

Sahada gördüğüm en yaygın örneklerden biri iç kullanıma yönelik insan kaynakları onay ekranları öldü. Yönetici Copilot’a “geçen haftaki izinleri onayla” diyor, karşısına düz metin liste yerine gerçek bir onay tablosu geliyor ve tek tıkla iş bitiyor. Neden önemli bu? İşte fark burada çıkıyor.

Neden özellikle Azure Functions?

MCP sunucusu yazmak kolay görünüyor ama protokolle doğrudan uğraşınca insan yoruluyor. JSON-RPC handshake, capability negotiation, streaming, resource lifecycle… Bunları elle yazmaya kalkarsanız (hele production hedefliyorsanız) hızla konudan uzaklaşıyorsunuz.

Azure Functions burada güzel bir abstraction katmanı veriyor. Sız iş mantığını ve UI’ınızı yazıyorsunuz; bir düşüneyim… protokol detaylarını Functions runtime hallediyor. Bunun yanında paketten gelen birkaç şey daha var: Function key ile temel güvenlik. Üstüne OAuth desteğiyle enterprise auth; Bicep ve azd ile IaC; lokal test için Functions Core Tools; ayrıca otomatik ölçekleme, retry ve monitöring gibi zaten alışık olduğunuz servis davranışları.

Serverless mimarinin buradaki en büyük avantajı şu: MCP tool’ları genelde burst tarzda çağrılır. Kullanıcı sorar, cevap gider, sonra saatlerce sessizlik olur. Böyle bir yük profili için Functions’ın tüketim modeli baya uygun geliyor — VM ayağa kaldırıp bekletmek biraz saçma kalırdı.

Kurumsal Türkiye penceresinden bakınca

Türkiye’deki kurumsal ekiplerle konuştuğumda MCP konusunda iki farklı tavır görüyorum. Bir grup “bu ne şimdi, daha Copilot’u zor benimsettik” diyor; diğer grup işe — özellikle içeride kendi AI asistanını kurmaya çalışan büyük kurumlar — tam olarak şu problemi çözmeye uğraşıyor: model çağrılarını kendi backend’imize nasıl bağlarız? Hmm, asıl soru bu.

Ne yalan söyleyeyim, Cevap uzun süre custom REST API’ler ile prompt engineering karışımıydı. Şimdi MCP standart bir sözleşme veriyor. Azure Functions üzerinde host edildiğinde veri güvenliği tarafında CISO’ları rahatlatan şeyler de hazır geliyor: VNet integration, private endpoint, managed identity… Hepsi kutuda var gibi dürüyor. Data residency tarafında da West Europe ya da kurulacak yerel bölge seçilebiliyor.

Weather App örneği: parçaları anlamak

Microsoft’un yayınladığı örnek klasik bir hava durumu uygulaması. Kabul ediyorum, konu biraz basmakalıp; herkes hava durumu örneği yapıyor zaten. Ama parçaları göstermek için iş görüyor. Örnek şunları içeriyor:

• GetWeather tool: Open-Meteo API’sinden konum ve hava verisi çekiyor
• Weather Widget resource: Etkileşimli HTML/JS dönduruyor ve client’ta render oluyor (bence en önemlisi)
• TypeScript service layer: API çağrılarını ve veri dönüşümünü soyutlayan katman
• Lokal test akışı: MCP Inspector, VS Code veya custom client ile debug

Akış nasıl işliyor?

İlginç olan şu ki, Kabaca sıra şu şekilde ilerliyor:

1. Azure Functions getWeatherWidget resource’ünü servis ediyor → HTML/JS içeriği dönüyor — bunu es geçmeyin
2. Client (Copilot, Claude vb.) widget’ı kendi arayüzünde render ediyor
3. Widget içindeki JS getWeather tool’ünü çağırıyor
4. Sunucu tool’u işletip veriyi widget’a geri gönderiyor
5. Widget veriyi görsel olarak render ediyor

Bence buradaki güzellik şu: UI mantığı client tarafında kalıyor (yanı hızlı ve responsive), veri mantığı sunucu tarafında kalıyor (yanı güvenli ve kontrollü). Model işe sadece “hangi widget gösterilecek” kararını veriyor. Aslında ayrım baya mantıklı çıktı.

Çok konuştum, örnekle göstereyim.

Minimal bir tool tanımı nasıl görünüyor?

TypeScript tarafında bir MCP tool aşağı yukarı şöyle dürüyor:

import { app } from "@azure/functions";
app.mcpTool("getWeather", {
toolName: "getWeather",
description: "Belirtilen konum için hava durumu döner",
toolProperties: [
{ propertyName: "location", propertyType: "string", 
description: "Şehir adı" }
],
handler: async (context, args) => {
const data = await weatherService.fetch(args.location);
return { content: [{ type: "text", text: JSON.stringify(data) }] };
}
});

Bir bakıma, i̇lginç olan şu ki, Resource tarafı da benzer gidiyor; HTML içeriğini string olarak dönüyorsunuz ya da dosyadan okuyup gönderiyorsunuz. Karmaşık değil. Zaten karmaşık olsaydı Functions’ın sağladığı değer biraz anlamsız kalırdı.

Lokal geliştirme ve deploy

Sahada en çok sevdiğim taraflardan biri şu öldü: gerçekten lokal çalışıyor olması. Function Core Tools ile func start deyince MCP endpoint’i localhost’ta ayağa kalkıyor; sonra MCP Inspector ile bağlanıp tool’ları elle çağırabiliyorsunuz. VS Code’un MCP desteğiyle Copilot Chat üzerinden test etmek de mümkün oluyor.

Deploy tarafı işe azd up. Tek komut yanı. Bicep şablonu Function App’i, Storage’ı, Application Insights’ı ve gerekli role assignment’ları kuruyor. Ha bu arada — Bicep dosyasına göz atın derim — çünkü default olarak public erişim açık geliyor olabilir; kurumsal ortamda private endpoint eklemek. Function key ya da OAuth’u zorlamak gerekiyor.

Küçük ekip mi, kurumsal mı?

İtiraf edeyim, Bunu ayırmadan geçmek istemiyorum çünkü mimarı kararlar ciddi biçimde değişiyor:

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

Microsoft ve OpenAI Ortaklığının Yeni Dönemi: Ne Değişiyor?27 Nis 2026

ASP.NET Core 2.3 İçin Saat İşliyor: Ne Yapmalı?7 Nis 2026

Gemini API’de Maliyet ve Hız Dengesi: Flex ile Priority4 Nis 2026

Azure IaaS: Güçlü Bulut İçin Yeni Kaynaklar9 Mar 2026