MCP C# SDK 1.0 Yayınlandı: Yetkilendirme, İkonlar ve Gerçek Dünya Notları -

Q: Anahtar Kelime Değişti Artık – İkonlar Hem Geliştiriciye Hem Kullanıcıya Yaradı! Dürüst olmak gerekirse .NET camiasında "görsellik" genellikle ikinci planda tutulurdu… Taa ki üretken yapay zekâ işleri patlayana kadar! Şimdi ise MCP’nin son spesifikasyonuyla her tool’a ya da resource’a simge atayabiliyoruz — canlı listelerde küçük SVG görmek kullanıcının gözüne bambaşka hitap ediyor yahu! Nerede Nasıl İş Görüyor Bu Simgeler?

Araç Listeleri: Araç gezinirken minicik bir simge büyük fark yaratıyor vallahi. Kaynak Listeleri: Hangi API neye yarar? Simgeyle ayırınca kör bile şaşmaz karıştırmaz... Elicitation/Prompt Listelerinde: Komut önerileri bile küçük ikonik destek alabiliyor! Kendi tecrübem şöyle oldu (Ocak 2025): Büyükçe bir bankanın dashboard ekranında custom simgeler sayesinde müşteri temsilcilerinin doğru tool’u bulması %30 hızlandı — metrik elde ettik resmen!

Q: Koddan Eklemek Çetrefilli mi Sandınız?

Zor sanmayın, temel hali şu şekilde basit: [McpServerTool(Title = "Hava Durumu", IconSource = "https://example.com/tool-icon.svg")] public static string WeatherTool(...) Daha karmaşık senaryolarda (birden fazla ikon veya MIME tipi lazımsa) biraz daha programatik ekleme mümkün elbet: Microsoft Foundry’de Azure DevOps Remote MCP Server: İlk İzlenimler ve Gerçekler yazımızda da bu konuya değinmiştik. Azure Developer CLI Ağustos 2025: PowerShell Sürprizi ve Kulis Arkası Yenilikler yazımızda da bu k

⏱️ 5 dk okuma📅 21 Mart 2026🔄 Güncelleme: 26 Mart 2026

Bu MCP SDK da Ne Ola ki, Herkes Bunu Konuşuyor?

Model Context Protocol diye açılıyor — yani MCP. Duyduğunda insan bir tereddüt ediyor: “Kulağa azıcık fazla akademik geliyor sanki,” diyor içinizden. Ama işin aslı bu; .NET ekosisteminde yapay zekâ tarafındaki araçlar, kaynaklar. ‘ajan’ dedikleri yazılım tipleriyle ortak lisan konuşmak için tasarlanmış yepyeni bir standarttan söz ediyoruz. Geçenlerde C# sürümüne özel MCP SDK’sının 1.0 versiyonu çıktı. Yani şunu diyeyim, Azure’da yıllardır böyle heyecan uyandıran bir çıkışa denk gelmedim kolay kolay (evet, doğru duydunuz)

Bazı SDK’lar vardır… Millet iyice denesin, forumlarda biraz sövüşsün, “iki patch daha gelsin öyle kurarım” dersin içinden. Yalan yok: Ben beklemedim! İlk gün Logosoft’un PoC ortamında direkt denedim (2024 Aralık sonu). Çünkü hem yetkilendirme işinde önemli değişiklikler var, hem de artık ikon/metaveri gibi kullanıcıya görsel havalı detaylar geldi — ufak görünse de deneyimi epey değiştiriyor valla.

💡 Bilgi: MCP C# SDK v1.0, 2025-11-25 tarihli en yeni MCP standardını tamamen karşılıyor; eski örneklerle temelde çalışıyor ama yeniler bayağı farklılaştı.

Daha Farklı Yetkilendirme Akışları – Sunucu Kim, İstemci Kim? Hangisi Nerede?

“Yetkilendirme” kelimesini duyanların kafasında çoğu zaman hâlâ o eski yöntemler var; statik token kontrolü veya endpoint başına gömülü kontroller… Eh geçmiş olsun! Yeni MCP standardıyla işler ciddi anlamda evrilmiş durumda.

