Size bir şey söyleyeyim, Dün akşam laptopun başında otururken Victor Colin Amador’un duyurusunu gördüm — Azure MCP Server artık .mcpb uzantısıyla, yanı bir MCP Bundle olarak dağıtılıyor. İlk tepkim “tamam da ne farkı var şimdi?” öldü açıkçası (kendi tecrübem). Ama biraz kurcalayınca işin aslını anladım: bu aslında küçük bir teknik detay gıbı görünse de, Azure MCP Server’ı geliştirici olmayan insanların eline verme hamlesi. Yanı olay göründüğünden daha büyük (yanlış duymadınız)
Araya gireyim: Bakın şimdi anlatayım. Ben 20 küsur yıldır BT’nın içindeyim, hosting’den başlayıp bulut mimarlığına kadar her şeyi gördüm. Azure MCP Server’ı ilk çıktığında kurmaya çalıştığımda bile Node.js sürüm uyumsuzluğuyla yarım saat boğuşmuştum. Şimdi düşünüyorum da, bu benim başıma geldiyse — ki AZ-305, AZ-500 sertifikalı biriyim — sıradan bir kurumsal kullanıcının hâli ne ölür?
Evet, doğru duydunuz.
Açık konuşayım, İşte .mcpb formatı tam olarak bu soruya cevap veriyor.
MCP Bundle Nedir, Neden Şimdi Çıktı?
MCP Bundle, adı üstünde, Model Context Protocol sunucularını tek bir ZIP arşivi gıbı paketleyen taşınabilir bir format. Tarayıcı eklentilerindeki .crx ya da VS Code’un .vsix dosyalarını biliyorsanız, mantık aşağı yukarı aynı; ama burada olay biraz daha “sunucu tarafına” kayıyor ve işin içine kurumsal dağıtım girince mesele bir anda daha pratik hâle geliyor.
İçinde iki şey var: Bir manifest.json bulunuyor, yanı sunucunun metadata’sı, araçları ve runtime gereksinimleri burada tanımlanıyor; bir de sunucu binary’si ile tüm bağımlılıklar geliyor, kısacası paket açılınca çalışmaya hazır bir şey elde ediyorsunuz. Güzel tarafı bu. Ama dür bir saniye — asıl fark biraz sonra ortaya çıkıyor.
Ve işler burada ilginçleşiyor.
İşin püf noktası şu: kullanıcı hiçbir runtime kurmak zorunda kalmıyor. Node.js yok, Python yok,.NET SDK yok, Docker yok; indiriyorsun, çift tıklıyorsun, iş bitiyor. Hani bazen en büyük kazanım yeni bir özellik değil de kurulum adımının ortadan kalkması ölür ya, burada tam olarak o hissiyat var.
“Kurumsal ortamda runtime yönetmek, özellikle geliştirici olmayan ekiplerde, başlı başına bir kâbus. MCPB bu kâbusu tek hamlede çözüyor — ama tabii bazı ödünler de var.”
Runtime Bağımlılığı Neden Büyük Bir Problemdi?
Bir bankacılık projesinde geçen sene yaşadığımız şeyi anlatayım. Müşterinin güvenlik ekibi endpoint makinelere Node.js kurulmasına izin vermiyordu; sebep de belli, npm çevreindeki supply-chain saldırıları artık kimseye sürpriz gelmiyor. Azure MCP’yi kullanmak istiyorduk. Kullanamıyorduk, çünkü Docker da yasaktı ve.NET SDK tarafında da sadece belirli sürümler onaylıydı. Kısacası teknik olarak çözüm vardı, ama politika duvarına tosluyordu.
Sonunda ne yaptık? Bir jump server’a kurup oradan proxy’ledik. İğrençti açık konuşayım. Çalışıyordu ama zarif değildi; ayrıca bakım işi de cabasıydı (bir yerde log kopsa gidip iki farklı makineye bakıyorsun). Şimdi .mcpb ile bu yük ciddi ölçüde azalıyor — çünkü binary kendi içinde geliyor ve dışarıdan runtime beklemiyor.
Evet, doğru duydunuz.
Bi saniye — Evet.
Eski Yöntemler vs Yeni MCPB: Karşılaştırma
Şimdiye kadar Azure MCP Server’ı kurmak için dört farklı yol vardı. Hepsinin artısı eksisi var, yanı işin aslı pek de şaşırtıcı değil (kendi tecrübem). Şöyle bir tabloya bakınca kafada daha hızlı oturuyor:
| Yöntem | Gereken Runtime | Kurulum Zorluğu | Kurumsal Uygunluk |
|---|---|---|---|
| npm/npx | Node.js 18+ | Orta | Düşük (npm politikaları) |
| pip/uvx | Python 3.10+ | Orta | Orta |
| dotnet tool | .NET 8 SDK | Kolay (developer için) | Yüksek |
| Docker | Docker Engine | Zor | Değişken |
| MCPB (.mcpb) | Yok | Çok kolay | Yüksek |
MCPB tarafında en sevdiğim nokta şu: runtime derdi yok. Evet, baya rahatlatıyor. Peki, ama dür bir saniye — burada küçük bir detay var; binary platforma özel geliyor, yanı Windows x64, macOS ARM64 ve Linux x64 için ayrı dosyalar kullanılıyor. Tek paket her yerde çalışıyor sanmayın. Bu da aslında normal, Go binary mantığına oldukça yakın.
Eğer siz de “kurulum niye bu kadar uğraştırıyor” diye düşündüyseniz, yalnız değilsiniz. Ben de ilk bakışta aynı yere takıldım, çünkü npm politikaları, Python ortamı,.NET SDK sürümü derken iş uzuyor; MCPB işe bunu biraz sadeleştiriyor, ama evrensel sihirli kutu da değil.
Dürüst olmak gerekirse, Kısacası, eski yöntemler hâlâ iş görüyor. MCPB işe özellikle kurumsal tarafta daha temiz bir seçenek gıbı duruyor.
Uçtan uca kurulum, üç adım diyorlar. Gerçekten öyle mi?
Microsoft’un dokümanında “üç adımda kur” diye geçiyor. Evet, kağıt üstünde baya temiz duruyor. Ben ilk denediğimde de şaşırdım açıkçası; Claude Desktop’a kurulum, doğru paketle birlikte, iki dakikada halloldu. Ama işin içinde bir de yanlış mimarı indirme riski var, orası biraz can sıkabiliyor.
1. Adım: Önce doğru paketi seçmek
Hani, GitHub’daki release sayfasına giriyorsunuz, en güncel sürümü açıyorsunuz ve “MCP Bundles” bölümünden kendi işletim sisteminize uygun .mcpb dosyasını indiriyorsunuz. Windows tarafında azmcp-win-x64.mcpb, Maç M1/M2 kullanıyorsanız da azmcp-osx-arm64.mcpb. Mantıklı değil mi? Basit görünüyor ama küçük bir detay var: mimariyi karıştırırsanız paket açılmıyor, o kadar.
2. Adım: Claude Desktop’a yüklemek
En rahat yöntem sürükle-bırak. Claude Desktop’ı açın, sol üstteki hamburger menüye (☰) tıklayın, sonra File > Settings > Extensions yolunu izleyin — valla güzel iş çıkarmışlar —. İndirdiğiniz .mcpb dosyasını bu pencereye bırakıyorsunuz; sunucu bilgilerini gösteriyor, siz de “Install” deyip onaylıyorsunuz. Bitti. Kulağa fazla basit geliyor ama gerçekten çoğu zaman böyle ilerliyor. Ubuntu 26.04 ve .NET 10: Resolute Raccoon ile Yeni Dönem yazımızda bu konuya da değinmiştik.
Kısa bir not düşeyim buraya.
Manuel kurulum da var, hani bazı kurumsal makinelerde drag-drop kısmı kilitli olabiliyor ya, işte o durumda işe yarıyor. Extensions sayfasındaki Advanced Settings > Install Extension yolundan .mcpb dosyasını seçiyorsunuz. Aynı sonuç çıkıyor, sadece yol biraz dolanıyor.
.mcpb dosyaları için varsayılan uygulama yaparsanız, sonrasında indirdiğiniz paketlere çift tıklayarak direkt kurabilirsiniz. Küçük bir ayar gıbı duruyor ama valla iş görüyor.
3. Adım: Azure’a authenticate olmak
Daha açık söyleyeyim, size bir şey söyleyeyim, Neyse, buradan sonrası bildiğimiz Azure rutini. Azure MCP Server sizin credential’larınızı kullanıyor, o yüzden önce oturum açmış olmanız lazım. En kısa yol şu:
az loginEğer kurumsal bir tenant’ta çalışıyorsanız ve MFA açıksa, tarayıcıda bir pencere açılıyor ve sızı oraya yönlendiriyor. Service principal ile gitmek istiyorsanız environment variable üzerinden de yapabilirsiniz; ama şahsi makinede ben açık konuşayım, buna çoğu zaman gerek yok.
Peki sonra? Kurulum tarafı bitiyor aslında. Geri kalan kısım artık kullanım senaryosuna bağlı gidiyor,. Servis ayağa kalktıktan sonra Claude tarafında Azure komutlarını daha rahat konuşmaya başlıyorsunuz.
Karşılaştığım Bir Hata ve Çözümü
İlk kurulumda ufak bir pürüz çıktı, not düşeyim dedim. Claude Desktop’a paketi kurdum, ama tools listesi bir türlü görünmedi; üstüne bir de “Server failed to start” uyarısı geldi. Panik mi? Evet, biraz öldü. Ama işin aslı basitmiş.
Aslında, Sebep şuydu: Azure CLI tarafında aktif subscription seçilmemişti. Yanı az login yapmıştım, tamam, ama default subscription ortada yoktu; ben de önce başka yerde aradım hatayı, sonra dönüp buna baktım. Mesele netleşti. Şu komutla çözdüm:
az account set --subscription "your-subscription-id"Ardından Claude Desktop’ı tamamen kapatıp yeniden açtım (sadece pencereyi kapatmak yetmiyor, sistem tepsisinden de çıkarmak gerekiyor). Bu sefer tools listesi dolu dolu geldi. Küçük hata gıbı duruyor, ama insanın saatini fena yiyor.
Türkiye’deki Kurumsal Kullanım Açısından Değerlendirme
Araya gireyim: Şimdi işin en kritik yerine gelelim. Türkiye’de Azure kullanan kurumsal müşterilerde gördüğüm tablo biraz böyle: MCP tarafı var, evet, ama benimsenme hızı pek öyle uçmuyor. Sebep de az çok belli; finans ve kamu tarafında AI asistanlarının kurumsal verilere dokunması hâlâ soru işareti, üstüne bir de KVKK ve BDDK regülasyonları binince, Claude Desktop gıbı bir SaaS uygulamasının Azure kaynaklarına erişmesi (hele bu erişim sizin makinedeki credential üzerinden oluyorsa) güvenlik ekiplerinin canını sıkıyor.
Vallahi, Yine de bir şey var. MCPB formatı bu gerilimi biraz azaltıyor gıbı duruyor. Çünkü binary kurumsal makinede çalışıyor, veri dışarı çıkmıyor (LLM’e giden prompt’lar hariç), bir de runtime kurulumu istemediği için IT politikalarını daha az zorluyor. Ama bak şimdi, burada hemen gazlamamak lazım; ben olsam önce dev/test subscription’da denerim, production’a dokunmadan önce RBAC ayarlarını tek tek kontrol ederim.
Küçük Ekip vs Kurumsal: Hangisi Sizin İçin?
İnanın, Startup ya da 5-10 kişilik bir ekipseniz, açık konuşayım, MCPB baya iş görüyor. Çok uzatmaya gerek yok; kurarsınız, kullanırsınız, zaman kazanırsınız. Developer deneyimi de fena değil. GPT-5.5 Geldi: Gerçekten Daha Akıllı mı, Hype mı? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili CodeAct ve Hyperlight: Agent’ları Tek Hamlede Hızlandırmak yazımıza da göz atmanızı tavsiye ederim.
Açık konuşayım, Ama 500+ kişilik bir kurumsal yapıda işler biraz değişiyor. Direkt herkese dağıtmak yerine önce bir pilot grup seçmek daha mantıklı geliyor bana. 10-15 kişilik bir takıma verin, — ki bu tartışılır — 3-4 hafta dönsünler, sonra geri bildirim toplayın. Ilk bakışta masum duran şeyler bazen sonradan baş ağrıtıyor.
- Hangı Azure araçlarına kim erişiyor? — Azure MCP epey şey yapabiliyor; storage account listeliyor, KQL sorgusu çalıştırıyor, resource group silebiliyor. Yanlış kişinin eline geçerse işler çirkinleşir.
- Prompt loglama var mı? — Claude Desktop kurumsal kullanılıyorsa, kim ne sormuş bunu görebilmeniz lazım. Yoksa sonra “kim yaptı bunu?” diye ortada kalırsınız. (bence en önemlisi)
- Azure RBAC rolleri ne? — “Owner” rolüyle bağlanan bir MCP ciddi hasar verebilir; minimum privilege prensibi burada da geçerli oluyor. Hatta bence burada daha da önemli.
Bu arada yukarıda bahsettiğim o konu var ya, ben bunu daha önce Azure MCP Visual Studio 2022’de: Eklenti Devri Bitti yazısında VS 2022 entegrasyonu üzerinden anlatmıştım. Orada da benzer güvenlik meselelerini kurcalamıştık; yanı mesele yeni değil, sadece bu sefer başka bir kapıdan geri geldi.
MCPB’nın Eksik Yönleri — Dürüst Konuşalım
Şimdi lafı dolandırmadan söyleyeyim: MCPB baya iyi bir adım, ama kusursuz değil. Her yeni çıkan şeyi göklere çıkaran yazılardan da açıkçası biraz sıkıldım (ciddiyim). Siz de öyle değil mısınız?
Birinci mesele güncelleme mekanizması. Şu an yeni sürüm gelince dosyayı indirip güncellemeyi elle yapıyorsunuz; browser extension’lardaki gıbı otomatik akış yok, işte bu yüzden 100+ kişilik ekiplerde IT tarafında ufak bir baş ağrısı çıkabiliyor. Umarım sonraki sürümlerde auto-update gelir, çünkü aksi hâlde iş biraz uzuyor.
Araya gireyim: İkinci konu enterprise deployment. Microsoft Intune ya da SCCM entegrasyonu henüz yok, yanı MSI paketi gıbı merkezî dağıtım yapamıyorsunuz. Elle kurulum gerekiyor. 2000 kişilik bir şirkette bu işin tadı kaçıyor, açık konuşayım; Microsoft bu tarafı hızlı toparlar diye umuyorum.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Üçüncü nokta… binary imzalama. .mcpb dosyalarının code signing’i şu anda GitHub releases üzerinden güvenilir görünüyor, ama bazı kurumsal AV çözümleri imzasız binary’leri hiç sevmiyor ve direkt karantinaya atıyor. Bizde de geçen hafta bir müşteride aynen öldü — Defender for Endpoint paketi yaklaşık 10 dakika karantinada kaldı, sonra manuel whitelist açmak gerekti. Peki bunu neden söylüyorum? Evet, can sıkıcıydı.
Maliyet Tarafı: Aslında Ücretsiz Ama…
Azure MCP Server’ın kendisi ücretsiz, MCPB paketinin de cebinizden para çıkarmıyor (yanlış duymadınız). Kısacası, ama işin aslı biraz kıvrak; Azure MCP üzerinden attığınız her sorgu arkada bir Azure API çağrısı demek oluyor, yanı Log Analytics KQL ya da Cost Management API gıbı şeylere abanırsanız, onların kendi fiyat etiketi var. TL bazında bakınca tek tük kullanımda çok can sıkmıyor, ayda birkaç yüz sorgu yapan bir developer için kabaca 100-200 TL civarı diyebiliriz. Bir data ekibi 50 kişiyle günde binlerce sorgu atarsa, ay sonunda 15-20 bin TL’lık fatura görünce insanın kaşı kalkıyor. Evet.
Ayrıca Claude tarafını da es geçmeyelim. Claude Desktop’ın Pro planı ayda 20 USD civarında, team planı işe biraz daha yukarı çıkıyor; direkt Anthropıc API kullananlarda da her prompt token bazlı ücretleniyor, yanı “ben sadece bir şey sordum” demek pek kurtarmıyor. Kurumsal bir değerlendirme yaparken bu iki maliyet kalemini kafada ayrı ayrı tutmak lazım, yoksa ilk başta ucuz görünen kurgu sonradan sessizce pahalanabiliyor (özellikle kullanım arttıkça). Peki neden?
Alternatifler: Sadece Claude mu?
Olayın ilginç tarafı şu: MCPB formatı sadece Claude Desktop’a bağlı değil. MCP ile uyumlu olan her client bunu destekleyebilir, teorik olarak. Cursor, Windsurf, VS Code Copilot eklentisi gıbı araçlar biraz daha elini taşın altına koyarsa, aynı .mcpb paketi başka yerlerde de çalışır; işin can alıcı noktası da bence tam burası.
İşte tam da bu noktada devreye giriyor.
Şu sıralar Azure DevOps tarafında da benzer bir hava var — konuyla ilgili olarak Azure DevOps MCP Server Nişan Güncellemesi: Neler Değişti? yazısına göz atabilirsiniz (eh, fena değil). Oradaki güncellemeyle birlikte ekosistem yavaş yavaş oturuyor, ama dür bir saniye, bu işin üçü sadece server tarafıyla da bitmiyor. CLI kısmı da var; mesela Azure Developer CLI ve Copilot: Terminalde AI Dönemi yazımda terminal tarafındaki akışı biraz kurcalamıştım (ki bu çoğu kişinin gözünden kaçıyor)
Pratik Öneri: İlk üç Adımda Ne Yapın?
Okuyup geçmeyin, bir de deneyin. Hani bazen yazıyı bitirince “tamamdır” diyorsunuz ya, burada öyle ölmüyor; küçük bir lab açıp elinizle kurcalayın,. Işin kokusu orada çıkıyor.
- Dev tenant’ınızda bir test subscription açın. Production’a bulaştırmayın.
- MCPB paketini indirin ve Claude Desktop’a kurun. 5 dakika sürer.
- Basit sorularla başlayın. “List my resource groups”, “Show me storage accounts in X region” gıbı read-only komutlar deneyin. Yazma/silme komutlarına hemen atlamayın.
Bir hafta böyle kullanınca, insanın eli biraz alışıyor, güven de geliyor; sonra daha karmaşık senaryolara geçersiniz (ama ben olsam yine de önce loglara bakarım), çünkü bu işte ilk kazma darbesi genelde en pahalıya patlıyor. Bence asıl olay şu: Azure Portal’da 20 dakika süren işi 30 saniyeye indirebiliyor, fena değil. Ters kullanırsanız o 30 saniye size 20 dakikalık dert olarak geri döner. Tahmin eder mısınız? Evet, aynen böyle.
Sıkça Sorulan Sorular
MCPB paketi hangı işletim sistemlerinde çalışıyor?
Şu an Windows x64, macOS (hem Intel hem Apple Silicon/ARM64) ve Linux x64 için ayrı paketler mevcut. GitHub releases sayfasına girip kendi mimarinize uyan dosyayı indirmeniz gerekiyor — yanlış mimariyi kurarsanız paket zaten açılmıyor, bence önce bunu kontrol etmek mantıklı.
Azure MCP Server’ı kullanmak için mutlaka Azure aboneliğim mi olmalı?
Araya gireyim: Kurmak için şart değil ama kullanmak için kesinlikle gerekiyor. Yanı MCP Server, sizin Azure credential’larınızla gerçek kaynaklara erişiyor. az login ile giriş yapmadıysanız hiçbir tool çalışmıyor — açıkçası bu adımı atlayan çok insan var.
MCPB formatı sadece Claude Desktop’ta mı çalışıyor?
Hayır, format açık standart aslında. MCP-uyumlu her client destekleyebilir. Mevcut dokümantasyon ağırlıklı olarak Claude Desktop üzerinden gidiyor, ama ilerleyen dönemde Cursor, Windsurf. Benzeri client’ların da destek eklemesi bekleniyor.
Kurumsal ortamda MCPB’yi güvenle kullanabilir mıyım?
Bu tamamen RBAC ayarlarınıza bağlı. MCP Server kullanıcının kendi credential’ıyla çalıştığı için, o kullanıcının Azure’da ne yetkisi varsa MCP de önü yapabiliyor. Mesela Owner rolüyle bağlanan bir MCP instance’ı teorik olarak tüm aboneliği silebilir — bence bu ciddi bir risk. Tecrübeme göre minimum privilege prensibiyle ayrı bir kullanıcı açıp sınırlı yetkilerle bağlamak çok daha mantıklı.
Eski npm/npx kurulumumu kaldırmam gerekiyor mu?
Hayır, gerekmiyor. İkisi aynı anda var olabilir. Pratikte pek bir anlamı olmaz — Claude Desktop zaten aktif bıraktığınız konfigürasyonu kullanıyor. Önce MCPB ile deneyin, her şey yolundaysa eski kurulumu temizleyebilirsiniz.
Kaynaklar ve İleri Okuma
Azure SDK Blog: Azure MCP Server now available as an MCP Bundle
Doğrusu, Azure MCP Server GitHub Repository
Model Context Protocol Resmî Dokümantasyonu
Azure CLI Authentication Rehberi
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
