Azure Functions ile Uzun Süreli MCP Araçları Geliştirmek

⏱️ 4 dk okuma📅 18 Temmuz 2026

Model Context Protocol (MCP) sunucularıyla çalışan geliştiricilerin sık karşılaştığı bir problem var: Bir aracın (tool) çalışması istemcinin bekleyebileceği süreyi aştığında ne yapmalı? Basit istek/yanıt akışının dışına çıkıp çok adımlı iş akışlarına ya da dakikalarca sürebilen işlemlere geçtiğinizde, mevcut MCP çağrı modeli sınırlarına dayanıyor. Bu yazıda, Azure Functions üzerinde Durable Functions kullanarak uzun süreli MCP araçlarının bugün nasıl gerçekleştirilebileceğini ve MCP’nin bu ihtiyacı standartlaştırmak için tanıttığı Tasks uzantısının ne getirdiğini ele alacağız.

MCP Araçlarında Bugünkü Sınır

MCP araçları bugün özünde istek/yanıt tabanlıdır: İstemci bir tools/call gönderir, sunucu sonucu döner. Bu model hızlı işlemler için uygundur; ancak şu koşullarda çatırdamaya başlar:

İş akışı dakikalarca sürüyorsa,
Yürütme birden fazla adıma bağlıysa,
Gecikme öngörülemezse.

Pratikte istemciler kendi araç çağrısı zaman aşımlarını uygular. Bunlar MCP spesifikasyonuyla standartlaştırılmamış olsa da genellikle 30–60 saniye civarındadır. Bu pencere aşıldığında istemci zaman aşımına düşer, ajan çağrıyı başarısız olarak görür ve arka plandaki iş çalışmaya devam edebilir. Kısacası: senkron araç çağrıları, uzun süreli işleri doğal biçimde modellemez.

MCP Tasks Uzantısı Neyi Değiştiriyor?

MCP’nin 2026-07-28 aday sürümüyle gelen Tasks uzantısı, tam olarak bu boşluğu doldurmayı hedefliyor. Uzantı etkinleştirildiğinde sunucu, bir tools/call‘a nihai sonuç yerine asenkron bir task handle (görev tanıtıcısı) ile yanıt verebiliyor. Yaşam döngüsünün geri kalanını istemci sürüyor:

tasks/get: Görevin durumunu sorgular.
tasks/update: Görev input_required durumuna geçerse sunucuya girdi gönderir.
tasks/cancel: Devam eden bir görevi iptal eder.

Bir görevin durumu working, input_required, completed, failed veya cancelled olabilir; tamamlandığında nihai sonucu da taşır. Görev oluşturma sunucu güdümlüdür: İstemci desteği istek başına yeteneklerinde bildirir, sunucu ise her istekte task döndürüp döndürmeyeceğine karar verir. Desteğini beyan etmeyen bir istemciye sunucu task döndürmez.

Ancak Tasks’ın işlevsel olabilmesi ekosistem desteğine bağlı: İstemcilerin uzantıyı beyan etmesi ve MCP SDK’larının görev yaşam döngüsünü uygulaması gerekiyor. Uzantı tanımlanmış olsa da geniş istemci ve SDK desteği hâlâ olgunlaşma sürecinde.

Durable Functions ile Bugünden Uzun Süreli Görevler

Tasks uzantısı istemciler arasında yaygın destek bulana kadar, mevcut istek/yanıt istemcileriyle çalışan ve uzun süreli yürütmeyi destekleyen bir desene ihtiyaç var. Microsoft tarafından paylaşılan örnekler bunu Durable Functions ile çözüyor. Durable Functions; kontrol noktası oluşturma, ölçekleme ve kurtarmayı otomatik yöneterek durum bilgisi tutan, uzun süreli iş akışlarını sıradan kod olarak yazmanıza olanak tanıyan bir çerçevedir.

Örneklerdeki uzun süreli iş, kısa bir blok zinciri madenciliğini simüle ediyor: Her blok, belirli bir örüntüye (örneğin belirli sayıda sıfırla başlayan bir çıktıya) ulaşana kadar farklı girdilerin denenmesini gerektiren bir hesaplama bulmacasını çözmeyi içeriyor. Bol deneme-yanılma barındırdığı için doğal olarak zaman alan, uzun süreli iş akışına iyi bir örnek oluşturuyor.

Sunucunun Sunduğu Araçlar

Örnek sunucu iki araç sunuyor:

start_mining
- Blokları madenlemek için bir Durable Functions orkestrasyonu başlatır.
- Yapılandırılabilir bir bütçe dahilinde kısa süre bekler.
- Bütçe içinde tamamlanırsa sonucu satır içi döner; hâlâ çalışıyorsa bir workflow_id döner.
get_mining_result
- workflow_id‘yi parametre olarak alır.
- Mevcut durumu döner: completed, running, failed veya not_found.

Ajanın araçları doğru sırada çağırması için workflow_id, get_mining_result‘ta zorunlu bir parametre olarak tanımlanmış; böylece ajan önce bir madencilik başlatmadan sorgulama yapamıyor. Ayrıca running yanıtı, bir poll_after_seconds değeri ve bir next talimatı taşıyor. Bu, ajanı iş bitmediğinde vazgeçmek ya da tamamlandı varsaymak yerine tekrar yoklama yapmaya yönlendiriyor.

Modelin Zayıf Noktası: Ajan Belleği

Buna rağmen sorgulama yolu, ajanın kendisine verilen workflow_id‘yi doğru hatırlamasına ve halüsinasyona kapılmamasına bağlı. Ajan kimliği bozar veya uydurursa, sorgu yanlış örneğe düşer ya da hiçbir örneğe düşmez. Bu yüzden get_mining_result, tahmin yürütmek yerine not_found dönduruyor.

Tasks Uzantısı Yaygınlaştığında Ne Değişecek?

Tasks uzantısı istemciler ve SDK’lar genelinde tam olarak uygulandığında model daha basit ve daha güvenilir hâle geliyor: Sunucu bir Task handle dönduruyor, istemci sorgulamayı ve yaşam döngüsü çağrılarını yönetiyor, SDK yürütme durumunu takip ediyor. Bu, bugünkü çözümün ajanın workflow_id gibi tanımlayıcıları hatırlayıp doğru şekilde iletmesine bağlı olması gibi kritik kısıtı ortadan kaldırıyor.

Ne Zaman Bu Deseni Tercih Etmeli?

Yazının özetlediği koşullar bu deseni değerli kılıyor:

Aracın çalışma süresi öngörülemez veya istemcinin zaman aşımını aşabilecek kadar uzunsa,
İş akışı birden fazla adım içeriyor ve durum bilgisi tutulması gerekiyorsa,
Kontrol noktası, ölçekleme ve hata kurtarma gibi özelliklere ihtiyaç varsa.

Durable Functions bu ihtiyaçları serverless bir modelde karşılarken, Azure Functions üzerindeki MCP eklentisiyle de doğal biçimde birleşiyor. Tasks uzantısı olgunlaştığında ise mevcut kodun büyük bölümünü koruyup istemci tarafındaki polling yükünü standart bir yaşam döngüsüne devretmek mümkün olacak.

Kaynaklar ve İleri Okuma

devblogs.microsoft.com

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

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