Azure DevOps MCP Server Nisan Güncellemesi: Küçük Dokunuşlar, Büyük Etki
Bunu yaşayan biri olarak söyleyeyim, Azure DevOps tarafında bazen öyle güncellemeler geliyor ki, ilk bakışta “tamam, birkaç tool eklenmiş” deyip geçiyorsunuz. Ama biraz eşelediniz mi tablo değişiyor; mesele tool sayısı değil, o araçların nasıl paketlendiği, LLM’in onlarla ne kadar kontrollü konuştuğu. Kurumsal tarafta işin ne kadar yürür kaldığı (bizzat test ettim). Bu Nisan güncellemesi de tam o sınıfa giriyor.
Açık konuşayım, ben bu tip MCP güncellemelerine sadece teknik merakla bakmıyorum (ben de ilk duyduğumda şaşırmıştım). Azure danışmanlığı yaptığım için, bir değişikliğin demo ortamında güzel görünmesi bana yetmiyor; güvenlik ekibi bunu kabul edecek mi, proje yöneticisi bunu günlük akışa sokabilecek mi, maliyet tarafı şişecek mi — ben bunlara bakıyorum. Hani işin mutfağı biraz başka oluyor ya, işte orası önemli.
Şimdi gelelim işin can alıcı noktasına.
Bu yazıda Azure DevOps MCP Server’ın Nisan güncellemesini kendi gözümden anlatacağım (ben de ilk duyduğumda şaşırmıştım). WIQL ile work item sorguları, remote taraftaki annotation yaklaşımı, eksik tool’ların tamamlanması, wiki araçlarının yeniden düzenlenmesi ve local server tarafında gelen PAT desteği (ciddiyim). Bir de elbette benim yorumum var: kağıt üstünde çok iyi duran bazı parçalar pratikte biraz daha pişmeye ihtiyaç duyuyor.
Neden bu güncelleme önemli?
MCP Server dünyasında asıl mesele şu: LLM’e erişim veriyorsunuz ama kontrolü kaybetmek istemiyorsunuz. Azure DevOps gibi yüzeyi geniş bir platformda bu daha da kritik hâle geliyor. Bir yanda work item’lar, wiki’ler, repo işlemleri; diğer yanda güvenlik sınırları ve kullanıcı deneyimi… Bu dengeyi tutturmak hiç kolay değil.
Peki neden?
Şunu söyleyeyim, Ben 2024 sonlarında bir finans kuruluşunda Azure DevOps entegrasyonu üzerine çalışırken benzer bir sıkıntı yaşamıştım. Ekipler “her şeyi tek yerden konuşalım” diyordu ama güvenlik grubu doğal olarak frene basıyordu. Bilhassa yazma yetkisi olan araçlar için açık sınırlar yoksa iş çığırından çıkabiliyor. Bu yüzden annotation yaklaşımı bana baya mantıklı geldi; çünkü araca etiket koymak kulağa küçük geliyor. Model davranışını yönlendirmede ciddi fark yaratıyor.
Bak şimdi, Bir de Türkiye tarafına bakalım. Burada enterprise müşteriler genelde “önce on-prem zihniyetiyle güvenliği çözeyim, sonra yapay zekâya açılırım” diyor. Startup tarafı işe tersinden gidiyor; hızlı değer görmek istiyorlar. Yanı aynı MCP Server iki farklı dünyada bambaşka okunuyor. Küçük ekipte hız kazanırsınız, büyük kurumda işe en başta denetim ve yetkilendirme kazanır.
WIQL sorgusu artık daha anlamlı
Şöyle söyleyeyim, Nisan güncellemesindeki en dikkat çekici parçalardan biri wit_query_by_wiql aracı öldü (kendi tecrübem). Work item’ları doğrudan WIQL ile sorgulamak güzel fikir; çünkü gerçek hayatta çoğu ekip filtreleme işini zaten böyle yapıyor. Tarihe göre açık işler, belirli kişiye atanmış kartlar, sprint bazlı kırılımlar… Tahmin eder mısınız? Bunlar klasik dashboard dışında da lazım oluyor.
Şunu söyleyeyim, Remote MCP tarafında bunun şimdilik Insiders özelliğiyle sınırlı tutulması bence doğru karar. Çünkü performans ve güvenilirlik konusu burada ince bir çizgi. Geçen ay İzmir’de bir müşteride buna benzer bir senaryoda fazla geniş sorgu açılmıştı ve cevap süresi beklediğimizden kötü çıktı. Sorun tool’un kendisinde değilmiş aslında; sorgu desenleri çok serbest bırakılmıştı. İşin aslı şu ki LLM’e her şeyi serbest verirseniz güzel görünür ama sistem nefes nefese kalır (buna dikkat edin)
İşte tam da bu noktada devreye giriyor.
LLM entegrasyonlarında en pahalı hata genelde model maliyeti değil; yanlış tasarlanmış tool yüzünden büyüyen operasyon yükü oluyor.
Remote MCP tarafında güvenlik dili değişiyor
Annotation konusu dışarıdan bakınca ufak bir metadata detayı gibi durabilir ama bence hikâyenin kalbi orası. Read-only, destructive ve openWorld ayrımı sayesinde modelin hangi aracı nasıl kullanacağına dair ortak bir dil oluşuyor (yanlış duymadınız). Yanı araç ismi tek başına yetmiyor; arkasındaki risk seviyesi de anlatılıyor.
Bunu 2019’da kendi lab ortamımda ilk kez API gateway kurarken yaşamıştım. O zaman da herkes endpoint listesini görüyor diye rahat hissediyordu ama izinlerin niyeti net değildi. Sonra loglara baktığınızda bazı çağrıların neden bu kadar agresif olduğunu anlayamıyordunuz bile… Şimdi MCP annotation mantığıyla benzer bir boşluk kapanıyor gibi görünüyor.
E tabi burada küçük bir hayal kırıklığı da söyleyeyim: annotation fikri iyi ama henüz tam oturmuş hissettirmiyor (en azından benim deneyimim böyle). Mesela de farklı client’ların bu metadataları ne kadar disiplinli okuyacağı konusu açıkta kalıyor. Kağıt üstünde süper dürüyor, pratikte göreceğiz artık.
| Alan | Güncelleme | Bana göre etkisi |
|---|---|---|
| Work item sorguları | WIQL desteği | Daha esnek filtreleme |
| Remote güvenlik | MCP annotations | Daha net risk ayrımı |
| Tool seti | Konsolidasyon | Daha az karmaşa |
| Local auth | PAT desteği | Daha kolay kurulum |
Araçları azaltmak bazen artırmaktan iyidir
MCP server’larda hep aynı problem var: platform büyüdükçe tool sayısı da şişiyor. Sonra hem kullanıcı hem model kayboluyor. Microsoft’un wiki araçlarını toplulaştırmaya başlaması bana bu yüzden doğru geliyor. Az araç = daha az belirsizlik demek değil sadece; aynı zamanda daha temiz karar ağacı demek.
Çok konuştum, örnekle göstereyim.
Yanı, Birkaç ay önce Ankara’da orta ölçekli bir üretim firmasının ekibinde buna yakın bir yapı gördüm (en azından benim deneyimim böyle). Onlarda eski sistemde altı farklı “listele”, “getir”, “oku” varyasyonu vardı. Insanlar hangi aracın ne zaman kullanılacağını karıştırıyordu. Tool sayısı fazla olunca otomasyon güçlenmiyor her zaman; bazen tam tersi oluyor — kafa karışıklığı artıyor. Bu konuyla ilgili GitHub Code Quality API: Repo Bazlı Açma-Kapama Dönemi yazımıza da göz atmanızı tavsiye ederim.
wiki araçlarının birleşmesi ne kazandırıyor?
wiki_get_page_content ile wiki_get_page arasındaki farkı ezberlemek yerine tek bir wiki yüzeyiyle ilerlemek çoğu senaryoda daha mantıklı olurdu. Diye düşünüyordum ben de açıkçası. Yeni yapı tam da bunu yapıyor gibi dürüyor: okuma için ayrı uçlar yerine tek çatı altında sadeleşme (en azından benim deneyimim böyle)
Bak şimdi, Küçük startup için bu çok rahatlatıcıdır; geliştirici sabah kodu yazar akşam test eder ve yoluna devam eder tabiî. Ama enterprise tarafta durum farklıdır: burada sadeleşme yanında geriye dönük uyumluluk planı da isterler (şaşırtıcı ama gerçek). Hele bir de change management takımları “bu eski tool ne olacak?” sorusunu hemen sorar. Bu konuyla ilgili Copilot Memory’de Yeni Kontrol Dalgası: Silme, Kapsam ve CLI yazımıza da göz atmanızı tavsiye ederim.
Local server tarafında PAT desteği neden sevindirici?
PAT desteği benim gözümde kullanım bariyerini baya düşüren bir adım öldü. Copilot" data-glossary-term="GitHub Copilot">GitHub Copilot gibi dış servislerle entegrasyonda kimse sırf authentication uğruna yarım gün harcamak istemez. Daha doğrusu isterdi eskiden… İlginç, değil mi? şimdi o sabır pek yok.
Lafı gevelemeden söyleyeyim: lokal geliştirme yapan ekipler için PAT hâlâ hızlı çözüm veriyor ama uzun vadeli kurumsal standart olarak Entra ID temelli akışların önüne geçmemeli. Ben AZ-104 ve AZ-500 hazırlıklarında da hep bunu anlattım; kısa vadede kolaylık sağlayan yöntem ile uzun vadede yönetilebilir yöntem aynı şey değil. Daha fazla bilgi için Claude Opus 4.8 GitHub Copilot’a Geldi: Peki Gerçekte Ne Değişiyor? yazımıza bakabilirsiniz.
Eğer bütçe kısıtlıysa ne yapmalı?
- Önce local server ile başlayın; küçük pilot kurun.
- PAT kullanımını sadece geliştirme ortamıyla sınırlayın.
- Telemetry toplayın; hangi tool gerçekten kullanılıyor görün.
- Sonra remote preview’a geçip erişimi daraltın.
- Kritik işler için read-only akışı ayrı tutun.
{
"server": "azure-devops-mcp",
"auth": {
"mode": "pat"
},
"tools": [
"wiki",
"wit_query_by_wiql",
"repo_get_file_content"
]
}Elicitations konusu niye ilginç?
Elicitations biraz sessiz gelen ama deneyimi toparlayan özelliklerden biri olabilir. Kullanıcıdan eksik bilgiyi nazikçe istemek — mesela proje seçimi gibi — özellikle yeni başlayanlar için faydalı olur. Ben bunu geçen yıl Bursa’da iç portal otomasyonu kurarken çok hissettim; insanlar doğru projeyi seçmediğinde bütün işlem zinciri bozuluyordu. GitHub Copilot Model Yönetiminde Yeni Dönem: Kuralları İnce Ayarla yazımızda bu konuya da değinmiştik.
Ama dürüst olayım: community talebi şu an çok güçlü görünmüyor işe geniş rollout yapmak erken olabilir. Microsoft’un burada kontrollü gitmesini mantıklı buluyorum. Her iyi fikir hemen yaygınlaştırılmaz; bazen önce dar alanda ölçersiniz, sonra açarsınız. Bu konuda %100 emin değilim ama sanırım doğru strateji bu. GitHub Copilot’ta.NET İşini Doğru Yerden Tutmak yazımızda bu konuya da değinmiştik.
Bana göre asıl mesaj ne?
Bence bu güncellemenin ana mesajı şu: Azure DevOps MCP Server artık sadece “araç sunan” bir yapı olmaktan çıkıp “araçları nasıl sunacağını düşünen” bir yapıya evriliyor. Bu önemli çünkü AI entegrasyonlarında kaliteyi belirleyen şey çoğu zaman modelin zekâsı değil, ona verilen yüzeyin düzeni oluyor.
Bir de şu var: Türkiye’de birçok kurum hâlâ pilot aşamasında olduğu için böyle değişiklikler direkt üretime alınmıyor. Önce PoC yapılıyor, sonra üç toplantı daha yapılıyor, sonra güvenlik onayı bekleniyor… Normal yanı. O yüzden benim tavsiyem basit:Denemek istiyorsanız ilk iş read-only tool’larla başlayın,sonra WIQL gibi kontrollü senaryolara geçin.
Zaman zaman AI dünyasında her şey parlak gösteriliyor ama burada öyle değil. Güzel gelişmeler var,evet;ama tooling konsolidasyonu tamamlanmadan büyük vaatlere kapılmamak lazım. Ben şahsen yönü doğru buluyorum,yalnız henüz bitmiş iş gibi konuşmam.
Sıkça Sorulan Sorular
MCP Server ne iş yapar?
MCP Server, hani LLM uygulamalarının dış sistemlerle standart bir şekilde konuşabilmesini sağlayan katman aslında. Azure DevOps özelinde work item, repo, wiki gibi kaynaklara kontrollü erişim veriyor.
wit_query_by_wiql aracı herkese açık mı?
Hayır, şu an remote MCP tarafında Insiders özelliğiyle sınırlı tutuluyor. Yanı performans ve güvenilirlik testleri hâlâ devam ediyor, o yüzden kısıtlı.
PAT desteği local kullanım için yeter mi?
Küçük ekipler için açıkçası gayet iş görüyor. Ama kurumsal ortamlarda uzun vadede Entra tabanlı kimlik modeli daha sağlıklı — bence geçişi ertelemek pek mantıklı değil.
Araç konsolidasyonu neden bu kadar önemli?
Aynı işi yapan fazla tool olması hem kullanıcıyı hem de modeli gereksiz yere yoruyor. Konsolidasyon mesela sadeleştirme sağlıyor ve bakım yükünü ciddi ölçüde azaltıyor. Tecrübeme göre bu fark zamanla çok hissediliyor.
Elicitations gerçekten işe yarıyor mu?
Bazı akışlarda kesinlikle yarıyor, özellikle eksik bilgi toplamak gerektiğinde çok faydalı. Ama her senaryoda şart değil; o yüzden kontrollü yaygınlaştırma bence en mantıklı yol.
Kaynaklar ve İleri Okuma
Azure DevOps MCP Server April Update — Orijinal Duyuru
Azure DevOps WIQL Syntax Resmî Dokümantasyonu
Açık konuşayım, Azure DevOps Personal Access Token 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.
0 comments