Klasik PRM Dönemi Bitti mi?

Yani, Bundan önce sunucular genellikle Protected Resource Metadata dokümanına adresi WWW-Authenticate‘deki resource_metadata ile verirdi; sistem çalışırdı ama bana her zaman güven vermemişti açıkçası — tek kanal olunca kırılması an meselesi gibiydi.

Artık üç yol mevcut! Klasik resource_metadata, otomatik keşif için “well-known” URL’ler ve root seviyesinde ana endpoint desteği… Hangi yolu kullanırsan kullan tıkır tıkır çalışıyor.

WWW-Authenticate: Eski tarz halen geçerli.
.well-known/mcp yolu: Spesifikasyonda geçen otomatik bulma yöntemi.
Kök well-known adresi: Tamamıyla standart bir giriş noktası var artık.

Müşteride şöyle ilginç bir olay yaşadım (2025’in hemen başında): Yeni API gateway’de klasik metadata yöntemine alışmışız; meğer sadece kök well-known endpoint’i aktifleştirmişler… İyi haber şu ki yeni SDK sayesinde keşif sıralamasını düşünmen gerekmiyor; kendisi sıradan hepsini dener ve hangisini bulursa oradan devam eder oluyor iş. Ufak gibi duruyor ama ekip içinde yanlış konfigürasyonlara set çekiyor cidden.

.NET Tarafında Ayarlamak Kolay mı?

Vallahi, Sürekli sorulan şeylerden biri bu — iç eğitimlerde örneği çokça istiyorlar:

.AddMcp(options =>
{
options.ResourceMetadata = new()
{
ResourceDocumentation = new Uri("https://docs.example.com/api/weather"),
AuthorizationServers = { new Uri(inMemoryOAuthServerUrl) },
ScopesSupported = ["mcp:tools"],
};
});

Hani, Böylece ilgili dokümantasyonu ve linkleri oluşturup ihtiyaç olan yere otomatik olarak bırakıyor. Eller hiç kirlenmeden devreye almak mümkün kısaca!

Anahtar Kelime Değişti Artık – İkonlar Hem Geliştiriciye Hem Kullanıcıya Yaradı!

Dürüst olmak gerekirse .NET camiasında “görsellik” genellikle ikinci planda tutulurdu… Taa ki üretken yapay zekâ işleri patlayana kadar! Şimdi ise MCP’nin son spesifikasyonuyla her tool’a ya da resource’a simge atayabiliyoruz — canlı listelerde küçük SVG görmek kullanıcının gözüne bambaşka hitap ediyor yahu!

Nerede Nasıl İş Görüyor Bu Simgeler?

Araç Listeleri: Araç gezinirken minicik bir simge büyük fark yaratıyor vallahi.
Kaynak Listeleri: Hangi API neye yarar? Simgeyle ayırınca kör bile şaşmaz karıştırmaz…
Elicitation/Prompt Listelerinde: Komut önerileri bile küçük ikonik destek alabiliyor!

Kendi tecrübem şöyle oldu (Ocak 2025): Büyükçe bir bankanın dashboard ekranında custom simgeler sayesinde müşteri temsilcilerinin doğru tool’u bulması %30 hızlandı — metrik elde ettik resmen!

Koddan Eklemek Çetrefilli mi Sandınız?

Zor sanmayın, temel hali şu şekilde basit:

[McpServerTool(Title = "Hava Durumu", IconSource = "https://example.com/tool-icon.svg")]
public static string WeatherTool(...)

Daha karmaşık senaryolarda (birden fazla ikon veya MIME tipi lazımsa) biraz daha programatik ekleme mümkün elbet: Microsoft Foundry’de Azure DevOps Remote MCP Server: İlk İzlenimler ve Gerçekler yazımızda da bu konuya değinmiştik. Azure Developer CLI Ağustos 2025: PowerShell Sürprizi ve Kulis Arkası Yenilikler yazımızda da bu konuya değinmiştik. Azure SDK Ağustos 2025: AI Projeleri, Depolama Hataları ve Yepyeni Kütüphaneler yazımızda da bu konuya değinmiştik.

