Bakın, Geçen ay bir finans kuruluşunda Azure kaynaklarını yöneten otomasyon pipeline’larını tartışıyorduk — uzun, biraz yorucu. Verimli bir toplantıydı. Ekip lideri tam ortada “Biz bu ajanları kendi ortamımızda çalıştıramazsak hiç bulaşmayalım” dedi. Durdum bir an. Haklıydı, haksız değildi. Bulut otomasyonunda AI ajanlarının güzel işler çıkardığını herkes görüyor, kabul, ama kurumsal ortamlarda “bu şey nerede çalışıyor, verilerim nereye gidiyor, kim kontrol ediyor” sorusu her teknik argümanın önüne geçiyor — her seferinde. İşte Azure MCP Server 2.0 tam da bu noktayı hedef alıyor ve açık konuşayım, bence bayağı işabetli bir hamle bu.
MCP Server Tam Olarak Ne ve Neden 2.0 Önemli?
Önce kısaca hatırlayalım. Azure MCP Server, Model Context Protocol spesifikasyonunu uygulayan açık kaynak bir sunucu. AI ajanları ve geliştirici araçlarının Azure kaynaklarıyla konuşmasını sağlıyor — ama bunu rastgele API çağrılarıyla değil, yapılandırılmış ve keşfedilebilir araç arayüzleriyle yapıyor. Şu an 57 farklı Azure servisi üzerinde tam 276 MCP aracı var. Provisioning’den deployment’a, monitöring’den operasyonel teşhise kadar geniş bir yelpaze kapsıyor.
Peki 2.0’da ne değişti? Tek kelimeyle: self-hosted remote server desteği. Artık MCP Server’ı kendi altyapınızda, kendi ağ sınırlarınızda barındırabiliyorsunuz. Kağıt üstünde basit görünüyor, haklısınız. Ama pratikte devasa bir fark bu — gerçekten devasa. Daha önce local geliştirme ortamında tek kişilik kullanım ağırlıklıydı, hani “ben açarım, ben kullanırım, ben kapatırım” türünden bir şeydi. Şimdi işe bir takımın tamamı aynı MCP sunucusu üzerinden, merkezî politikalar ve güvenlik kontrolleriyle çalışabiliyor.
Şunu söyleyeyim, 2023’te MCP konseptini ilk duyduğumda içimden “güzel fikir. Enterprise’da kim buna güvenecek ki” demiştim. Self-hosted desteği olmadan kurumsal müşterilere bunu önermek gerçekten zordu — neredeyse imkânsızdı. Artık o engel kalktı. En azından büyük ölçüde.
Self-Hosted Remote Server: Sahada Ne İfade Ediyor?
Dürüst olmak gerekirse, Bak şimdi, self-hosted dediğimizde ne kastediyoruz, önü biraz açayım çünkü burada önemli detaylar var. Azure MCP Server 2.0 HTTP tabanlı transport’u epey güçlendirmiş ve remote modda kimlik doğrulama senaryolarını destekler hâle gelmiş. İki ana authentication yaklaşımı var:
- Managed Identity: Eğer Microsoft Foundry yanında çalıştırıyorsanız, managed identity ile doğrudan entegre olabiliyor. Azure’da zaten kimlik altyapınız varsa en temiz yol bu — ekstra bir şeyle uğraşmıyorsunuz.
- On-Behalf-Of (OBO) Flow: OpenID Connect delegasyonu üzerinden, oturum açmış kullanıcının kimliğiyle Azure API’lerini çağırabiliyor. Yanı ajan “kendi başına” değil, kullanıcı adına hareket ediyor — bu güvenlik açısından çok kritik bir ayrım, atlamamak lazım.
Şöyle söyleyeyim, Logosoft’ta geçtiğimiz hafta bir telekomünikasyon müşterimizle tam olarak bu konuyu tartıştık. Adamların 200’den fazla geliştiricisi var ve her birinin Azure portalına girip kaynak yönetmesi yerine, merkezî bir MCP sunucusu üzerinden ajanlarla çalışması planlanıyor — mantıklı bir hedef (inanın bana). OBO flow burada hayat kurtarıcı çünkü her geliştiricinin kendi yetki sınırları korunuyor. Ajan, kullanıcının göremeyeceği bir kaynağa erişemiyor. Erişemez, nokta.
Bunu biraz açayım.
Güvenlik Sıkılaştırması: Sadece Laf Değil
Güvenlik konusunda 2.0 ciddi adımlar atmış (inanın bana). Ama dur bir saniye — “güvenlik sıkılaştırması” ifadesini her release note’ta görüyoruz ve çoğu zaman içi boş oluyor, kabul edelim bunu. Bu sefer durum biraz farklı, gerçekten.
Endpoint Validasyonu ve Injection Koruması
Uzak sunucu modunda çalışırken endpoint validasyonu güçlendirilmiş. Prompt injection ve komut enjeksiyonuna karşı korumalar eklenmiş. Bu özellikle önemli çünkü bir AI ajanı Azure kaynaklarını yönetiyorsa ve birisi o ajana kötü niyetli bir prompt gönderebiliyorsa… işler gerçekten çok kötü gidebilir. Düşünün: ajan subscription’daki büyük çoğunluk kaynakları silme yetkisine sahip ve birisi önü manipüle edebiliyor. Kâbus senaryosu bu, abartmıyorum.
Durun, bir saniye.
Operasyonel Güvenlik Kontrolleri
Read-only mod, işlem onay mekanizmaları ve denetim logları gibi operasyonel güvenlik önlemleri de 2.0’ın parçası. Bir bankacılık projesinde — sanırım 2024 başlarındaydı, biraz bulanık hatırlıyorum ama öyle bir dönemdi — benzer bir otomasyon aracı kullanırken en büyük sorunumuz “bu araç tam olarak ne yaptı, kim tetikledi, geri alabilir mıyız” sorularına cevap verememekti. Denetim logları olmadan compliance ekibini ikna etmek imkânsız, bunu deneyimledik bizzat.
Yine de açık konuşayım: bu güvenlik özelliklerinin gerçek dünyada ne kadar sağlam olduğunu görmek için biraz daha zamana ihtiyacımız var (yanlış duymadınız). Kağıt üstünde güzel. Pratikte göreceğiz artık.
Tipik Kullanım Senaryoları ve Karşılaştırma
Gelelim “peki ben bunu nerede kullanacağım” sorusuna. Farklı ölçeklerdeki organizasyonlar için küçük bir tablo hazırladım: Bu konuyla ilgili GitHub’da “Low Quality” Etiketi: Moderasyonda Küçük Ama Yerinde Bir Hamle yazımıza da göz atmanızı tavsiye ederim.
| Senaryo | Küçük Takım / Startup | Enterprise |
|---|---|---|
| Deployment Modeli | Local MCP (IDE içinde) | Self-hosted remote server |
| Kimlik Doğrulama | Azure CLI token | Managed Identity / OBO Flow |
| Politika Yönetimi | Bireysel ayarlar | Merkezî tenant/subscription varsayılanları |
| Güvenlik İhtiyacı | Temel seviye | Denetim logları, RBAC, injection koruması |
| CI/CD Entegrasyonu | İsteğe bağlı | Pipeline’lara gömülü, zorunlu |
Araya gireyim: Startup’lar için local modda başlamak mantıklı. Tek geliştirici veya küçük bir ekibiniz varsa, IDE’nizin içinde MCP Server’ı ayağa kaldırıp Azure kaynaklarınızı ajanla yönetebilirsiniz — hızlı, kolay, yeterli. Ama 50’den fazla kişilik bir ekibiniz varsa, herkesin kendi local MCP’sını çalıştırması kaosa davetiye çıkarmaktır. Remote server tam burada devreye giriyor. GitHub Bildirimlerinde Sıralama Geldi: Küçük Detay mı? yazımızda bu konuya da değinmiştik.
Ha, bu arada — CI/CD entegrasyonu konusu beni en çok heyecanlandıran kısım, şunu da söyleyeyim. Bir MCP aracını pipeline’ın içine koyabilmek, mesela deployment sonrası otomatik diagnostik çalıştırmak ya da kaynak provizyon kontrolü yapmak, ciddi zaman kazandırabilir. Bunu daha önce custom script’lerle yapıyorduk. Hiç de zarif değildi, inanın.
Kısa bir not düşeyim buraya.
Pratikte Nasıl Başlanır?
Hmm, bir düşüneyim… En basit başlangıç noktası şöyle: önce local modda deneyin, kavramı oturtun, sonra remote’a geçin. Aşağıda basit bir başlatma örneği var: Daha fazla bilgi için GitHub’un Mart 2026 Dersi: Dayanıklılık Kağıt Üstünde Değil yazımıza bakabilirsiniz.
# Azure MCP Server'ı klonlayın
git clone https://github.com/Azure/azure-mcp-server.git
cd azure-mcp-server
# Bağımlılıkları yükleyin
npm install
# Local modda başlatın (geliştirme için)
npm run start:local
# Remote modda başlatın (takım kullanımı için)
npm run start:remote — --auth managed-identity --port 8080Remote modda başlattığınızda takımınızdaki herkes bu sunucuya bağlanabiliyor. Ama dikkat — remote modu açmadan önce genelde authentication yapılandırmanızı tamamlayın. Kimlik doğrulamasız remote MCP sunucusu açmak, açık konuşayım, intihar niteliğinde bir hareket olur. Microsoft bunu varsayılan olarak zaten engelliyor, ama yine de uyarayım dedim.
Araya gireyim: Bir de şunu ekleyeyim: 276 araç arasından hangilerini aktif edeceğinizi seçebiliyorsunuz. Hepsini birden açmak zorunda değilsiniz. Mesela sadece Azure App Service ve Azure SQL ile ilgili araçları aktif edip geri kalanını kapatabilirsiniz. Hem güvenlik hem performans açısından çok daha sağlıklı bir yaklaşım bu.
Evet, doğru duydunuz.
Küçük başlayın, merkezî büyüyün. Local modda kavramı öğrenin, remote modda ölçeklendirin. Güvenlik katmanlarını atlayarak hızlanmaya çalışmak, sonunda sizi daha çok yavaşlatır.
Beklediğim Kadar İyi mi? Eksik Bulduğum Noktalar
Her yeni release’i övmek kolay. Ben biraz hayal kırıklığı yaşadığım noktaları da paylaşayım — bunlar önemli.
Birincisi, 276 araç kulağa çok hoş geliyor, tabii ki. Ama bazıları henüz oldukça yüzeysel. Azure Kubernetes Service araçlarını denediğimde “cluster oluştur” ve “cluster sil” gibi temel operasyonlar var, tamam, ama node pool scaling veya HPA konfigürasyonu gibi daha granüler işlemler eksik. Showcase için güzel, üretim ortamında tek başına yetmiyor — en azından şimdilik.
Açıkçası, İkincisi, dokümantasyon hâlâ biraz dağınık (ki bu çoğu kişinin gözünden kaçıyor). Open source projelerin kronik sorunu bu, biliyorum. GitHub repo’sundaki README iyi ama enterprise deployment senaryoları için adım adım rehber ararsanız biraz zorlanırsınız. Microsoft’un bunu hızla düzeltmesi gerekiyor.
Üçüncüsü — ve bu beni biraz rahatsız etti açıkçası — offline mod desteği yok. MCP Server’ın çalışması için sürekli Azure’a erişim gerekiyor. Air-gapped ortamlar için bu bir sorun. Tabii, Azure kaynaklarını yönettiğiniz için internet bağlantısı doğal olarak gerekli, bunu anlıyorum. E peki, sonuç ne oldu? Ama en azından bir cache mekanizması veya kısmi offline destek olabilirdi bence.
Bak bir de şunu söyleyeyim: MCP Apps’i Kolaylaştıran Fluent API: Sahada Ne Değişiyor? yazımda MCP dünyainin genel durumunu değerlendirmiştim. O yazıdaki bazı endişelerim hâlâ geçerli. Ama 2.0 ile önemli bir kısmı giderilmiş durumda — bunu da teslim etmek lazım.
Foundry Entegrasyonu ve Geleceğe Bakış
Microsoft Foundry ile entegrasyon konusu ayrıca ilginç. Microsoft Foundry Mart 2026: Sahadan İlk İzlenimler yazımda Foundry’nın potansiyelinden bahsetmiştim. Peki bunu neden söylüyorum? MCP Server 2.0’ın Foundry ile managed identity üzerinden doğrudan çalışabilmesi, bu iki parçayı birleştiren güzel bir köprü olmuş — tasarım kararı doğru verilmiş.
Bak şimdi, Geleceğe baktığımda MCP’nın Azure ekosistemindeki rolünün giderek büyüyeceğini düşünüyorum. Burada, şu an 57 servis destekleniyor ama Azure’da 200’den fazla servis var. Kalan servislerin de eklenmesi zaman meselesi. Ama — az önce her şey güllük gülistanlık dedim gibi bir izlenim bıraktım, düzelteyim bunu — bu genişleme sırasında kalitenin düşmemesi lazım. 276 tane yarım yamalak araç yerine 150 tane sağlam araç tercih ederim, açıkçası.
E tabii bir de güvenlik tarafı var. Copilot Güvenlik Taramasında: Riski Okutan Yeni Hamle yazısında bahsettiğim güvenlik tarama yaklaşımlarının MCP araçlarına da uygulanması gerekecek eninde sonunda. Bir ajanın Azure’da ne yapabileceğini sınırlamak, sadece RBAC ile değil, araç seviyesinde de kontrol edilmeli (ilk duyduğumda inanamadım). Bu kısım henüz tam oturmamış bence — önümüzdeki dönemde göreceğiz nasıl gelişecek.
Sıkça Sorulan Sorular
Azure MCP Server 2.0’ı kullanmak için ücret ödenmesi gerekiyor mu?
Şunu fark ettim: Hayır. Daha açık söyleyeyim, azure MCP Server tamamen açık kaynak ve ücretsiz. Ama tabii altında çalışan Azure kaynakları (VM, App Service vb.) için normal Azure faturalandırması geçerli. Sunucunun kendisi bedava, barındırdığınız altyapı değil.
Self-hosted remote server ile SaaS arasındaki fark nedir?
Bunu yaşayan biri olarak söyleyeyim, Self-hosted demek sunucuyu kendi altyapınızda sız çalıştırıyorsunuz — kontrol tamamen sizde. Microsoft’un hosted bir MCP SaaS servisi şu an yok. Bu, özellikle veri egemenliği ve ağ izolasyonu gerektiren kurumsal ortamlar için tercih edilen model.
Hangi AI ajanları Azure MCP Server ile uyumlu?
İnanın, MCP (Model Context Protocol) spesifikasyonunu destekleyen herhangi bir ajan veya araç uyumlu. GitHub Copilot, VS Code’daki ajan uzantıları ve MCP uyumlu üçüncü parti araçlar doğrudan bağlanabiliyor. Spesifik bir LLM’e bağımlılık yok.
Enterprise ortamda kaç kullanıcı aynı anda bağlanabilir?
Bu tamamen sunucunuzu barındırdığınız altyapının kapasitesine bağlı (buna dikkat edin). MCP Server kendisi hafif bir uygulama ama 200+ eşzamanlı kullanıcı için yük dengeleme. Horizontal scaling düşünmeniz gerekir. Microsoft’un resmî benchmark’ı henüz yayınlanmadı — bu eksik bir nokta.
Mevcut Azure CLI veya Terraform iş akışlarımı değiştirmem gerekir mi?
Hayır, MCP Server mevcut araçlarınızın yerini almıyor, onları tamamlıyor. Terraform ile IaC yapmaya devam edebilir, Azure CLI kullanmaya devam edebilirsiniz. MCP daha çok AI ajanlarının — kendi adıma konuşayım — Azure’la etkileşim kurması için bir katman. İkisi birlikte gayet güzel çalışıyor.
Kaynaklar ve İleri Okuma
Azure MCP Server 2.0 Stable Release Duyurusu — Azure SDK Blog
Azure MCP Server GitHub Repository
Azure MCP Server Resmî Dokümantasyonu — Microsoft Learn
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder