Microsoft, Azure MCP Server 3.0.0 sürümünü 12 Ekim 2026’da yayımladı. Yeni kaynak oluşturma varsayılanları sıkılaşıyor, bilinmeyen araç parametreleri reddediliyor ve bazı veritabanı araçlarının davranışı değişiyor. Ajanları otomasyona bağlayan ekipler için bu sürüm, yalnızca paket güncellemesi olarak ele alınmamalı.
Resmi sürüm notları, 2.0 sonrasındaki 50 beta sürümünün değişikliklerini bir araya getiriyor. Değişiklikler, kaynak oluşturma şablonlarının yanı sıra kayıtlı araç çağrılarının, veritabanı rollerinin ve sonuçları ayrıştıran kodun yeniden doğrulanmasını gerektiriyor. Güvenli varsayılanlar mevcut kaynakları kendiliğinden düzeltmiyor.
Azure MCP Server hangi işi yapıyor?
Azure MCP Server, destekleyen ajan uygulamalarının Azure hizmetleriyle Model Context Protocol üzerinden çalışmasını sağlar. Host uygulamadaki MCP istemcisi, sunucunun araçlarını keşfeder ve uygun çağrıları yürütür. Yetkili bir kullanıcının kaynak listesini sorgulaması veya desteklenen kaynak oluşturma işlemini başlatması bu akışa örnek.
Sunucu, Azure servislerinin kimlik ve erişim kontrollerinin yerine geçmez. Çağrının başarılı olması kullanılan kimliğin izinlerine, hedef hizmetin yapılandırmasına ve ağ erişimine bağlıdır. Araç listesinde bir komutun bulunması, o komutun bütün aboneliklerde çalıştırılabileceği anlamına gelmez.
Bu nedenle ben sürüm değerlendirmesine iki ayrı envanterle başlamayı öneriyorum: etkin araçlar ve bu araçların kullandığı kimliklerin izinleri. Yalnızca araç adlarına bakmak, servis tarafındaki gerçek erişim kapsamını göstermeye yetmez. Ajan ve cihaz kontrolü de bu incelemenin ayrı bir parçasıdır.
Kaynak oluşturma varsayılanlarında ne değişti?
3.0 sürümünde yeni Storage account oluşturulurken Shared Key kimlik doğrulaması kapalı geliyor. Event Hubs namespace’lerinde local authentication devre dışı. Recovery Services vault oluşturma işleminde public network erişimi kapalı, NFS dosya paylaşımlarında ise RootSquash ve aktarım şifrelemesi güvenli varsayılanlar arasında.
Bunlar aynı güvenlik kontrolü değil. Shared Key’in kapatılması kimlik doğrulama yöntemini, public network erişiminin kapatılması ağdan erişilebilirliği etkiler. Birini doğrulamış olmak diğerinin de uygun yapılandırıldığı anlamına gelmez. Kaynak türüne göre kimlik, ağ ve veri erişimini ayrı inceleyin.
Bu davranış, ilgili araçlarla oluşturulan yeni kaynaklar için geçerli. Mevcut kaynaklar otomatik olarak sıkılaştırılmaz. Ayrıca bağlantı yöntemi değişiyorsa uygulamanızın çalışabilmesi için uygun Entra kimliği, rol ataması veya özel ağ erişimi gerekebilir.
Örneğin Shared Key kullanan bir uygulamanın yeni Storage account’a eskisi gibi bağlanacağını varsaymayın. Önce desteklenen kimlik doğrulama akışını ve gerekli veri düzlemi rollerini doğrulayın. İşlem başarılı görünse bile uygulamanın erişim testi ayrı bir kabul kriteri olmalı.
Endpoint doğrulaması neyi sağlıyor?
Değişiklik kaydında, veri ve yönetim düzlemi araçlarında Microsoft.Security.AntiSSRF tabanlı, buluta özgü endpoint doğrulaması yer alıyor. Böylece araçların yönlendirildiği adresler beklenen servis uç noktaları açısından denetlenebiliyor.
Bu kontrolü bütün prompt injection risklerini ortadan kaldıran bir özellik gibi yorumlamamak gerekir. İzin verilen bir servise yapılan yetkisiz iş işlemi farklı bir sorundur. Endpoint doğrulaması, araç yetkileri, kullanıcı onayı ve Azure erişim kontrolleri birbirini tamamlar.
Telemetride seçenek değerlerinin artık kaydedilmemesi de dikkate değer. Değerlerin loglara taşınmasını azaltır; ancak kurumun kendi istemci, proxy veya uygulama loglarının aynı davranışı gösterdiğini garanti etmez. Hassas bilgilerin nerede kaydedildiği ayrıca incelenmeli.
Araç sözleşmesini kullanan kodları kontrol edin
3.0, araçlar arasında kullanılmayan parametreleri ve bazı özel retry seçeneklerini kaldırıyor. subscription, resource-group veya tenant gibi isimlerin belirli araçlardan kaldırılması, bunların bütün komutlardan silindiği anlamına gelmez. Etkilenen komutun güncel şemasını kontrol etmek gerekiyor.
Bilinmeyen parametrelerin açıkça reddedilmesi özellikle kayıtlı istemleri ve entegrasyon kodlarını etkileyebilir. Önceki sürümde dikkate alınmayan bir argüman, güncellemeden sonra çağrıyı başarısız kılabilir. Testleri yalnızca modelin ürettiği yeni çağrılarla sınırlamayın; kayıtlı otomasyon girdilerini de kullanın.
Bazı sonuçlar bestPractices, results veya servers gibi adlandırılmış nesneler altında normalize edildi. Çıktıyı belirli bir JSON yolundan okuyan betikleriniz varsa parse adımını yeniden deneyin. Boş sonuç ile hatalı parse durumunu birbirinden ayırın.
Sunucu ayrıca outputSchema ve structuredContent desteği sunuyor. Kullanım biçimi --structured-output-mode seçeneğiyle ilişkilidir. İstemcinizin bu alanları nasıl işlediğini doğrulamadan, bütün araç çıktılarının otomatik olarak beklediğiniz şemaya geçeceğini varsaymayın.
Veritabanı araçları için ayrı bir yetki kontrolü
MySQL ve PostgreSQL query araçları artık destructive olarak işaretleniyor; SQL fiiline dayalı filtreleme kaldırılıyor. İşlemin yapabileceklerini veritabanına bağlanan kullanıcının izinleri belirliyor. Salt okunur kullanım istiyorsanız bunu veritabanı rolüyle uygulayın.
MCP araç işaretleri istemciye bilgi verir, veritabanı yetkisini kısıtlamaz. Bir kimliğe veri değiştirme veya silme izni verdiyseniz, yalnızca model talimatına salt okunur yazmak aynı güvenceyi sağlamaz. Testte yetkisiz yazma girişiminin gerçekten reddedildiğini de görmelisiniz.
Bu davranış değişikliğini üretim bağlantısıyla denemek yerine ayrı bir test veritabanında doğrulamanızı öneririm. Başarılı sorgu kadar reddedilmesi gereken sorgu da kabul testinin parçasıdır. Denetim kayıtlarında hangi kimliğin hangi işlemi yürüttüğü görülebilmeli.
Yeni araç alanları ve protokol uyumu
Yeni namespace’ler arasında Azure Backup, Resilience Management, SRE Agent, Terraform, Optimization, IoT Hub ve Insights bulunuyor. Azure Backup tarafında vault, policy ve recovery point işlemleri; Terraform tarafında sağlayıcı dokümanı, Azure Verified Modules ve dışa aktarma araçları öne çıkıyor.
Her namespace’i aynı anda etkinleştirmek zorunda değilsiniz. Ajanın görevine göre araç kapsamını belirleyin. Kullanılmayan yönetim araçlarını sunmak, incelemeniz gereken sözleşme ve izin sayısını artırır.
Sunucu MCP 2026-07-28 stateless protokolüne geçti; sürüm notlarında 2025-11-25 istemcileri için otomatik geriye dönük uyumluluk belirtiliyor. Bu protokol uyumu, uygulamanızın kaldırılmış parametrelerden veya değişmiş JSON çıktılarından etkilenmeyeceği anlamına gelmez.
Bir diğer yükseltme ayrıntısı log kategorileri. Paylaşılan kod namespace’i Azure.Mcp.Core yerine Microsoft.Mcp.Core oldu. Eski ada göre filtre kullanan appsettings.json veya ortam yapılandırmaları varsa güncelleyin.
Üretime geçmeden önce
- Araç girdilerini ve JSON çıktısını kayıtlı örneklerle deneyin.
- Yeni kaynaklarda kimlik doğrulama ve ağ erişimini ayrı doğrulayın.
- Veritabanı kimliklerinin gerçek yetkilerini kontrol edin.
- İstemci uyumunu ve log filtrelerini test edin.
3.0 daha güvenli bir başlangıç sağlıyor; üretim sorumluluğu yine kimlik, ağ ve uygulama kontrollerinin birlikte doğrulanmasında. Sorularınız olursa yorumlarda buluşalım.