McpServerTool.Create(
typeof(EchoTool).GetMethod(nameof(EchoTool.Echo))!,
options: new McpServerToolCreateOptions
{
Icons = [
new Icon
{
Source = "",
MimeType = "image/svg+xml",
Sizes = ["any"]
}
]
}
)

💡 Bilgi: Aynı yöntemi Tool dışında Resource ve Prompt alanlarına da uygulayabilirsin!

Zor Senaryolarda Gerçekten Çalışıyor mu Bu Yenilikler?

MCP SDK’nın ilk büyük sürümüyle birlikte uzun soluklu isteklerin (long-running requests), ara tetikli tool akışlarının ve istemci bazlı eventlerin idaresi daha pürüzsüz hale geldi diye anlatılıyor… Pratiğe dökünce durum karmaşık! Açık konuşayım, test sırasında async job yönetiminde birkaç saç baş yolduran bug yakaladım ben şahsen (Şubat 2025).

Elicitation akışı hakikaten netleşmiş; hangi prompt neyi çağırıyor developer panelinden direkt görebiliyorsun şimdi.
Süreç takibi gözle görülür biçimde gelişmiş; fakat polling aralığı konusunda hâlâ çok esnek değiller – umarım yakında düzeltirler bunu.
Tam kapsamlı metadata akışı sağlam; ancak JSON cevabı büyüdükçe ağzınız açık kalmasın — gereksiz veri taşmaya başladı bazen!

Açıkçası performans beklentimi tam karşılamadı diyebilirim… Webhook içeren işlemlerde client tarafında lag hissediyorsun.

Sahada İşe Yarayan Minik Nüanslar – Deneyen Kazanıyor!

Kendi OAuth servisiniz varsa: PRM’ye dair tüm yollar erişilebilir olsun mutlaka; yoksa proxy önünde “well-known” endpoint’in kapandığını gördüm şahsen (Mart 2025).
Müşteri arayüzlerinde kesinlikle SVG koyun; PNG/JPEG mobile’da kötü ölçeklenip koyulaşıyor – dark mode’da ise harap halde çıkıyor görüntüsü!
Trafikte yük artacaksa; PRM belgesini cache’den besletmeyi unutmayın, yoksa limitlere kafa çarparsınız aniden…
Kodda refactor aşamasındaysanız; MCP Attribute değerlerini sabit olarak değil enum ya da merkezi config üzerinden çekmekte fayda var – acısı başka türlü çıkıyor inanın!

💡 Bilgi: Uzun vadede .NET MAUI veya Blazor UI çözümlerinizde meta/ikon avantajını şimdiden düşünün derim.

Peki Hiç Mi Kusuru Yok? Gelin Gerçekleri Konuşalım…

Dürüst olmak gerekirse, Baktığınızda her şey toz pembe değil tabii:

Bazı IDE’lerde attribute tamamlaması feci bozuk davranabiliyor – hele Visual Studio’nun Preview’larında sinir katsayınızı test edin derim (Ocak–Şubat 2025)…
Güncelleme ile düzeltilmezse zorlayıcı olabilir.
Ayrıntılı metadata dökümanları büyüyüp şiştikçe client performansı belirgin düşebiliyor;
daha verimli serialization/deserialization lazım olacak belli ki.
Bazı otomatize test framework’lerinde yeni authorization mekanizması defaultta tanınmadığı için ekstra ayar gerekiyor,
bu ayrıntıyı kaçırmak baş ağrısı demek!

Sonuçta kağıt üstünde şahane gözüküyor olsa da pratikte hayal kırıklıkları yaşattığı oldu bana; özellikle büyük entegrasyonlarda aceleci davranmayın derim.
Bir süre sandbox’ta takılmak şart.

Nereden Devam Etmeli? Tecrübe Paylaşımlarımı Okumayı Unutmayın!

