SQL MCP Server: Veritabanını Ajanlara Açmanın Yolu
Şunu açıkça söyleyeyim — son birkaç aydır AI agent’ları kurumsal veritabanlarına bağlama işi kafamı epey kurcalıyor. Hani her yerde “agentic AI” konuşuluyor, copilot’lar her şeyi yapacak deniyor ama… bir durun. Bu agent’lar veriye nasıl erişecek? Direkt SQL bağlantısı mı vereceksiniz? Connection string’i bir LLM’e mi bırakacaksınız? Yok artık.
Tuhaf ama, Tam da burada Microsoft’un yeni duyurduğu SQL MCP Server devreye giriyor. Data API Builder (DAB) 2.0’ın parçası olarak gelen bu özellik, bana kalırsa kurumsal veri erişiminde işleri baya değiştirir gibi dürüyor. Ama her şeyi pembe göstermeyeyim — eksikleri de var, onlara da geleceğim.
MCP Nedir ve Neden Bu Kadar Önemli?
Vallahi, Model Context Protocol, yanı MCP, aslında çok basit bir fikre dayanıyor: AI agent’larının dış dünyayla nasıl konuşacağını ortak bir dille tarif ediyor. Agent bir tool görüyor, ne beklediğini anlıyor, çağırıyor, sonucu alıyor. Hepsi bu. Ama işin garibi, bu kadar sade bir şey baya işe yarıyor.
Peki, peki neden? Çünkü herkes kendi bağlantısını baştan yazıyordu. Geçen ay bir finans kuruluşundaki projede bunu birebir gördüm — ekip, GPT tabanlı bir copilot’u Oracle veritabanına bağlamak için 3 haftadır özel middleware yazıyordu; prompt injection’a karşı koruma koyuyorlar, şema sızıntısını engellemeye uğraşıyorlar, hatalı sorguları yakalamaya çalışıyorlar… Hepsi elle, hepsi custom kod. Açık konuşayım, insanın içi şişiyor. SQL MCP Server tam da bu karmaşayı biraz toparlamaya geliyor.
SQL MCP Server, MCP protokolünün 2025-06-18 versiyonunu implement ediyor. İki transport destekliyor: standart hosting senaryoları için Streamable HTTP, lokal. CLI senaryoları için de stdio. Başlatıldığında agent’a “ben şunları yapabiliyorum” diye yeteneklerini ilan ediyor — buna tool discovery deniyor. Güzel tarafı şu: her şeyi tek tek anlatmak zorunda kalmıyorsunuz. Kötü tarafı da var tabiî; yanlış yapılandırırsanız iş çabuk dağılıyor.
Data API Builder 2.0 ile Gelen Fark
Bence, SQL MCP Server tek başına bir ürün değil. Bir bakıma, data API Builder (DAB) 2.0’ın üstüne oturuyor, işin aslı bu. İlginç, değil mi? Bu detay önemli; çünkü DAB zaten yıllardır production’da pişmiş bir abstraction katmanı, REST ve GraphQL endpoint’leri veriyordu, şimdi üstüne bir de MCP eklenmiş durumda (ciddiyim)
Şimdi gelelim işin can alıcı noktasına.
Desteklenen Veritabanları
| Veritabanı | Destek Durumu | Notum |
|---|---|---|
| Microsoft SQL Server | ✅ Tam destek | En olgun entegrasyon |
| Azure SQL Database | ✅ Tam destek | Managed Instance dahil |
| PostgreSQL | ✅ Tam destek | Açık kaynak tarafı için güzel |
| Azure Cosmos DB | ✅ Tam destek | NoSQL senaryoları |
| MySQL | ✅ Tam destek | Legacy sistemler için faydalı |
Baya iş görüyor, ama dur bir saniye — hybrid query tarafı burada asıl numara. Tek bir agent, aynı anda hem SQL Server’dan hem Cosmos DB’den veri çekebiliyor; bunu elle yazmaya kalksanız, açık konuşayım, insanın hevesi yarıda kalır. 2022’de bir e-ticaret projesinde benzer bir şeyi manuel kurmuştuk; relational + NoSQL hibrit sorgu katmanıydı ve tam 2 ay sürdü. Şimdi işe çoğu şey bir JSON config dosyasıyla toparlanıyor. Zaman zaman insan “biz niye bunu daha önce böyle yapmadık” diye düşünüyor.
Güvenlik Katmanları
Bak şimdi, güvenlik tarafında DAB’ın sunduğu yapı fena değil:
- RBAC (Role-Based Access Control) — API katmanında çalışıyor, veritabanının içine kadar inmiyor.
- Azure Key Vault entegrasyonu — connection string’ler ve API key’ler burada tutulabiliyor.
- Microsoft Entra (eski adıyla Azure AD) desteği — kurumsal kimlik doğrulama için iyi oturuyor.
- Custom OAuth — Entra dışındaki senaryolarda da iş görebiliyor. (bence en önemlisi)
- Entity abstraction — agent veritabanı şemasını görmüyor.
Neyse, şu son maddeyi biraz açayım. Entity abstraction dediğimiz şey, agent’ın “customers” tablosunu, kolonlarını ya da foreign key ilişkilerini görmemesi demek; yanı eline doğrudan şema vermiyorsunuz, sadece tanımladığınız tool’lar kalıyor: “müşteri oluştur”, “sipariş sorgula” gibi. Bu yaklaşım prompt injection saldırıları açısından baya rahatlatıyor (evet, doğru duydunuz). Geçen sene bir bankacılık projesinde LLM’in ürettiği SQL sorgularını sanitize etmek için epey uğraşmıştık; entity abstraction o yükün büyük kısmını ortadan kaldırıyor gibi dürüyor.
Evet.
Kurulumu Gerçekten Kolay mı?
Microsoft buna “zero-code solution” diyor. Hmm, bir durup bakınca… evet, büyük ölçüde öyle. Neyse, sQL MCP Server bir container image olarak geliyor (MCR, yanı Microsoft Container Registry üzerinden), sizden de aslında tek istediği şey bir JSON yapılandırma dosyası. Temel yapı da aşağı yukarı şöyle dürüyor:
{
"$schema": "https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json",
"data-source": {
"database-type": "mssql",
"connection-string": "@env('SQL_CONNECTION_STRING')"
},
"entities": {
"Customer": {
"source": "dbo.Customers",
"permissions": [
{
"role": "agent",
"actions": ["read", "create"]
}
]
}
},
"runtime": {
"mcp": {
"enabled": true
}
}
}Connection string’i environment variable’dan çekiyor, bu kısmı hoş. Entity tarafında da hangi role’ün ne yapacağını tek tek yazıyorsunuz, yanı işin kontrolü elinizde kalıyor. Bu kadar gibi görünüyor. Ama tabi gerçek hayatta tablo biraz değişiyor; geçen hafta kendi lab ortamımda bunu kurarken ilk ayak işi 15 dakika sürdü, sonra RBAC kurallarıyla uğraştım, Entra token’ını configure ettim derken toplamda 2 saat gitti. Sız ne dersiniz? Yine de eski usulle kıyaslayınca baya iş görüyor.
Evet.
Ha bu arada, VS Code extension’ı da var. CLI tool’u da var. Cross-platform çalışıyor, o taraf rahat. Hatta REST. GraphQL endpoint’lerini test etmek için built-in araçlar bile koymuşlar; bak şimdi, böyle küçük detaylar bazen insanı şaşırtıyor. Developer experience açısından Microsoft bu sefer fena değil iş çıkarmış diyebilirim — açık konuşayım. Bu konuyla ilgili Foundry Local GA Öldü: Bulut Olmadan Yerel AI yazımıza da göz atmanızı tavsiye ederim.
Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?
Şimdi asıl meseleye gelelim. Türkiye’deki şirketler bunu nasıl kullanır, peki neden bu kadar konuşuyoruz?
Bir şey dikkatimi çekti: Logosoft’ta danışmanlık verdiğim kurumsal müşterilerin büyük çoğunluğu hâlâ on-premises SQL Server kullanıyor. Bankalar, telekomlar, büyük holdingler… Hepsinde iri MSSQL instance’ları var; bir de üstüne güvenlik, uyumluluk ve veri çıkışı kaygısı eklenince iş biraz daha karışıyor, yanı masada teknik taraftan çok operasyonel stres de oluyor. Ve hepsinde aynı soru dönüp dolaşıyor: “AI agent’larımız bu verilere nasıl güvenli erişecek?” SQL MCP Server’ın güzel yanı şu: sadece Azure’da değil, on-premises’te de çalışıyor. Container olduğu için Kubernetes cluster’ınıza deploy edebiliyorsunuz. Bu da KVKK ve veri lokalizasyonu derdi olan Türk firmaları için baya iş görüyor.
Dürüst olmak gerekirse, Ama dur bir saniye — burada küçük ama önemli bir boşluk var. Türkiye’deki çoğu kurum henüz MCP protokolünü bilen bir AI agent kullanmıyor; GPT-4o, Claude, Gemini gibi modellerin MCP desteği de tam oturmuş değil, açık konuşayım. Foundry" data-glossary-term="Microsoft Foundry">Microsoft Foundry ile native entegrasyon var, evet, fakat kaç Türk şirketi Foundry’yi production’da kullanıyor? Az. Hatta beklediğimden az. Dolayısıyla SQL MCP Server’ın gerçek potansiyeli bence 2026’nın ikinci yarısında daha net ortaya çıkacak; agent dünyai biraz daha olgunlaştıkça işin rengi değişir.
SQL MCP Server, veritabanını agent’lara açarken şemayı gizliyor, RBAC ile erişimi kısıtlıyor ve entity abstraction ile sadece tanımlı operasyonlara izin veriyor. Bu, “SQL injection 2.0” diyebileceğimiz prompt injection saldırılarına karşı ciddi bir savunma hattı.
Küçük bir detay: İşin aslı bu kısım kritik. Şema görünmüyorsa agent kafasına göre sağa sola bakamıyor; RBAC varsa herkes her tabloyu göremiyor; entity abstraction varsa da model sadece tanımladığınız işleri yapabiliyor (mesela rapor çekiyor ama saçma sapan update denemiyor) (şaşırtıcı ama gerçek). Evet, tam da öyle.
Enterprise vs Startup: Kime Uygun?
Küçük bir startup’sanız, hele 3 kişilik ekiple bir chatbot yapıyorsanız, SQL MCP Server biraz fazla kaçabilir. Evet. Container deploy etmek, RBAC kurmak, Entra ayarlamak… bunlar bildiğiniz enterprise işleri; startup tarafında bazen işin aslı daha basit kalıyor. Doğrudan bir ORM üstünden API yazmak daha hızlı ilerliyor. Ama bir yandan da, eğer ölçeklenmeyi kafaya koyduysanız, temeli en baştan düzgün atmak sonradan sizi epey rahatlatır.
Enterprise tarafında tablo değişiyor. Peki neden? Çünkü özellikle şu senaryolarda SQL MCP Server baya iş görüyor:
- Copilot veya chatbot’ların güvenli CRUD operasyonları yapması gereken durumlar
- SQL yazmadan iç otomasyon kurma ihtiyacı — hani IT dışı ekiplerin de agent kullanabilmesi (bu kritik)
- Veritabanını doğrudan expose etmeden agent capability ekleme
- Birden fazla veritabanı tipini tek bir noktadan yönetme (bence en önemlisi)
Bir de caching kısmı var, orayı atlamayalım. Redis ve Azure Managed Redis entegrasyonu geliyor; first-level ve second-level cache desteği de var. Büyük kurumlarda agent’lar aynı sorguyu tekrar tekrar çalıştırabiliyor (bunu sahada çok gördüm), cache olmazsa veritabanı gereksiz yere yoruluyor. Bu entegrasyonun built-in gelmesi güzel, ama dur bir saniye — yine de Redis’i ayrıca kurmanız gerekiyor; sadece yapılandırma tarafında işi biraz toparlıyor.
Observability ve Telemetri
Production’da bir şeyi ayağa kaldırıyorsanız, önü göremiyorsanız, o şey aslında biraz kör çalışıyor demektir. Benim kafamda iş böyle. SQL MCP Server’ın Azure Log Analytics, Application Insights. OpenTelemetry ile konuşabiliyor olması da bu yüzden baya değerli. Daha fazla bilgi için Kubernetes AI Gateway WG: AI Trafiği Artık Standart yazımıza bakabilirsiniz. Copilot CLI’da Auto Model Seçimi: Ne İşe Yarıyor? yazımızda bu konuya da değinmiştik.
Açık konuşayım, AZ-500 sınavına hazırlanırken güvenlik monitöring tarafına epey gömülmüştüm, hani log ne anlatıyor, alarm nerede patlıyor, anomali nasıl yakalanıyor gibi konuların içine girdim. Aynı mantık burada da geçiyor — hangi agent hangi tool’u ne zaman çağırdı, kaç kere döndü, hata aldı mı, response time nasıl gitti (inanın bana). Bunları görmeden sağlıklı yorum yapmak zor. Bilhassa de bir şey ters giderse — mesela bir agent normalden 10 kat fazla veri çekmeye başladıysa — sistemin bunu fark edip ses vermesi lazım. OpenTelemetry entegrasyonu sayesinde Grafana ya da Jaeger gibi araçlarla da izleyebiliyorsunuz, yanı illâ Azure ekranlarına mahkûm değilsiniz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bir müşteride bunu zaten yaşamıştık. Application Insights üzerinden DAB’ın REST endpoint’lerini izliyorduk, dolayısıyla MCP endpoint’leri de aynı pipeline’a düşünce ekstra bir monitöring kurma derdi çıkmadı; açık konuşayım, operasyon tarafı biraz nefes aldı.
Eksikler ve Eleştirilerim
Eh, Tamam, güzel tarafları var. Ama birkaç şey de insanı kaşındırıyor (bizzat test ettim)
Şunu fark ettim: Birincisi, dokümantasyon hâlâ biraz zayıf kalıyor. Microsoft’un kendi blog yazısı giriş için fena değil, hatta ilk bakışta baya yol gösteriyor; ama gerçek dünya senaryoları, edge case’ler ve troubleshooting adımları eksik olunca iş biraz dağılıyor, ben de ilk denememde bir RBAC hatasına takıldım ve çözümü bulmak için GitHub Issues’a girmek zorunda kaldım. Resmî docs’ta yoktu. İyileşir mi? Muhtemelen evet, ama şu an erken adopter’lar ufak bir çile çekebiliyor.
İkincisi, MCP çevrei daha tam oturmamış durumda. Bir bakıma, sQL MCP Server kendi işini yapıyor, bunda sorun yok; asıl mesele ona bağlanacak agent tarafının hâlâ gelişiyor olması. Microsoft Foundry dışında MCP’yi native destekleyen agent framework’ü pek az, yanı liste kısa (en azından benim deneyimim böyle). LangChain ve AutoGen tarafında — kendi adıma konuşayım — MCP client desteği var ama production-ready mi diye sorarsanız, hmm, ben biraz temkinliyim. Daha önce Foundry Agent’a MCP ile Özel Araç Bağlamak yazımda bu entegrasyonu detaylı anlatmıştım — ilgileniyorsanız oraya da bir göz atın.
Şimdi gelelim işin can alıcı noktasına.
Kendi deneyimimden konuşuyorum, Üçüncüsü maliyet konusu. Evet, yazılım ücretsiz görünüyor. Ama container çalıştırmak için compute gerekiyor; Azure Container Instances ya da AKS kullanacaksanız, TL bazında düşününce özellikle küçük firmalar için ekstra bir kalem çıkıyor ortaya. Redis cache ayrı, Application Insights ayrı, sonra bir bakıyorsunuz toplam sahip olma maliyeti sessizce büyümüş. Açık konuşayım, bunu baştan hesaplamazsanız sonradan can sıkabiliyor. Bulut Maliyet Optimizasyonu: Hâlâ Geçerli Prensipler yazımda bu tip gizli maliyetleri nasıl yöneteceğinizi anlatmıştım.
İlk Adımlar: Ne Yapmalısınız?
Denemek istiyorsanız, ben olsam şöyle girerdim işe:
- Önce DAB CLI’ı kurun:
dotnet tool install -g Microsoft.DataApiBuilder - Basit bir SQL Server veya PostgreSQL veritabanıyla test config’i oluşturun
- MCP’yi enable edip stdio transport ile lokal agent’ınıza bağlayın
- VS Code extension’ını kurun — geliştirme deneyimini ciddi kolaylaştırıyor (bence en önemlisi)
- RBAC kurallarını sıkılaştırın, entity bazında minimum yetki verin
Burada işin aslı şu: ilk kurulum genelde hızlı gidiyor, ama sonra küçük detaylar çıkıyor (özellikle config tarafında), o yüzden ben önce dar bir senaryoyla başlayıp sonra genişletmeyi daha mantıklı buluyorum.
Bak şimdi, Eğer Azure MCP araçlarını VS Code’da nasıl kullanacağınızı merak ediyorsanız, Azure MCP Araçları Visual Studio 2022’de Yerleşik Geldi yazım size yol gösterecektir.
Benden söylemesi — üretim ortamına almadan önce mutlaka bir staging’de en az 2 hafta test edin. Agent’ların beklenmedik sorgular üretme potansiyeli var (en azından benim deneyimim böyle). RBAC kurallarınızı agent davranışlarına göre iteratif olarak sıkılaştırmanız gerekecek (ben de ilk duyduğumda şaşırmıştım). Bu bir “kur ve unut” teknolojisi değil.
Sıkça Sorulan Sorular
SQL MCP Server sadece Azure’da mı çalışır?
Hayır, aslında çalışmıyor. Container tabanlı olduğu için AWS, GCP gibi herhangi bir bulutta ya da on-premises Kubernetes/Docker ortamında rahatlıkla çalışıyor. Veri lokalizasyonu gibi bir gereksinimin varsa kendi sunucunda da host edebilirsin (bizzat test ettim)
Kullanmak için kod yazmam gerekiyor mu?
Temel senaryolarda gerekmiyor. Hani bir JSON ayar dosyasıyla entity’lerini, izinlerini ve veritabanı bağlantını tanımlıyorsun, bu kadar. Stored procedure çağırmak ya da custom logic eklemek istersen biraz daha konfigürasyon gerekebilir —. Yine de geleneksel CRUD kodu yazmak zorunda kalmıyorsun. Açıkçası bu en büyük avantajlarından biri bence.
Hangi AI agent framework’leri MCP’yi destekliyor?
Araya gireyim: Microsoft Foundry native olarak destekliyor. Bunun dışında LangChain, AutoGen ve Semantic Kernel’da da MCP client desteği ya var ya geliyor. Ama şunu söyleyeyim, ekosistem henüz olgunlaşma aşamasında — her framework’ün MCP implementasyonu aynı seviyede değil, buna dikkat etmek lazım.
SQL MCP Server ücretli mi?
Hayır, açık kaynak ve tamamen ücretsiz. Yanı yazılımın kendisi için hiçbir lisans ücreti ödemiyorsun. Ama tabiî çalıştıracağın compute kaynağı, mesela Redis cache ya da Application Insights gibi monitöring araçları için altyapı maliyetlerin olacak — bunları hesaba katmayı unutma.
Durun, bir saniye.
Prompt injection saldırılarına karşı ne kadar güvenli?
Tecrübeme göre oldukça iyi bir yaklaşım var burada. Entity abstraction sayesinde agent veritabanı şemasını görmüyor, sadece tanımlı tool’ları çağırabiliyor. RBAC ile de hangi role’ün hangi operasyonu yapabileceğini kısıtlıyorsun. Bu, doğrudan SQL erişimine kıyasla çok daha güvenli bir yöntem (kendi tecrübem). Ama şunu da unutmamak lazım — %100 güvenlik diye bir şey yok, RBAC kurallarını dikkatli tasarlamak gerekiyor.
Kaynaklar ve İleri Okuma
SQL MCP Server Resmî Sayfası (Microsoft)
Data API Builder Resmî Dokümantasyonu
Introducing SQL MCP Server — Azure SQL DevBlog
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.
3 comments