AI kod asistanlarıyla çalışırken bazen ilginç bir durumla karşılaşıyorum. Önerilen kod gayet mantıklı görünüyor, değişken isimleri yerinde, mimari de ilk bakışta fena değil. Sonra projeyi derliyorum ve kullandığım kütüphanede önerilen metodun bulunmadığını görüyorum. Bazen de asistan, güncel sürümünü kullandığım bir paketin eski API'sine göre kod üretiyor. Açıkçası böyle durumlarda doğrudan modele kızmak pek bir şey çözmüyor. Asistanın elindeki bilgiler eksik olabilir. Projemde hangi paket sürümünün kullanıldığını, ilgili metodun gerçek imzasını veya son değişikliğin neden yapıldığını bilmiyorsa tahmin yürütmesi şaşırtıcı değil.
Benim burada dikkatimi çeken konu, AI asistanlarının yalnızca kod yazan araçlar olmaktan çıkıp geliştirme ortamındaki diğer sistemlerle birlikte çalışabilmesi. Örneğin bir NuGet paketini kontrol etmesi, GitHub'daki bir issue'yu incelemesi, resmî dokümantasyona bakması veya yazdığı değişikliği tarayıcıda test etmesi mümkün. Bu noktada MCP (Model Context Protocol) devreye giriyor.
Bir blogdaki .NET geliştiricilerine yönelik MCP sunucuları hakkındaki yazıyı incelerken benim için asıl mesele de bu oldu: Hangi araçları kurabileceğimizden çok, bunların günlük geliştirme sürecinde hangi sorunları çözebileceği.
Gelin, konuyu doğrudan .NET geliştirme senaryoları üzerinden değerlendirelim.
MCP nedir, neden ilgilenmeliyim?
MCP, AI uygulamalarının harici veri kaynaklarına ve araçlara standart bir protokol üzerinden erişebilmesini sağlayan bir iletişim katmanıdır. Basit bir örnekle anlatayım. AI asistanına bir metot yazdırdığımda, yalnızca verdiğim istemi ve erişebildiği bağlamı kullanarak cevap üretebilir. Ancak asistanı ilgili dokümantasyona veya proje bilgilerini sağlayan bir araca bağlarsam, cevap hazırlarken bu kaynaklardan da yararlanabilir.
Burada üç kavramı birbirinden ayırmak gerekiyor:
- AI modeli: İsteği yorumlar, akıl yürütür ve çözüm üretir.
- MCP sunucusu: Modele belirli araçları veya kaynakları kullanma imkânı sunar.
- MCP istemcisi: Genellikle kullandığımız AI uygulamasının bu sunucularla iletişim kurmasını sağlar.
MCP tek başına daha iyi kod yazan bir model oluşturmaz. Fakat modelin ihtiyaç duyduğu bilgilere erişmesini ve desteklenen işlemleri gerçekleştirmesini kolaylaştırabilir.
Örneğin .NET 8 ile geliştirdiğimizi varsayalım. Asistandan bir ASP.NET Core özelliği için örnek istediğimizde, güncel olmayan bir API önermesi mümkün. İlgili dokümantasyona erişebilmesi ve hedef framework sürümünü bilmesi, bu riski azaltabilir.
Elbette tamamen ortadan kaldırmaz. Asistan doğru dokümantasyonu bulsa bile yanlış yorumlayabilir. Bu nedenle MCP'yi insan kontrolünün alternatifi olarak değil, geliştirme sürecini destekleyen bir araç olarak görüyorum.
Her MCP sunucusunu kurmak zorunda mıyız?
Bence burada biraz frene basmak gerekiyor.
Son dönemde AI araçlarıyla ilgili listelerde sıkça karşılaştığımız bir yaklaşım var: Ne kadar çok araç bağlarsak o kadar iyi sonuç alacağımız düşünülüyor. Ben bu fikre pek katılmıyorum. Zaten her gün kullanmadığım bir sistemi sırf MCP desteği var diye geliştirme ortamıma eklemem. Önce gerçekten bir ihtiyacım olup olmadığına bakarım.
Bir MCP sunucusunu değerlendirirken şu soruları sorarım:
- Günlük işimde hangi sorunu çözüyor?
- Sağladığı bilgi güncel ve güvenilir mi?
- Hangi erişim izinlerine ihtiyaç duyuyor?
- Kullandığım AI istemcisiyle uyumlu mu?
- Projeye eklediğim bakım ve güvenlik yüküne değiyor mu?
Örneğin yalnızca ASP.NET Core API geliştirdiğim bir projede Azure kaynaklarını yöneten bir MCP sunucusuna ihtiyacım olmayabilir. Buna karşılık NuGet bağımlılıklarını sık güncelliyorsam paket bilgilerine erişim sağlayan bir araç çok daha anlamlıdır.
Benim yaklaşımım şu: Önce sorunu belirlemek, sonra uygun aracı seçmek. Aracı kurup ardından ona iş bulmaya çalışmak yerine bu sırayı korumak daha mantıklı.
.NET geliştiricileri için öne çıkan MCP sunucuları
Aşağıdaki araçları her projede bulunması gereken zorunlu bileşenler olarak değerlendirmiyorum. Bazıları doğrudan geliştirme sürecine, bazıları testlere, bazılarıysa operasyon tarafına hitap ediyor.
Ayrıca bir MCP sunucusunun desteklediği işlemler kullanılan uygulamaya ve sürüme göre değişebilir. Bu nedenle aşağıdaki örnekleri, ilgili araçların sunduğu özelliklerin güncel dokümantasyonla doğrulanması gereken kullanım senaryoları olarak düşünmekte fayda var.
1. NuGet MCP: Paket bağımlılıklarını daha bilinçli yönetmek
.NET projelerinde paket güncellemek çoğu zaman yalnızca sürüm numarasını değiştirmekten ibaret değil. Bir paketi yükselttiğimizde hedef framework ile uyumluluğu, diğer bağımlılıkları ve olası kırıcı değişiklikleri de değerlendirmemiz gerekiyor. Özellikle uzun süredir geliştirilen projelerde küçük bir paket güncellemesi bile beklenmedik sonuçlar doğurabiliyor. NuGet ekosistemine yönelik MCP araçları, destekledikleri ölçüde paket bilgilerini ve sürüm ayrıntılarını AI asistanının kullanımına sunabilir. Örneğin şöyle bir istek verebilirim:
Projedeki NuGet bağımlılıklarını incele. Kullanılan sürümleri belirle, güncel sürümleri ve olası uyumluluk sorunlarını araştır. Güvenlik açısından kontrol edilmesi gereken paketleri ayrıca listele. Şimdilik hiçbir dosyayı değiştirme.
Burada özellikle son cümleyi önemsiyorum. Önce mevcut durumu anlamak, ardından değişiklik planını değerlendirmek istiyorum. Asistanın doğrudan paket sürümlerini değiştirmesiyle önce rapor hazırlaması arasında önemli bir fark var. Bir başka konu da güncel sürümün her zaman en iyi seçenek olmaması. Projemin hedef framework'ü, bağımlılık zinciri ve test sonuçları yükseltme kararında belirleyici olmalı.
Ben nerede kullanırdım? Paket güncelleme çalışmalarında, bağımlılık analizi sırasında ve yeni bir kütüphaneyi projeye eklemeden önce.
Not: Paket bilgilerine erişim, bilinen güvenlik açıklarının eksiksiz tarandığı anlamına gelmez. Bunun için kullanılan kaynağın kapsamını ayrıca kontrol etmek gerekir.
2. Microsoft Learn MCP: Resmî dokümantasyonu çalışma akışına katmak
Bana göre .NET geliştiricileri için en anlamlı başlangıç noktalarından biri, Microsoft'un resmî dokümantasyonuna erişim sağlayan MCP araçları. Çünkü .NET ekosistemi sürekli gelişiyor. ASP.NET Core, EF Core, kimlik doğrulama ve uygulama yapılandırması gibi konularda farklı sürümlere ait örneklerle karşılaşabiliyoruz. Bir dokümanda çalışan kodun başka bir .NET sürümünde aynı şekilde çalışacağını varsaymak doğru değil.
Örneğin .NET 8 kullanan bir projede API anahtarı tabanlı kimlik doğrulama üzerinde çalıştığımı düşünelim. Asistandan yalnızca örnek kod istemek yerine, resmî dokümantasyonu araştırmasını ve hedef sürümle uyumlu bir çözüm önermesini isterim.
.NET 8 ve ASP.NET Core için API anahtarı tabanlı kimlik doğrulama seçeneklerini araştır. Microsoft'un resmî dokümantasyonunu esas al. Önerdiğin yaklaşımın sınırlamalarını açıkla ve örneğin hedef sürümle uyumunu kontrol et.
Böyle bir istem, asistanın sürüm ayrıntılarını gözden kaçırma ihtimalini azaltabilir. Benim açımdan buradaki kazanç yalnızca daha doğru kod üretmek değil. Araştırmaya nereden başlayacağımı belirlemek ve resmî kaynaklara daha hızlı ulaşmak da zaman kazandırıyor.
Ben nerede kullanırdım? Framework API'lerini araştırırken, sürüm yükseltmelerinde ve ASP.NET Core ile EF Core yapılandırmalarında.
3. Context7: Farklı kütüphanelerin dokümantasyonunu incelemek
Her projemiz yalnızca Microsoft teknolojilerinden oluşmuyor. .NET backend'in yanında React, farklı test kütüphaneleri veya üçüncü taraf bileşenler kullanabiliyoruz. Bu durumda tek bir dokümantasyon kaynağı yeterli olmayabilir. Context7, desteklediği kütüphanelerin dokümantasyonunu AI asistanının çalışma bağlamına taşımayı amaçlıyor. Böylece asistanın genel bilgisine güvenmek yerine, kullandığımız kütüphanenin dokümantasyonunu incelemesini isteyebiliriz.
Örneğin .NET API'min frontend tarafında kullandığım bir kütüphanenin API'si değişmiş olsun. Şöyle bir istek verebilirim:
Projede kullanılan kütüphanenin sürümünü belirle. Mevcut sürümün dokümantasyonunu incele ve bu sürümle uyumlu bir örnek hazırla. Önerdiğin metotların gerçekten mevcut olup olmadığını kontrol et.
Context7 ile Microsoft Learn MCP'nin amaçları kısmen kesişse de aynı ihtiyaçlara odaklanmıyorlar. Ben Microsoft teknolojilerinin resmî dokümantasyonu için Microsoft Learn'i, farklı kütüphanelerle çalışırken ise Context7'yi değerlendirmeyi tercih ederdim. Tabii burada da aracın ilgili kütüphaneyi ve sürümü destekleyip desteklemediğini kontrol etmek gerekiyor.
Ben nerede kullanırdım? Birden fazla framework kullanan projelerde ve sık değişen üçüncü taraf kütüphanelerin API'lerini araştırırken.
4. GitHub MCP: Kodun arkasındaki gereksinimleri anlamak
Bence AI destekli geliştirme sürecinde en çok gözden kaçırılan konulardan biri, kodun neden o şekilde yazıldığını anlamak. Bir sınıfı okuyarak mevcut davranışı görebiliriz. Ancak o sınıfın neden oluşturulduğunu, hangi hatayı çözmek için değiştirildiğini veya belirli bir kararın hangi gereksinime dayandığını anlamak için issue'lara ve pull request geçmişine de bakmamız gerekebilir. GitHub MCP, sunduğu yetkilere ve araçlara bağlı olarak repository'ler, issue'lar ve pull request'lerle çalışmayı kolaylaştırabilir.
Örneğin bir API'de zaman aşımı sorunu yaşandığını düşünelim. Asistandan doğrudan yeni bir retry mekanizması yazmasını istemek yerine önce mevcut durumu araştırmasını isterim.
İlgili issue'yu ve bağlantılı pull request'leri incele. Sorunun mevcut kodla ilişkisini açıkla. Olası nedenleri, etkilenebilecek bileşenleri ve test edilmesi gereken senaryoları listele. Kod değiştirmeden önce bir çözüm planı sun.
Bu yaklaşımın önemli bir avantajı var: Asistanı çözüm üretmeye başlamadan önce gereksinimleri anlamaya yönlendiriyoruz. Özellikle büyük repository'lerde bu önemli. Çünkü yalnızca kod parçalarına bakarak öneri hazırlayan bir asistan, geçmişte alınmış mimari kararları veya bilinen sorunları gözden kaçırabilir.
Ben nerede kullanırdım? Issue analizinde, pull request incelemelerinde ve mevcut bir özelliği değiştirmeden önce etki alanını belirlerken. Repository'ye yazma veya pull request oluşturma izinlerini ise ihtiyaç olmadıkça açmazdım. İnceleme için gereken yetkiyle değişiklik yapmak için gereken yetki aynı değil.
5. Azure DevOps MCP: İş takibiyle kod geliştirmeyi birleştirmek
GitHub tarafında issue ve pull request'ler ön plandayken, Azure DevOps kullanan ekiplerde work item'lar, sprint görevleri ve pipeline sonuçları geliştirme sürecinin önemli parçaları. Azure DevOps MCP, desteklediği özelliklere bağlı olarak bu bilgilerin AI asistanı tarafından incelenmesini sağlayabilir.
Örneğin bir work item'da birkaç kabul kriteri bulunuyor. Bunların mevcut kodda karşılanıp karşılanmadığını araştırmak istiyorum.
Work item'ın açıklamasını ve kabul kriterlerini incele. İlgili repository'deki kodla karşılaştır. Eksik veya belirsiz noktaları belirle ve uygulanması gereken değişiklikler için bir plan oluştur.
Burada yalnızca kod üretmekten bahsetmiyoruz. Gereksinimlerin anlaşılması, mevcut davranışın değerlendirilmesi ve test kapsamının belirlenmesi de işin içinde. Teknik liderlik ve ekip yönetimi tarafında da bunun karşılığı olduğunu düşünüyorum. İş takibiyle geliştirme ortamı arasında bağ kurabilmek, bir görevin yalnızca kod tarafını değil, neden yapıldığını da değerlendirmeyi kolaylaştırabilir.
Ben nerede kullanırdım? Work item analizi, kabul kriterlerinin kontrolü ve pipeline sonuçlarının araştırılması sırasında. Azure DevOps MCP'nin desteklediği özellikler uygulamaya göre değişebileceğinden, kurulum öncesinde gereken işlevleri doğrulamak gerekir.
6. Playwright MCP: Yazılan kodun davranışını tarayıcıda kontrol etmek
AI asistanına bir test senaryosu yazdırmakla uygulamayı gerçekten çalıştırıp test etmek arasında fark var. Playwright MCP, desteklediği tarayıcı etkileşimlerini AI asistanının gerçekleştirmesine imkân tanıyabilir. Böylece web uygulamasını açmak, form alanlarıyla etkileşime girmek ve beklenen davranışları kontrol etmek gibi işlemler iş akışına dahil edilebilir.
Örneğin bir .NET MVC uygulamasında giriş ekranını geliştirdiğimi düşünelim. Formun doğru çalışması kadar hatalı girişte uygun mesajın gösterilmesi ve başarılı giriş sonrasında doğru sayfaya yönlendirme yapılması da önemli. Asistandan şunu isteyebilirim:
Giriş ekranını tarayıcıda aç. Boş alanlar, başarısız giriş ve başarılı giriş senaryolarını test et. Beklenen davranışlarla gözlemlediğin sonuçları karşılaştır ve başarısız senaryoları raporla.
Bu tür bir kullanım, özellikle arayüz değişikliklerinden sonra faydalı olabilir. Ancak burada bir ayrıntıyı atlamamak gerekiyor: Tarayıcıda birkaç senaryonun başarılı olması, uygulamanın bütün testlerden geçtiği anlamına gelmez. Test verileri, beklenen sonuçlar ve farklı kullanıcı senaryoları önceden belirlenmeli. Ben gerçek kullanıcı hesaplarıyla veya production ortamında denemeler yapmak yerine kontrollü bir test ortamını tercih ederdim.
Ben nerede kullanırdım? Uçtan uca testlerde, form davranışlarını doğrularken ve arayüz değişikliklerinin beklenmeyen sonuçlarını araştırırken.
7. Postman MCP: API testlerini geliştirme sürecine dahil etmek
Backend geliştiren biri olarak API testlerinin yalnızca başarılı yanıtı kontrol etmekten ibaret olmadığını düşünüyorum. Geçersiz istekler, yetkisiz erişim, bulunamayan kayıtlar, beklenmeyen yanıt alanları ve HTTP durum kodları da test edilmesi gereken noktalar. Postman MCP, desteklediği entegrasyonlar üzerinden API koleksiyonları ve isteklerle çalışmayı AI asistanının iş akışına taşıyabilir.
Örneğin yeni bir ödeme endpoint'i geliştirdiğimi varsayalım. Asistandan doğrudan testleri çalıştırmasını istemeden önce beklenen davranışları belirlemesini isterim.
Endpoint'in API sözleşmesini incele. Başarılı ve başarısız istek senaryolarını listele. HTTP durum kodlarını ve yanıt alanlarını kontrol et. Testleri çalıştırmadan önce kullanılacak ortamı ve gerekli değişkenleri doğrula.
Böylece yalnızca test sayısını artırmak yerine, gerçekten hangi davranışların doğrulanması gerektiğine odaklanabiliriz. Postman MCP'nin tüm uygulamalarda aynı işlevleri sunduğunu varsaymamak gerekir. Koleksiyonları okuma, istekleri çalıştırma veya test sonuçlarını değerlendirme gibi yetenekleri kullanılan sunucunun dokümantasyonundan kontrol etmek gerekir.
Ben nerede kullanırdım? API test senaryolarını hazırlarken, mevcut koleksiyonları incelerken ve tekrarlanan kontrolleri kolaylaştırmak istediğimde.
8. Azure MCP: Bulut ortamındaki sorunları araştırmak
.NET uygulamamız Azure üzerinde çalışıyorsa geliştirme sürecinin bir noktada operasyon tarafıyla kesişmesi kaçınılmaz. Bir deployment tamamlanmış olabilir ama uygulama beklenen davranışı göstermiyordur. Böyle bir durumda kaynakların durumunu, yapılandırmaları ve erişilebilen operasyonel bilgileri birlikte değerlendirmek gerekir. Azure MCP, desteklediği araçlar ve verilen izinler ölçüsünde Azure kaynaklarıyla ilgili bilgilerin incelenmesini sağlayabilir.
Örneğin şöyle bir istek verebilirim:
İlgili uygulamanın Azure kaynaklarını ve erişebildiğin durum bilgilerini incele. Olası sorunları kanıtlarıyla birlikte listele. Herhangi bir yapılandırmayı değiştirmeden önce bulgularını ve önerdiğin adımları raporla.
Burada asistanın yalnızca bir sonuç üretmesini değil, o sonuca hangi bulgulardan hareketle ulaştığını da açıklamasını isterim. Bulut ortamlarında yanlış bir işlem, geliştirme makinesindeki hatalı koddan çok daha geniş bir etkiye sahip olabilir. Bu nedenle ilk aşamada salt okunur erişim kullanmak ve kritik değişiklikleri onaya bağlamak bana göre daha doğru.
Ben nerede kullanırdım? Azure kaynaklarını incelerken, deployment sorunlarını araştırırken ve operasyonel bilgileri bir araya getirmek istediğimde.
9. Cloudflare MCP: DNS ve edge altyapısına erişmek
Cloudflare kullanan projelerde DNS kayıtları, güvenlik kuralları ve Workers gibi servisler uygulamanın çalışması açısından önemli olabilir. Cloudflare MCP, desteklediği işlevlere göre bu kaynakları incelemeyi veya izin verilen işlemleri gerçekleştirmeyi sağlayabilir.
Örneğin bir alan adına erişim sorunu yaşandığında şu şekilde ilerlemek isterim:
İlgili alan adının DNS kayıtlarını incele. Mevcut yapılandırmayı listele ve olası tutarsızlıkları raporla. Herhangi bir kayıt üzerinde değişiklik yapma.
Bu tür bir yaklaşım, sorunun kaynağını araştırırken yardımcı olabilir. Ancak DNS veya güvenlik yapılandırmalarındaki yanlış bir değişiklik uygulamanın erişilebilirliğini etkileyebilir. Bu yüzden Cloudflare MCP'yi her .NET projesine önerilecek bir araç olarak görmüyorum. Cloudflare kullanan ve bu kaynakları düzenli olarak inceleyen ekipler için anlamlı bir seçenek.
Ben nerede kullanırdım? DNS yapılandırmalarını araştırırken ve Cloudflare altyapısındaki sorunları incelerken.
Ek bir seçenek: .NET metadata MCP sunucuları
Yukarıdaki araçların çoğu dokümantasyon, repository veya operasyonel verilerle ilgileniyor. Ancak .NET geliştiricilerinin karşılaştığı daha özel bir problem var: AI'nin kullandığımız kütüphanede bulunmayan bir metodu önermesi. Bunu yalnızca dokümantasyon eksikliği olarak değerlendirmemek gerekiyor. Bazen asistan genel olarak doğru bir API'yi biliyor ama projemizdeki paket sürümünde bulunmayan bir overload kullanıyor. .NET metadata odaklı MCP sunucuları, destekledikleri ölçüde gerçek assembly ve tip bilgilerine, metot imzalarına veya bağımlılık ayrıntılarına erişim sağlayabilir. Örneğin şöyle bir istek verebilirim:
Bu projede kullanılan kütüphanenin gerçek metot imzalarını incele. Önerdiğin çağrının mevcut sürümde desteklenip desteklenmediğini kontrol et. Uyumlu değilse mevcut API'lerle uygulanabilecek alternatifleri göster.
Bence bu kategori özellikle büyük .NET projelerinde dikkate değer. Çünkü bazen sorun, çözümün mantığında değil, kullanılan API'nin gerçekte nasıl tanımlandığında yatıyor. Ancak burada da sunucunun hangi assembly'leri inceleyebildiğini ve ne tür metadata sunduğunu kontrol etmek gerekir. Her metadata sunucusunun tüm bağımlılıkları otomatik olarak çözebildiğini varsaymamak lazım.
Ben olsam hangi MCP sunucularıyla başlardım?
Buraya kadar farklı ihtiyaçlara yönelik araçları inceledik. Peki hepsini kurar mıydım? Hayır. Ben önce günlük geliştirme akışımda en çok karşılaştığım sorunlara bakardım. Bir .NET geliştiricisi için başlangıçta şu üç alanın oldukça anlamlı olduğunu düşünüyorum:
| Öncelik | Araç | Neden? |
|---|---|---|
| 1 | Microsoft Learn MCP | Framework ve API bilgilerini resmî dokümantasyonla kontrol etmek için |
| 2 | GitHub MCP | Issue'ları, pull request'leri ve repository bağlamını incelemek için |
| 3 | NuGet MCP | Paket sürümlerini ve bağımlılıkları değerlendirmek için |
Web uygulamaları üzerinde yoğun çalışıyorsam Playwright MCP'yi de bu listeye eklerdim. API testleri işimin önemli bir parçasıysa Postman entegrasyonunu değerlendirirdim. Azure DevOps, Azure veya Cloudflare tarafındaki araçlarıysa kullandığım altyapıya göre seçerdim.
Bu sıralama bir performans testi sonucu değil; günlük geliştirme ihtiyaçlarına göre yaptığım bir değerlendirme. Farklı projelerde öncelikler değişebilir. Bana göre doğru başlangıç, üç veya dört aracı aynı anda kurup ne işe yaradıklarını anlamaya çalışmak değil. Önce tek bir iş akışını seçip gerçekten fayda sağlayıp sağlamadıklarını görmek.
MCP kurarken güvenlik tarafını nasıl ele almalıyız?
AI asistanına bir araç bağladığımızda yalnızca yeni bir özellik eklemiyoruz. Aynı zamanda belirli verilere erişim veya bazı işlemleri gerçekleştirme yetkisi de vermiş olabiliriz. Bu nedenle MCP sunucularını değerlendirirken güvenliği sonradan düşünülecek bir konu olarak görmüyorum.
Gereken en düşük yetkiyle başlayın
Bir repository'yi incelemek için yazma yetkisi gerekmeyebilir. Azure kaynaklarının durumunu öğrenmek için onları silme veya değiştirme izni vermek zorunda değilsiniz. Ben mümkün olduğunda salt okunur erişimle başlar, gerçekten ihtiyaç duyulan yetkileri daha sonra değerlendirirdim.
Hassas verileri koruyun
Bağlantı dizeleri, API anahtarları, erişim token'ları ve üretim logları dikkatle ele alınmalı. MCP sunucusuna bağlanmadan önce hangi verilerin paylaşılacağını, sunucunun kim tarafından işletildiğini ve verilerin nasıl işlendiğini incelemek gerekiyor.
Her sunucuya güvenmeyin
İnternette yayımlanmış olması bir MCP sunucusunun güvenilir olduğunu göstermez. Kaynağını, bakım durumunu, istediği izinleri ve güncel dokümantasyonunu kontrol etmek gerekir. Ayrıca bir MCP sunucusundan veya harici bir kaynaktan gelen her metni güvenilir talimat olarak değerlendirmemek önemli. Örneğin bir issue açıklamasında veya log kaydında, asistanı beklenmedik bir işlem yapmaya yönlendiren içerikler bulunabilir.
Kritik işlemleri onaya bağlayın
Production ortamında kaynak silmek, DNS kaydı değiştirmek, deployment başlatmak veya repository'ye kod göndermek gibi işlemlerin otomatik yapılması her zaman doğru olmayabilir. Ben bu tür işlemlerde önce planın hazırlanmasını, ardından değişikliğin incelenmesini ve gerekli onayın alınmasını tercih ederdim.
Kurulum talimatlarını güncel kaynaktan alın
MCP sunucularının yapılandırma biçimleri ve kurulum yöntemleri değişebilir. Bu nedenle eski bir blog yazısındaki yapılandırmayı doğrudan kopyalamak yerine, ilgili sunucunun güncel dokümantasyonunu takip etmek daha sağlıklı. Özellikle şirket projelerinde veya üretim sistemlerine erişen ortamlarda bu kontrolü atlamamak gerekiyor.
Sonuç: Daha fazla araç değil, daha doğru bağlam
MCP sunucularını değerlendirirken benim için en önemli nokta, AI asistanının hangi araçlara bağlandığından çok bu bağlantıların hangi sorunu çözdüğü.
Güncel dokümantasyona erişmek, NuGet bağımlılıklarını incelemek, GitHub issue'larını anlamak ve uygulama davranışlarını test etmek günlük geliştirme sürecinde karşılığı olan işler. MCP, bu adımları AI destekli bir iş akışında bir araya getirmemize yardımcı olabilir. Ancak yalnızca MCP kurduğumuz için daha kaliteli kod üreteceğimizi veya hataların ortadan kalkacağını düşünmüyorum. Asistanın doğru bağlamı alması, kullandığı araçların güvenilir olması ve ürettiği sonuçların doğrulanması gerekiyor.
Ben olsam önce geliştirme sürecimde en çok zaman kaybettiren iki işi belirlerdim. Bunlara uygun araçları kontrollü izinlerle dener, gerçekten zaman kazandırıp kazandırmadıklarını gözlemlerdim. Sonuçtan memnun kalırsam kapsamı genişletirdim.
Çünkü mesele AI asistanına mümkün olduğunca çok araç bağlamak değil. Mesele, doğru bilgiye erişebilen, yaptığı işi doğrulayabilen ve kontrolün bizde kaldığı bir geliştirme süreci oluşturmak.
Keyifli kodlamalar 🖖