Açık konuşayım: Azure DevOps MCP Server’ı ilk duyduğumda biraz mesafeli yaklaştım. Çünkü “model-tool” entegrasyonları son bir yılda öyle hızlı çoğaldı ki, hangisi gerçekten iş görüyor, hangisi sadece demo ekranında parlıyor, ayırt etmek ayrı dert öldü. Ama Nişan güncellemesini kurcalayınca, hele bir müşteride remote MCP’yi bağlayıp canlıda görünce, fikrim yavaş yavaş değişti.
Şöyle anlatayım. Logosoft’ta bir sigorta şirketinin Azure Boards tarafında çalışıyoruz — yaklaşık 400 aktif work item, 12 takım, birbirine giren sprint yapıları var (en azından benim deneyimim böyle). Geliştirici ekip Copilot kullanıyor zaten. “Şu sprintte kalan bug’ları listele” dedirttiğimde, MCP olmadan LLM elini kolunu sallayıp duruyor. MCP ile? Bir dakika içinde WIQL sorgusunu kurup cevabı getiriyor. Fena değil. İşte bu Nişan güncellemesi de o dakikayı 15 saniyeye çeken birkaç iyileştirme getiriyor.
WIQL ile Work Item Sorgulama: Asıl Oyun Değiştirici
wit_query_by_wiql aracı, bu güncellemede benim gözüme en çok çarpan parça öldü. Burada, neden mi? Çünkü Azure DevOps’un asıl tadı, dashboard’larda değil, WIQL’in elini kolunu biraz daha serbest bırakmasında yatıyor; basit sorguları zaten arayüzden hallediyorsunuz ama bir sprintte iki takımın ortak yürüttüğü epic’leri, bağlı PR’ları. Blocked etiketli item’ları yan yana görmek istiyorsanız, işte orada WIQL devreye giriyor.
Şu an remote MCP tarafında bu özellik sadece Insiders bayrağı açık olanlara veriliyor. Mantıklı aslında. Microsoft önce biraz telemetri topluyor, performansa bakıyor, sonra geniş kitleye açar; ben de açık konuşayım, kurumsal tarafta yeni LLM özelliklerini “geniş kitle” etiketi gelmeden production’a sokmam, önce Insiders’ta denerim, gözlemlerim, sonra karar veririm (şaşırtıcı ama gerçek)
Bir ipucu: WIQL sorgusu yazdırırken LLM’e “sadece sorguyu kur, çalıştırma” demek baya işe yarıyor. Önce sorguya bakın, bir kenarda düşünün, sonra onaylayıp çalıştırın. Bilhassa büyük projelerde yanlış bir
WHEREkoşulu binlerce item’ı çekebiliyor (quota gidiyor, context şişiyor), yanı küçük bir hata bazen gereksiz yere büyük bir masraf çıkarıyor.
Türkiye’deki Ekipler İçin Bu Ne Anlama Geliyor?
Kurumsal müşterilerde gördüğüm tablo biraz karışık, nasıl desem, Türkiye’deki Azure DevOps kullanımı tek tipe oturmuyor. Bir tarafta Boards’u deli gıbı kullanan ama Pipelines tarafında hâlâ Jenkins’ten kopamayan ekipler var; diğer tarafta Pipelines’a tamamen geçmiş olup Boards yerine Jira’da direten takımlar var. Aynı ürün ailesi içinde iki ayrı dünya yanı.
Boards ağırlıklı çalışan biriyseniz, WIQL aracı anında iş görüyor. Çünkü project manager’lar sprint raporu çıkarırken zaman kaybediyor, boşuna değil. İstanbul’daki bir bankada çalışan bir scrum master arkadaşım vardı; haftada yaklaşık 6 saatini sadece work item raporlamasına ayırıyordu. MCP ile Copilot’u birlikte kullanınca bu süreyi 1.5 saate indirdiğini söyledi; ben önce “abartı olmasın” dedim ama sonra izledim — valla öyleymiş.
Remote MCP Server Tarafındaki Değişiklikler
Annotations: LLM’e “Bu Araç Tehlikeli” Demek
MCP Annotations ilk bakışta ufak bir detay gıbı duruyor. Ama production’a gelince işler değişiyor, ciddi fark yaratıyor. Kısacası her araca üç tür etiket ekleniyor:
- read-only: Sadece okur, veriyi değiştirmez. Güvenli taraf.
- destructive: Veri değiştirir ya da siler. Burada iki kere düşünmek lazım.
- openWorld: Dış sistemlerle konuşur, sonuç biraz sürprizli olabilir.
Şimdi, peki neden? Çünkü LLM’ınız bir work item’ı silmeye kalkarsa, annotation sayesinde bunun destructive olduğunu anlayabiliyor; sonra kullanıcıdan teyit isteyebiliyor ya da agent katmanı bu çağrıyı direkt kesebiliyor. Geçen ay bir finans kuruluşunda yaptığımız agentic workflow tasarımında aynısını elle kurmuştuk (epey uğraştırdı, açık konuşayım), şimdi Microsoft bunu standart hâle getiriyor — fena değil.
Eksik Araçlar Kapanıyor
Nişan tarafında güzel bir toparlama var. Local ve remote MCP arasındaki mesafe baya kapanıyor. Şunlar eklendi:
repo_get_file_content— Bir dosyanın içeriğini çekmek içinrepo_list_directory— Klasör listelemek içinrepo_vote_pull_request— PR onayı vermek için (bence en önemlisi)
Bak şimdi, Bence bunlar beklenen araçlardı. Hatta biraz gecikmiş bile diyebilirim. Bir Copilot agent’ına “şu dosyanın PR öncesi hâlini göster” dediğinizde işin özü zaten burada yatıyor; review akışı böyle dönüyor. Vote PR kısmı işe başka bir hikâye — LLM’in kendi başına PR onaylamasına sıcak bakmıyorum, şey yanı, o çizgi biraz kaygan. Ama human-in-the-loop senaryoda “bu PR’a şartlı onay ver” gıbı bir akışta gayet iş görüyor.
Tool Restructuring: Daha Az Araç, Daha İyi Performans
Bak şimdi, asıl kilit nokta burası. Azure DevOps’un alanı çok geniş; Boards var, Repos var, Pipelines var, Wiki var, Test Plans var, Artifacts var… Hepsini tek tek tool diye açınca LLM ne yapacağını şaşırıyor (özellikle tool sayısı 40’ı geçince yanlış seçimler bariz artıyor). Deneyimle sabit; bu kadar çok seçenek olunca model bazen doğru kapıyı bulamıyor.
Doğrusu, Microsoft bunu fark etmiş ve wiki tool’larıyla başlayıp konsolidasyona gitmiş. Yeni yapı şöyle görünüyor:
| Yeni Tool | Tıp | Yerine Geçtiği Eski Tool’lar |
|---|---|---|
wiki |
Read-only | wiki_get_page, wiki_get_page_content, wiki_list_pages, wiki_list_wikis, wiki_get_wiki |
wiki_upsert_page |
Write | wiki_create_or_update_page |
search_wiki |
Search | search_wiki |
Kafanız karışmasın diye söyleyeyim: artık tek bir wiki tool’u içinde action parametresiyle farklı işler yapılıyor;
Evet. .NET Nisan 2026 Güvenlik Güncellemeleri: CVE Analizi yazımızda bu konuya da değinmiştik. Daha fazla bilgi için .NET MAUI 11’de Harita Pin Kümeleme: Pratik Rehber yazımıza bakabilirsiniz. Daha fazla bilgi için Kubernetes v1.36 ile Gelen Değişiklikler ve Notlarım yazımıza bakabilirsiniz.
Local MCP Server: PAT Desteği ve Elicitations
Personal Access Token ile Kimlik Doğrulama
Bu iyileştirmeyi ben baya sevdim. Neden mi? Çünkü ilk kurulumda başıma gelen şey şuydu: MCP Server’ı local Copilot’a bağlamak istedim, ama Entra ID flow bir türlü rayına oturmadı. Proxy arkasındaydık, conditional access politikaları da üstümüze üstümüze geliyordu… açık konuşayım, insanın hevesi kırılıyor. O an “keşke PAT kullansam” dedim.
Şunu fark ettim: Şimdi bu seçenek var. Bilhassa dış sistemlerle çalışan ekipler için, self-hosted agent’lar için ya da CI tarafında MCP çağrısı yapan senaryolarda PAT gerçekten iş görüyor. Ama burada bir durup nefes almak lazım:
Elicitations: Yönlendirilmiş Sorular
Elicitations dediğimiz şey, LLM’in eksik bilgiyi sizden istemesi için kullanılan mekanizma. Mesela work item oluşturacaksınız ama hangı projeye gideceği belli değilse, MCP Server artık size “hangı proje?” diye sorabiliyor (ben de ilk duyduğumda şaşırmıştım). Basit gıbı duruyor, ama baya fark ediyor.
Microsoft bu konuda biraz temkinli davranıyor, şey yanı, topluluktan beklenen talep tam gelmemiş gıbı görünüyor. Ben buna kısmen katılıyorum. Çünkü iyi yazılmış bir system prompt ile context birleşince bu bilgilerin çoğu zaten çıkıyor. Ama multi-project ortamlarda durum değişiyor; yukarıda anlattığım testte 8 farklı Azure DevOps projesine erişimi olan bir kullanıcı vardı. Siz ne dersiniz? Elicitation olmadan LLM neredeyse her seferinde yanlış projeyi seçiyordu.
Pratik Başlangıç: İlk Adımlar
Peki, bu yeniliklere nereden girilir? Ben olsam lafı uzatmadan şu sırayla giderim — müşterilerde de çoğu zaman bu çerçeve iş görüyor,. Tabii her ortamın derdi biraz farklı oluyor:
- Önce local MCP kurun. Remote tarafı hâlâ tam oturmadı, local’de deneyim daha sakın ve daha az sürprizli oluyor.
- PAT oluşturun, scope’u dar tutun. Expire süresini 90 gün yapın, sonra da takvime not düşün; unutuluyor, biliyorum.
- Küçük bir projede deneyin. Production Boards’unuzu ilk deneme alanı yapmayın, orada hata çıkarsa can sıkıyor.
- WIQL araçlarını Insiders’ta etkinleştirin, birkaç gün izleyin. Hani bazen ilk gün her şey yolunda görünür ya, asıl tablo sonra çıkıyor.
- Ekip kullanımına açmadan önce destructive tool’lar için onay flow’u kurun. Evet, bu kısım biraz sıkıcı geliyor ama sonradan “keşke” dememek için lazım.
Örnek bir MCP config’i (Copilot için): (evet, doğru duydunuz)
{
"mcpServers": {
"azure-devops": {
"command": "npx",
"args": ["-y", "@azure-devops/mcp-server"],
"env": {
"ADO_ORG": "your-org-name",
"ADO_PAT": "your-pat-token",
"ADO_INSIDERS": "true"
}
}
}
}Küçük Ekip vs Enterprise: Farklı Yaklaşımlar
Dürüst olmak gerekirse, Küçük bir startup’sanız ya da 5-10 kişilik bir ekipseniz, local MCP ile PAT kombinasyonu baya iş görüyor. Kurulumu 15 dakika sürüyor, maliyet sıfıra yakın, risk de düşük kalıyor. Ben kendi küçük projelerimde bunu böyle kullanıyorum, açık konuşayım. Bu konuyla ilgili değişti ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Enterprise tarafına geçince iş biraz dağılıyor. Hani 50+ geliştirici, bölünmüş takımlar, üstüne bir de compliance baskısı varsa, tablo değişiyor; remote MCP’ye dönmek, Entra ID entegrasyonu kurmak. Conditional access policy’leri MCP trafiğine göre yeniden yazmak daha mantıklı oluyor. Bir telekom projesinde biz tam olarak bunu yaşadık. İlk turda PAT ile başladık, sonra neredeyse tüm geliştiricileri Entra ID flow’una aldık, en sonda audit log akışını Sentinel’e yönlendirdik. Toplam süre? Yaklaşık 6 hafta. Az değil.
Maliyet Tarafı: TL Bazında Ne Görünüyor?
MCP Server’ın kendisi ücretsiz, evet. Ama işin içinde küçük bir tuzak var; MCP çağrıları LLM context’ını şişiriyor, yanı modelin önüne daha fazla veri koyuyorsunuz. Bu da token sayısını yükseltiyor, özellikle de bir WIQL sorgusu 20-50 work item dönduruyorsa, request başına 3-5K token eklenmesi hiç zor değil. Bu konuyla ilgili Ingress’ten Gateway API’ye Geçiş: 1.0 Rehberi yazımıza da göz atmanızı tavsiye ederim.
Copilot Business kullanıyorsanız, kullanıcı başı yaklaşık 19 USD/ay civarında gidiyor ve token derdi pek yok. Ama kendi Azure OpenAI kotanızdan GPT-4 çağırıyorsanız, burada tablo değişiyor; yoğun MCP kullanan bir geliştirici ay sonunda kabaca 200-400 TL arası ek maliyet çıkarabiliyor. Peki neden? Çünkü veri çok geliyor, model de bunu yiyor.
Açık konuşayım, Eğer bütçe sıkışık işe, şunu denemek baya iş görüyor: MCP aracılığıyla gelen veriyi önce özetleyen bir ara agent yazın. Yanı 50 work item yerine LLM’e “bu 50 item’dan kritik olan 5’i şunlar” gıbı kısa bir özet gönderin; açık konuşayım, maliyetin yarıya indiğini görmek şaşırtmıyor. Azure MCP Visual Studio 2022’de: Eklenti Devri Bitti yazısında da benzer bir pattern’den bahsetmiştim.
Şimdi gelelim işin can alıcı noktasına.
Karşılaştığım Bir Sorun ve Çözümü
Dürüst olayım. Bu güncellemeyi ilk kurcaladığımda wit_query_by_wiql aracı bana 403 dönüyordu, ben de bir süre “neden şimdi?” diye ekrana bakıp durdum. İki saat gitti; sonra fark ettim ki remote MCP tarafında Insiders bayrağını açmayı unutmuşum (organization settings → Preview Features → Azure DevOps MCP Insiders). Basitmiş, evet, ama insan başına gelince bayağı saçma hissettiriyor. Siz aynı yere takılmayın.
Açık konuşayım, Bir başka mesele de şu öldü: Tool restructuring sonrası eski tool adlarıyla yazdığım prompt’lar dağıldı. Yanı wiki_get_page artık çalışmıyor, onun yerine wiki tool’unu action: "get_page" ile çağırmak gerekiyor; ilk anda ufak bir detay gıbı duruyor ama agent prompt’u içinde her şeyi domino taşı gıbı etkiliyor. Eski prompt’larınızı bir yoklayın derim.
İlgili Yazılar
Bu konuyla yakından alakalı birkaç yazım var, vakit bulursanız göz atın:
- Azure DevOps Advanced Security: Tek Tıkla CodeQL Devri
- Azure Developer CLI ve Copilot: Terminalde AI Dönemi
Sıkça Sorulan Sorular
Azure DevOps MCP Server’ı kurmak için Premium lisans gerekiyor mu?
Hayır, Basic lisans yeterli. MCP Server için ayrıca para (söylemesi ayıp) ödemiyorsunuz; aslında şöyle düşünün — Azure DevOps organizasyonunuzda hangı yetkilere sahipseniz, MCP üzerinden de aynı şeyleri yapabiliyorsunuz, ne fazlası ne eksiği (evet, doğru duydunuz). PAT kullanıyorsanız, orada da belirleyici olan PAT’in scope’u.
Local MCP mi, Remote MCP mi kullanmalıyım?
Bakın, dürüst olmak gerekirse, Tek başınıza çalışıyorsanız ya da küçük bir ekipseniz local çok daha pratik, kurulumu da basit. Ama kurumsal bir ortamdaysanız ve — kendi adıma konuşayım — Entra ID entegrasyonu, audit log akışı, merkezî kontrol gıbı şeyler istiyorsanız remote MCP daha mantıklı. Şunu da söyleyeyim: Nişan 2025 itibarıyla remote hâlâ public preview’da, yanı bazı araçlar local’de var. Remote’da henüz yok.
Şimdi gelelim işin can alıcı noktasına.
WIQL olmadan work item sorgulaması yapılabilir mi?
Yapılabilir, ama sınırlı kalıyor. Temel listeleme ve tekil item okuma için diğer tool’lar genelde yeterli. Ancak mesela çok kriterli sorgular, cross-project aramalar ya da tag/link kombinasyonlu filtreler için WIQL şart. Bence Insiders bayrağını açıp WIQL’i aktif etmek en doğrusu (ciddiyim)
MCP Server production ortamında güvenli mi?
“Güvenli” derken neyi kastettiğinize bağlı aslında. MCP protokolünün kendisi zararlı bir şey yapmıyor, ama LLM’in destructive bir tool çağırma ihtimali var. Annotations sistemi bu riski biraz azaltıyor; yine de tecrübeme göre production’da human-in-the-loop yaklaşımından vazgeçmemek lazım (kendi tecrübem). En çok da silme işlemleri ve PR merge gıbı şeylerde otomatik onay vermeyin, ciddi söylüyorum.
PAT yerine Entra ID ile kimlik doğrulama yapılabilir mi?
Evet, mümkün — hem de önerilen yol bu zaten. Ama açıkçası kurumsal ağlarda ilk kurulum biraz sancılı olabiliyor; proxy, conditional access, MFA zorunlulukları derken baş ağrıtabiliyor. Bence önce PAT ile başlayıp sistemi tanıyın, sonra Entra ID’ye geçin. Hem daha az stres, hem daha sağlıklı bir geçiş ölür.
Kaynaklar ve İleri Okuma
Azure DevOps MCP Server April Update — Orijinal Duyuru
Azure DevOps Resmî Dokümantasyonu
Model Context Protocol Resmî Sitesi
Azure DevOps MCP GitHub Deposu
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.