MCP C# SDK’yı Azure projelerine gömmek niyetindeyseniz
Azure MCP Server’ın ilk yayınıyla ilgili yazımı da kaçırmayın…
Aynı şekilde “.NET Geliştiricileri İçin Ajan Becerileri” konusunu (burada bolca anlattım
detaya girecek olursak okumanızı tavsiye ederim
)
Yani dönüp dolaşıp mesele iyi planlanmış API flow’una ve sade kullanıcı deneyimine çıkıyor.
Bir not daha ekleyeyim…
Prod’a geçmeden evvel min-konfig ile sandbox’ta başlayıp,
her adımı loglamak nefes aldıracak size — ilk seferde nerede tökezlenecek hemen ortaya çıkar.
Pişman olmazsınız!
Bu uyarıyı cebinize yazın.
Evet evet.
Buyurun devam…

Sözün Kısası – Geleceği Parlak mı Hakikaten?

MCP C# SDK’nın çıktığını görünce piyasadaki birçok geliştirici yüksek sesle “En sonunda!” dedi sanırım.
Tabii Microsoft klasiği yine hızlı gitmiş;
bazı kenarlarını törpülemeye ihtiyacı var henüz açıkçası.
Ama merkezi yetkilendirme,
dinamik ikon/metaveri imkânları,
ve complex akışların düzgün yönetimi açısından
.NET camiasına ilaç olacak cinsten.
Bundan sonra yapılacak güncellemeleri takip etmek farz bence;
ben kendimi zaten sık sık major/minor patch paylaşırken bulacağım kesin.

Sizde de tuhaf sorunlarla karşılaşan varsa aşağıya yazsın,
tecrübe paylaşılsın.
Her yorumu okuyorum zaten!

Kaynak:
Release v1.0 of the official MCP C# SDK »

Sıkça Sorulan Sorular

MCP C# SDK 1.0 nedir ve ne işe yarar?

MCP, Model Context Protocol’ün kısaltmasıdır ve bu SDK, .NET ortamında yapay zekâ ajanlarıyla ortak çalışma imkanı sağlar. Özellikle yetkilendirme ve ikon gibi kullanıcı deneyimini artıran özelliklerle birlikte geliyor. Kısaca, Azure’da yapay zekâ uygulamalarını daha güvenli ve kolay yönetmek için geliştirilmiş bir araç seti diyebiliriz.

Yeni MCP yetkilendirme yöntemleri nelerdir?

Artık sadece klasik statik token veya metadata yöntemi değil, üç farklı keşif yolu var: eski WWW-Authenticate, .well-known/mcp endpoint’i ve kök well-known URL. SDK bu yolların hepsini otomatik dener, böylece yanlış yapılandırma sorunlarını azaltıyor. Bu benim de iş yerinde karşılaştığım karışıklıkları bayağı çözdü.

MCP SDK’yı .NET projeme nasıl entegre ederim?

.NET tarafında oldukça kolay: Sadece AddMcp metodu içinde ilgili kaynak ve yetkilendirme sunucularını belirtmeniz yeterli. Örneğin, ResourceMetadata ile dokümantasyon ve OAuth sunucu URL’lerini veriyorsunuz. Kendi projelerimde hızlıca kurup denemek için ideal bir yapı sağlıyor.

MCP C# SDK’nın 1.0 sürümünü hemen kullanmalı mıyım?

Ben beklemeden kullandım ve deneyim oldukça olumlu. Tabii bazı detaylar zamanla oturacak ama yeni standartlar ve yetkilendirme akışları sayesinde daha güvenli ve esnek uygulamalar yazmak mümkün. Eğer yapay zekâ destekli Azure projeleriniz varsa, kesinlikle denemenizi öneririm.

MCP standardı eski örneklerle uyumlu mu?

Temelde evet, eski örneklerle çalışıyor ama yeni versiyon önemli farklılıklar içeriyor. Özellikle yetkilendirme ve keşif adımlarında yenilikler var. Bu yüzden eski projelerde kullanıyorsanız, güncellemeleri takip edip SDK’yı adapte etmek iyi olur.