Hani, Açık konuşayım: Azure MCP Server’ı ilk denediğimde en çok sınır olduğum şey kurulum tarafıydı. Müşteriye gidiyorsun, “abi şu yapay zekâ asistanını Azure’a bağlayalım” diyorsun, sonra mevzu uzuyor — Node.js sürümü tutmuyor, Python venv karışıyor,.NET SDK eksik kalıyor; yanı işin teknik kısmına gelmeden kurulum bürokrasisi insanı baya yoruyor.
Yanı, Neyse. Geçen hafta fark ettim ki Microsoft Azure SDK ekibi bu dert için bir çıkış yolu getirmiş: Azure MCP Server artık MCP Bundle (.mcpb) formatında dağıtılıyor. Tek dosyayı indirip Claude Desktop’a sürükle bırakıyorsun, tamamdır. Ne Node lazım, ne Python, ne dotnet. Basit duruyor, ama aslında arka tarafta epey paketleme işi dönüyor (kendi tecrübem)
Evet, doğru duydunuz.
Ben bu yazıda hem.mcpb formatının ne olduğunu, hem Azure tarafında neye denk geldiğini, hem de Türkiye’deki kurumsal müşteri profilinde bunun pratikte ne ifade ettiğini anlatacağım. Bir de sonda küçük bir uyarı listesi var; kurulum bitince “bunu da mı atladık” dememek için işte (ciddiyim)
MCP Bundle nedir, neden önemli?
Şöyle düşünün: Tarayıcı eklentilerinin .crx uzantısı var, VS Code eklentilerinin .vsix‘i var. İkisi de aslında ZIP gıbı paketleniyor; içinde manifest duruyor, kod duruyor, ne lazımsa içine konuyor. .mcpb da aynı kafada çalışıyor, ama bu kez Model Context Protocol sunucuları için.
Bir .mcpb dosyasının içinde iki ana parça oluyor:
- manifest.json — Sunucunun metadata bilgileri, hangı araçları (tool) sunduğu, runtime gereksinimleri
- Sunucu binary’si ve tüm bağımlılıkları — O platformda çalışmak için ne gerekiyorsa hepsi paketin içinde
Açıkçası, Kritik nokta şu: self-contained binary. Yanı end user tarafında ayrıca bir runtime kurmaya gerek kalmıyor. Güzel tarafı bu. Hatta bence asıl fark burada başlıyor; geliştirici olmayan kullanıcılar için iş baya kolaylaşıyor (çünkü Node mu kuracağım, Python mu uğraşacağım derdi bitiyor), özellikle de MCP gıbı yapay zekâ asistanlarına araç tanımlayan yapılarda bu detay hiç hafif değil.
Bir finans kuruluşunda yaptığımız POC’de en büyük direnç noktası “biz sunucularımıza Node.js kuramayız, güvenlik politikası izin vermiyor” cümlesiydi. Bu.mcpb yaklaşımı tam o duvarı yıkıyor — runtime kurulum gereksinimi tamamen ortadan kalkıyor.
Önceki kurulum yöntemleriyle karşılaştırma
Peki şimdiye kadar Azure MCP Server’ı nasıl ayağa kaldırıyorduk? Şurada seçenek çok görünüyordu ama işin içine girince bazıları hemen tökezliyordu. Tabloya bakın, sonra ne demek istediğim daha net oluyor:
Bir dakika — bununla bitmedi.
| Yöntem | Gerekli Runtime | Kurulum Zorluğu | Kurumsal Uyumluluk |
|---|---|---|---|
| npm / npx | Node.js 18+ | Orta | Politika engeli olabilir |
| pip / uvx | Python 3.10+ | Orta | venv yönetimi karışık |
| dotnet | .NET 8 SDK | Kolay (geliştiriciler için) | Sadece geliştirici makinesinde |
| Docker | Docker Engine | Yüksek | Lisans/policy sorunları |
| .mcpb (yeni) | Hiçbir şey yok | Sürükle-bırak gıbı düşünün | Epey rahat ediyor |
Şöyle söyleyeyim, Açık konuşayım, ben uzun süredir Azure MCP Server Artık MCPB Paketi: Runtime Derdi Bitti başlığıyla bunu bekliyordum; o yüzden görünce sevindim. Mantıklı değil mi? Hatta Visual Studio tarafında da benzer bir yaklaşım gelmişti — Azure MCP Visual Studio 2022’de: Eklenti Devri Bitti‘de de anlatmıştım zaten — Microsoft genel olarak MCP entegrasyonunu sürtünmesiz hâle getirmek için baya uğraşıyor, hani lafı gevelemeden söyleyeyim.
Araya gireyim: Tam da öyle.
Üç adımda kurulum: gerçekten bu kadar basit
1. Adım: Doğru.mcpb dosyasını indir
GitHub’daki Azure MCP Server releases sayfasına giriyorsunuz. En güncel release post’unun altında “MCP Bundles” diye bir bölüm var; oradan işletim sisteminize ve mimarinize uyan paketi seçiyorsunuz, yanı Apple Silicon Maç kullanıyorsanız darwin-arm64, Windows x64 tarafındaysanız win-x64 alıyorsunuz, işte hayatı nokta da burada — yanlış mimariyi indirirseniz açılışta pat diye hata veriyor.
Ben kendi M2 Maç’imde darwin-arm64 indirdim, dosya boyutu da yaklaşık 80 MB civarındaydı. Self-contained olduğu için biraz şişkin, evet, ama karşılığında runtime derdiyle uğraşmıyorsunuz; açık konuşayım, bana göre fena olmayan bir takas.
2. Adım: Claude Desktop’a kur
Burada en rahat yol sürükle-bırak. Şöyle ilerliyorsunuz:
- Claude Desktop’ı aç, sol üstteki hamburger menüye (☰) tıkla
- File > Settings > Extensions yoluna git — bunu es geçmeyin
- İndirdiğin.mcpb dosyasını Extensions sayfasına sürükle bırak — bunu es geçmeyin
- Açılan detay penceresinde sunucu bilgilerine bir göz at, sonra Install‘a baş
- Karşınıza çıkan pop-up’ta bir kez daha Install de
Bitti gitti. Kurulum tamamlanınca Install butonu Uninstall’a dönüyor, sunucu da enabled olarak görünüyor; manuel yapmak isterseniz Advanced Settings > Install Extension yolundan da ilerleyebilirsiniz. Hani, sürükle-bırak varken neden kendinize ekstra iş çıkarasınız ki?
3. Adım: Azure kimlik doğrulaması
Burada durun biraz. Sunucu kuruldu ama Azure’a erişimi yok, yanı kimlik doğrulaması gerekiyor. En basit yöntem terminalde Azure CLI ile şu komutu çalıştırmak:
az login
Bu komut tarayıcıda Microsoft hesap ekranını açıyor, siz giriş yaptıktan sonra Claude Desktop tarafındaki MCP sunucusu sizin kimliğinizle Azure’a istek gönderebiliyor. Birden fazla tenant kullanıyorsanız az login --tenant <tenant-id> ile doğrudan istediğiniz tenant’a bağlanabilirsiniz. Daha fazla bilgi için GPT-5.5 GitHub Copilot’ta GA: 7.5x Çarpan Değer mi? yazımıza bakabilirsiniz.
Service Principal ya da Managed Identity ile ilerlemek istiyorsanız AZURE_CLIENT_ID, AZURE_TENANT_ID gıbı environment variable’larla da ayarlayabiliyorsunuz — ama bu taraf daha çok production senaryolarında işe yarıyor. Lokal geliştirme içinse az login çoğu zaman yeterli oluyor. Daha fazla bilgi için Azure Smart Tier GA: Blob Depolamada Otomatik Tasarruf yazımıza bakabilirsiniz. Daha fazla bilgi için GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımıza bakabilirsiniz.
Kurumsal Türkiye perspektifinden bakınca
İlginç olan şu ki, Şimdi işin Türkiye tarafına gelelim. Kurumsal müşterilerde gördüğüm tablo biraz değişik,. MCP gıbı yapay zekâ entegrasyonları herkes için aynı hızda ilerlemiyor; bazı yerlerde ekip hevesli oluyor, bazı yerlerde işe ilk soru hemen güvenlikten geliyor, sonra compliance devreye giriyor, ardından da “peki bunu kim onaylayacak?” muhabbeti açılıyor.
- Endpoint güvenlik politikaları sıkı. Çalışanların makinesinde npm install ya da pip install çalıştırması, birçok bankada ve telekomda yasak..mcpb formatı burada baya iş görüyor çünkü kurumsal endpoint koruma çözümleri “bilinmeyen runtime” diye alarm basmıyor, dolayısıyla ekipler en azından ilk bariyeri daha rahat geçiyor. (bence en önemlisi)
- “AI ne kadar veri görür” sorusu. Bu hâlâ en sık duyduğum soru..mcpb kurulmuş olsa bile sunucu sizin
az logincredential’larınızla çalışıyor; yanı read-only bir kullanıcıyla bağlanırsanız Claude’un yapabildiği şey de read-only kalıyor. İşin aslı RBAC burada kilit rol oynuyor. (bence en önemlisi) - Compliance kaygısı. KVKK, BDDK, EPDK gıbı regülasyonlarla yaşayan müşterilerde “veri Claude API’sine gidiyor mu?” sorusu kritik hâle geliyor. MCP mimarisinde tool çağrıları lokalde çalışıyor ama tool sonuçları Claude’a context olarak iletiliyor; bunu müşteriye açık açık anlatmak lazım, yoksa yanlış beklenti oluşuyor.
Şöyle söyleyeyim, Geçen ay bir telekom müşterisinde bu konuyu epey konuştuk. Operations ekibi “Azure resource’larımızı doğal dille sorgulayalım, sürekli Resource Graph yazmayalım” diyordu; haklılar da. Ama.mcpb gelmeden önce şirket politikası yüzünden geliştirici olmayan SRE ekibine Node.js kurdurtamıyorduk, işte o yüzden süreç tıkalıydı. Şimdi tek dosya var, sürükle-bırak yapıyorsun — küçük bir detay gıbı duruyor ama sahada etkisi ciddi hissediliyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Küçük ekip vs büyük kurum: hangı senaryo size uyar?
Kendi deneyimimden konuşuyorum, Açık konuşayım: Her ortam için aynı yol doğru değil. Bazen startup mantığıyla hızlı gitmek lazım, bazen de adım adım ilerlemek gerekiyor; yoksa işler çorba oluyor.
Küçük ekip / startup iseniz:.mcpb tam size göre olabilir. Geliştirici var ama kimse runtime yönetimiyle uğraşmak istemiyor, hani klasik durum. İndiriyorsunuz, dağıtıyorsunuz, kullanmaya başlıyorsunuz; hatta isterseniz Slack kanalına dosyayı atıp ekipteki herkesin 5 dakikada kurulum yapmasını sağlayabiliyorsunuz.
Orta ölçekli şirket iseniz:.mcpb yine idare eder bir seçim ama burada bir “internal sürüm onay” akışı olsun derim. Yanı sürüm güncellendiğinde otomatik mi geçeceksiniz, yoksa manuel test mi yapacaksınız? Bu sorunun cevabı önemli çünkü MCP sunucusunun yetkileri Azure subscription’ınızdaki kaynaklara dokunabiliyor; küçük bir hata bazen beklenmedik yere gidiyor.
Enterprise / regülasyona tabi sektör iseniz:.mcpb’yi olduğu gıbı dağıtmak yerine internal package repository’nize koymanız daha mantıklı ölür. Sürüm kontrolü, audit trail ve rollback gıbı şeyler burada gerçekten lazım oluyor. Bir de Azure credential tarafında ayrı bir Service Principal yaratın; kullanıcının kişisel hesabıyla değil, adı belli olan bir kimlikle çalışsın ki sonra kimin ne yaptığı daha net izlenebilsin. JetBrains Copilot: Inline Agent Mode ve Yeni Oyuncaklar yazımızda bu konuya da değinmiştik.
Hangı araçlar (tools) geliyor paketle?
Azure MCP Server şu sıralar baya dolu geliyor. Hepsini tek tek saymaya kalksam uzar gider, o yüzden en çok işime yarayanları bırakayım; hani pratikte elimi en sık neye atıyorsam onlar bunlar:
- Resource Graph sorguları: “Tüm storage account’larımı listele, hangileri public access’e açık?” gıbı doğal dil sorularını KQL’e çeviriyor (bu kritik)
- Cosmos DB veri keşfi: Container’ları, partition key’leri, document örneklerini sorgulayabiliyor
- Azure Monitör / Log Analytics: KQL yazdırmak yerine “son 24 saatte hangı VM’lerde CPU %90’ı geçti” diye sorabiliyorsunuz
- Key Vault, Service Bus, Storage: Yapısal işlemler için yardımcı tool’lar
İlk kurcaladığımda bir şey gözüme battı, ama iyi anlamda (bizzat test ettim). Bazı tool’lar “destructive” işleri kendi kafasına göre yapmıyor, önce onay istiyor; yanı bu küçük detay bence kritik. Yapay zekâya “şu resource group’u sil” demek kulağa basit geliyor. Işin üçü kaçarsa sıkıntı büyük olurdu (özellikle production tarafında), o yüzden bu fren mekanizması fena değil. Bu arada Kubernetes Prod Debug Güvenliği: JIT Erişim Rehberi yazımda anlattığım JIT yaklaşımı MCP tarafında da geçerli; kalıcı yetki vermek yerine kısa süreli ve audit edilen yetki vermek daha mantıklı duruyor.
Karşılaştığım bir hata ve çözümü
Yanı, Kurulumun ilk turunda az login yaptım. Sonra Claude Desktop’ı kapatıp açtım. Ama sunucu inatla “credentials not found” diyordu, yanı iş bir türlü rayına oturmuyordu. Yarım saat kurcalayınca şunu fark ettim: Claude Desktop’ı GUI’den açınca, terminal session’ında tanımlı olan AZURE_CONFIG_DIR environment variable’ını görmüyor.
İşin kilidi buydu. MacOS’ta launchctl setenv ile bunu global environment’a vermek gerekiyor; Windows tarafında da benzer şekilde sistem environment variable’ı olarak tanımlamak lazım. Küçük bir ayrıntı gıbı duruyor, ama değil — dokümantasyonda bu nokta biraz daha net yazılsa iyi olurmuş, çünkü yeni başlayan biri burada bayağı oyalanıyor. Daha fazla bilgi için Copilot Chat Pull Request’lerde: Gerçekten Fark Yaratıyor yazımıza bakabilirsiniz.
Genel kural şu: Claude Desktop tool’unuzu çağırmıyor gıbı davranıyorsa, önce
az account showkomutuna bakın. Terminal’de çalışıyor ama Claude tarafında patlıyorsa, sorun büyük ihtimalle environment variable miras alımındadır.
Beklediğim kadar mükemmel değil — eksikler
Şimdi tarafsız konuşayım..mcpb formatı baya iyi bir adım,. Işin içinde birkaç pürüz de var; yanı ilk bakışta “tamam bu öldü” diyorsun, sonra ufak ufak takılıyor insan:
- Otomatik güncelleme yok (henüz). Yeni sürüm çıkınca indirip yeniden kurman gerekiyor. Browser eklentilerinde alıştığımız o sessiz güncelleme rahatlığı burada yok, açık konuşayım, biraz eski usul kalıyor.
- Sadece Claude Desktop “first-class” destekliyor. Diğer MCP-uyumlu istemcilerde teorik olarak çalışıyor, evet, ama deneyim aynı yerde durmuyor; bir tarafta düzgün oturmuş akış var, diğer tarafta “idare eder” hissi biraz belli oluyor.
- Bundle boyutu büyük. 80 MB tek bir tool seti için az buz değil. Self-contained olmanın bedeli bu, kabul, ama yine de indirirken insanın aklına ilk gelen şey “bu kadar da mı?” oluyor.
- Logging/debug deneyimi zayıf. Bir şey patladığında nereye bakacağını bulmak zorlaşıyor. Geliştirici dostu sürümde stdout’u görebiliyorsun,.mcpb tarafında işe bu kapalıya yakın duruyor; işte asıl sıkıntı da burada başlıyor.
Evet.
Evet, doğru duydunuz.
Yine de net söyleyeyim: Bu format kalıcı gıbı duruyor. Microsoft, OpenAI ve Anthropıc MCP konusunda aynı çizgiye yaklaşınca, paketleme standardının da toparlanması kaçınılmazdı zaten (hani bazen teknoloji tarafında herkes ayrı telden çalar ya, burada o gürültü biraz azalıyor). Önümüzdeki 6-12 ay içinde diğer Microsoft MCP sunucularının da — mesela Azure DevOps MCP Server Nişan Güncellemesi: Neler Değişti? yazımda bahsettiğim DevOps MCP gıbı —.mcpb formatına geçeceğini tahmin ediyorum. Peki neden? Çünkü ekosistem yavaş yavaş oraya itiliyor ve bu kez yön pek değişecek gıbı görünmüyor.
Tam da öyle.
İlk adım rehberi: Bugün ne yapın?
Lafı uzatmadan söyleyeyim, bu yazıyı okuyup “tamam, ben bunu bir deneyeyim” diyenler için iş gören bir yol haritası var:
- Azure CLI’ınız yoksa kurun:
brew install azure-cliveya Windows installer - Test için bir non-prod Azure subscription’ı belirleyin — production’da deneme yapmayın! — bunu es geçmeyin
- GitHub releases’dan platform’unuza uygun.mcpb’yi indirin
- Claude Desktop’a sürükle-bırak ile kurun — bunu es geçmeyin
az loginyapıp test sorgusu atın: “Bu subscription’da kaç tane resource group var?”- Sonuçları audit log’larda kontrol edin — Claude’un sizin adınıza ne yaptığını görmek önemli
Bu son madde önemli. Hatta biraz can sıkıcı derecede önemli. Siz ne dersiniz? Yapay zekâ asistanlarının yetkilerini test etmeden production’a yaklaştırmayın; ben kendi makinemde bile ilk haftalar boyunca her tool çağrısının Azure Activity Log’da nasıl göründüğünü tek tek izledim, çünkü işin aslı bazen küçük bir deneme sandığınız şey, yanlış izinle beklenmedik yere dokunabiliyor.
Sıkça Sorulan Sorular
.mcpb dosyası güvenli mi? İçinde ne çalışıyor?
İçinde Azure MCP Server’ın derlenmiş binary’si ve runtime bağımlılıkları var. Microsoft’un resmî GitHub releases’ından indirdiğiniz sürece güvenli. SHA hash kontrolü yapmak istiyorsanız release sayfasındaki checksum’larla karşılaştırabilirsiniz. Ama şunu da söyleyeyim — üçüncü taraf kaynaklardan.mcpb indirmeyin, aklınızdan bile geçirmeyin.
Aynı anda hem.mcpb hem npm/dotnet kurulumu çalışır mı?
Şunu fark ettim: Teknik olarak çalışıyor, ama bence gereksiz bir karmaşa yaratıyor. Yanı aynı tool’u iki farklı yerden register etmiş oluyorsunuz, Claude hangisini çağıracağına karar verirken kafası karışabiliyor. Siz ne dersiniz? Birini seçin, diğerini kaldırın — açıkçası bu kadar basit.
Production Azure ortamına bağlamak güvenli mi?
Bakın, i̇lginç olan şu ki, “Güvenli” derecesi aslında sizin RBAC konfigürasyonunuza bağlı. Mesela kullandığınız credential’ın Owner yetkisi varsa, Claude da teorik olarak Owner gıbı davranabiliyor. Tecrübeme göre en mantıklısı şu: read-only bir Service Principal yaratın,.mcpb sadece o credential’la konuşsun. Yazma işlemleri için de mutlaka manuel onay süreci ekleyin.
Claude Desktop dışında hangı istemciler destekliyor?
MCP standardını destekleyen tüm istemciler teorik olarak.mcpb dosyalarını kullanabiliyor (yanlış duymadınız). Ama açıkçası şu an en sorunsuz deneyim Claude Desktop’ta. Cursor, Continue.dev gıbı alternatiflerde “manifest.json”u manuel okuyup config eklemeniz gerekebiliyor — hani biraz uğraş istiyor yanı.
Kurumsal proxy arkasında çalışır mı?
Çalışıyor, ama HTTPS_PROXY ve HTTP_PROXY environment variable’larını sistem genelinde tanımlamanız gerekiyor. Bir de şu var — Azure CLI’ın da aynı proxy’den geçmesi lazım, yoksa az login takılıp kalıyor. Kurumsal CA sertifikanız varsa önü da güven listesine eklemeyi unutmayın.
Kaynaklar ve İleri Okuma
Azure SDK Blog: Azure MCP Server now available as an MCP Bundle — Orijinal duyuru, teknik detaylar burada.
Azure MCP Server GitHub Repository — Releases, issue tracker, dokümantasyon. Sürüm güncellemelerini buradan takıp edin.
Model Context Protocol Resmî Sitesi — MCP standardının kendisi, spec dokümanları ve diğer uygulayıcılar.
Azure CLI Authentication Dokümantasyonu — az login alternatifleri, Service Principal kullanımı, environment variable’lar için referans.
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.



