MCP Nedir, Kurumsal Entegrasyonda Ne Değiştiriyor?

Kurumsal entegrasyonun faturası hiçbir zaman tek bir bağlantı olmadı. Çarpım oldu.

Beş farklı yapay zeka modelini sekiz kurumsal sisteme bağlamak istediğinizde önünüzde bir entegrasyon yoktur, kırk entegrasyon vardır. Her biri ayrı yazılır, ayrı test edilir, ayrı bakım ister ve sistemlerden biri API'sini değiştirdiğinde beşi birden bozulur. Bu matematik, kurumsal yazılımda yıllardır aynıdır ve MCP'nin çözmeyi iddia ettiği şey tam olarak budur.

Ama 2026'da kurumsal tarafta asıl değişen şey protokolün kendisi değildi. Aşağıda önce protokolü, sonra o asıl değişen şeyi anlatıyoruz.

Hızlı Cevap: MCP (Model Context Protocol), yapay zeka modellerinin araçlara ve verilere tek bir standart arayüz üzerinden bağlanmasını sağlayan açık bir protokoldür. Kasım 2024'te Anthropic tarafından yayınlandı, Aralık 2025'te Linux Foundation çatısındaki Agentic AI Foundation'a devredildi ve bugün OpenAI, Google, Microsoft, IBM ve Amazon tarafından da destekleniyor. Yani artık tek bir şirketin protokolü değil. Kurumsal tarafta 2026'da değişen şey ise protokolün çekirdeği değil, üstüne oturan yetkilendirme katmanı oldu: kurumun kendi kimlik sağlayıcısının, hangi istemcinin hangi sunucuya kimin adına eriştiğine karar verebilmesi. "Çalışıyor mu" ile "denetim kaydı, kimlik entegrasyonu ve CISO onayıyla çalıştırabilir miyim" farklı sorulardır. Kurumsal dağıtımı belirleyen ikincisidir.

İçindekiler

• MCP nedir?
• Neden şimdi?
• MCP ile klasik API entegrasyonu arasındaki fark
• Kurumsal tarafta asıl değişen: yetkilendirme
• MCP'nin gerçek maliyetleri
• Kendi MCP sunucumuzu kurarken ne öğrendik?
• MCP ve WebMCP aynı şey değil
• Terimler sözlüğü
• Sık sorulan sorular
• Kurumsal dağıtım öncesi kontrol listesi

MCP Nedir?

MCP (Model Context Protocol): Yapay zeka modellerinin dış araçlara, verilere ve sistemlere tek bir standart arayüz üzerinden bağlanmasını sağlayan açık protokoldür.

Fikir basit. Model ile sistem arasına, her ikisinin de konuştuğu ortak bir dil koyarsınız. Sistem tarafında bir MCP sunucusu yazarsınız; bu sunucu "şu araçları sunuyorum, şu parametreleri alıyorlar" der. Model tarafındaki MCP istemcisi bu listeyi okur ve gerektiğinde çağırır.

Kazanç, entegrasyon matematiğinin değişmesidir. Beş model ve sekiz sistem için kırk özel entegrasyon yerine, beş istemci ve sekiz sunucu yazarsınız. Çarpım toplama dönüşür. Yeni bir model geldiğinde sekiz sistemi yeniden bağlamazsınız, model MCP konuşuyorsa zaten bağlıdır.

Bir MCP aracı, özünde bir isim, bir açıklama ve bir parametre şemasından ibarettir:

{
  "name": "list_services",
  "description": "Şirketin sunduğu hizmetleri listeler.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "lang": {
        "type": "string",
        "enum": ["tr", "en", "ru", "ar"],
        "description": "Yanıt dili. Varsayılan: tr"
      }
    }
  }
}

Modelin bu aracı ne zaman çağıracağına karar vermesini sağlayan şey description alanıdır. Kurumsal projelerde en sık atlanan ve en pahalıya patlayan detay da budur: kötü yazılmış bir araç açıklaması, aracın hiç çağrılmamasına ya da yanlış yerde çağrılmasına yol açar.

Neden Şimdi?

MCP Kasım 2024'te yayınlandı, yani protokol yeni değil. Kurumsal tarafta 2026'yı farklı kılan üç şey var.

Artık tek bir şirketin protokolü değil. Anthropic, MCP'yi Aralık 2025'te Linux Foundation çatısı altındaki Agentic AI Foundation'a devretti. Kurumsal satın alma tarafında bu teknik değil stratejik bir fark yaratır: bir standardı benimserken sorulan ilk soru "bu şirket vazgeçerse ne olur" sorusudur ve bağımsız vakıf yönetişimi bu sorunun cevabıdır.

Benimseme eşiği geçildi. Fortune 500 şirketlerinin yaklaşık %28'i on sekiz aydan kısa sürede MCP uygulamaya geçirdi. Temmuz 2026 itibarıyla kurumsal AI ekiplerinin %78'inin üretimde MCP tabanlı ajanları var. Ekosistem tarafında 9.400'ün üzerinde herkese açık sunucu ve ayda 97 milyon SDK indirmesi konuşuluyor. OpenAI, Google, Microsoft, IBM ve Amazon protokolü destekliyor.

Spesifikasyon kurumsal ihtiyaçlara göre olgunlaştı. 28 Temmuz 2026 revizyonu durumsuz (stateless) bir protokol çekirdeği, çok turlu istekler, başlık tabanlı yönlendirme, önbelleklenebilir liste sonuçları ve yetkilendirme sertleştirmesi getirdi. Bunların hiçbiri gösterişli özellikler değil. Hepsi, protokolü demo ortamından üretim ortamına taşıyan sıkıcı şeyler.

MCP ile Klasik API Entegrasyonu Arasındaki Fark

MCP bir API değildir, API'lerin önüne konan bir katmandır. Fark şurada:

Tablodaki son iki satır kurumsal tarafta en çok yanlış anlaşılan kısım. MCP entegrasyonu deterministik değildir: aracı ne zaman çağıracağına model karar verir. Bu esneklik hem gücün hem riskin kaynağıdır ve klasik entegrasyon güvenlik modelinin neden yetmediğini açıklar.

Kurumsal Tarafta Asıl Değişen: Yetkilendirme

MCP'yi bir hafta sonu kurabilirsiniz. Kurumsal ortamda çalıştırmak farklı bir iştir ve mesele protokolün kendisi değildir.

Klasik entegrasyonda yetki statiktir: servis bir hesapla bağlanır, o hesabın yetkileri bellidir, denetim kaydı isteği yapan servisi gösterir. Ajan dünyasında bu model kırılır. Bir ajan, bir kullanıcı adına hareket eder. "Bu isteği kim yaptı" sorusunun cevabı artık bir servis hesabı değil, gerçek bir çalışandır ve o çalışanın yetkilerinin ajana da uygulanması gerekir.

2026'da bu boşluğu kapatan şey EMA (Enterprise-Managed Authorization) oldu. EMA, spesifikasyonun resmî bir uzantısı hâline geldi ve kurumun kendi kimlik sağlayıcısının şu kararı vermesini sağlıyor: hangi MCP istemcisi, hangi MCP sunucusuna, hangi kullanıcı adına erişebilir? Teknik temeli Cross-App Access içindeki ID-JAG (Identity Assertion JWT Authorization Grant). İlk kimlik sağlayıcı olarak Okta, ilk istemciler arasında Claude, Claude Code ve Visual Studio Code yer alıyor.

Pratikte bunun anlamı şu: MCP sunucunuza erişim, kurumun geri kalanıyla aynı kapıdan geçer. Çalışan işten ayrıldığında kimlik sağlayıcıdan devre dışı bırakılır ve MCP erişimi de kapanır. Ayrı bir yetki listesi yönetmezsiniz.

Kurumsal dağıtımda sorulacak sorular teknik olmaktan çok idari:

• Bu sunucuya kim erişebilir ve bu erişim nasıl geri alınır?
• Hangi araç, kim tarafından, ne zaman çağrıldı? Denetim kaydı var mı?
• Erişim gözden geçirmeleri kim tarafından, hangi sıklıkta yapılıyor?
• Araç bazında yetki verilebiliyor mu, yoksa tek anahtar her şeyi mi açıyor?

Bu soruların cevabı yoksa elinizde çalışan bir prototip vardır, dağıtılabilir bir sistem değil.

MCP'nin Gerçek Maliyetleri

MCP hakkında yazılanların çoğu tanıtım metni gibi okunuyor. Kurumsal karar verirken bilmeniz gereken maliyetler şunlar.

Bağlam şişmesi

Bağlı tüm MCP sunucularının araç şemaları modelin bağlamına yüklenir. Yirmi sunucuya bağlıysanız, kullanıcı basit bir soru sorduğunda bile yüzlerce araç tanımı bağlam penceresini işgal eder. Bu hem maliyeti artırır hem model performansını düşürür. Çözüm tarafında araç arama ve gecikmeli yükleme (yalnızca ilgili şemaları getirme) yaklaşımları var, ama varsayılan davranış şişmedir.

Saldırı yüzeyi

MCP'yi kolay yapan şeyler, aynı zamanda saldırı yüzeyini standartlaştırdı. Araç zehirlenmesi (tool poisoning) ve halı çekme (rug pull) saldırıları belgelenmiş durumda: araç açıklamalarına gizlenmiş talimatlarla modelin davranışı yönlendirilebiliyor ya da güvenilen bir sunucu sonradan davranışını değiştirebiliyor. Üçüncü taraf bir MCP sunucusuna bağlanmak, o sunucunun sahibine modelinizin davranışı üzerinde söz hakkı vermektir.

Gecikme

Her araç çağrısı bir tur ekler. Model çağırır, sunucu cevaplar, model yorumlar, belki tekrar çağırır. Çok araçlı iş akışlarında bu turlar birikir. Kullanıcının beklediği bir arayüzde bu fark hissedilir.

Kendi MCP Sunucumuzu Kurarken Ne Öğrendik?

Bu bölüm teori değil. detartech.com üzerinde çalışan bir MCP sunucumuz var ve aşağıdakiler onu yazarken aldığımız kararlar.

Sunucu salt-okunur, durumsuz ve streamable HTTP üzerinden çalışıyor. Şu anda on araç sunuyor. İsterseniz kendiniz deneyebilirsiniz:

curl -s -X POST https://detartech.com/api/mcp \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2025-06-18" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Dönen listede get_company_info, list_services, search_blog, list_case_studies gibi araçlar var. Hepsi bir lang parametresi alıyor ve dört dilde cevap veriyor.

Sunucunun initialize yanıtındaki instructions alanı da önemli. Ajana kısıtınızı protokolün içinde söyleyebilirsiniz; burada sunucunun salt-okunur olduğunu ve iletişim için kullanıcıyı nereye yönlendirmesi gerektiğini açıkça yazıyoruz:

{
  "protocolVersion": "2025-06-18",
  "capabilities": { "tools": { "listChanged": false } },
  "serverInfo": { "name": "detartech", "title": "Detartech", "version": "1.0.0" },
  "instructions": "... This server is read-only: it cannot submit contact or quote requests. To start an inquiry, direct the user to the contact or quote page returned by get_company_info."
}

Salt-okunur başlayın

Sunucuda bilinçli olarak submit_quote ya da submit_contact gibi bir araç yok. Bu kararı üç gerekçeyle aldık ve kurumsal projelerde de aynısını öneriyoruz.

Birincisi, yazma ucu spam ucudur. İnternete dokümante edilmiş, adresi ilan edilmiş, kimlik doğrulaması olmayan bir yazma endpoint'i vermek demektir. İkincisi, lead kalitesi düşer. Ajanın kullanıcı adına doldurduğu teklif talebi, tahmin edilmiş proje detayları içerir; peşine düşüp çöp olduğu anlaşılan bir lead, hiç gelmeyen lead'den kötüdür. Üçüncüsü, bugün tüketicisi yok. Yaygın hiçbir AI asistanı kendiliğinden sunucunuzu keşfedip form göndermiyor. Kazanç sıfıra yakın, açılan saldırı yüzeyi anında gerçek.

Buradan çıkan kural: ajana okuma yeteneği vermek ucuzdur ve risksizdir. Yazma yeteneği vermek ise arkasında kimlik doğrulama, hız sınırı, kötüye kullanım izleme ve lead triyajı gerektiren gerçek bir üründür. İkisini aynı sprintte yapmayın.

Metadata bir vaattir, rozet değil

Ajan hazırlığı konusunda en sık yapılan hata, arkasında bir şey olmayan metadata yayınlamak. Var olmayan bir sunucu için sunucu kartı yayınlarsanız, ajan gerçekten bağlanmayı dener ve başarısız olur. O noktada "ajan uyumlu" değil, bozuk görünürsünüz. Hedefi boş bir keşif kaydı, ajanı hiçbir yere götürmeyen bir yol tabelasıdır.

Aynı dürüstlüğü kendi kurulumumuz için de uygulayalım: bu sunucunun bugün ölçülebilir bir arama görünürlüğü getirisi yok. Değeri vitrin olması ve kendi ürünümüzü kendimizin kullanması. Bunu bilerek kurduk.

Bunu yazarken bulduğumuz sızıntı

En değerli çıktı araçların kendisi olmadı. Sunucuyu yazarken, içerik çeken yardımcı fonksiyonların bir kısmının pasife alınmış kayıtları da döndürdüğünü fark ettik. Yani yayından kaldırılmış hizmet ve yazılar site haritasında, RSS akışında ve arama motorlarına gönderilen bildirimlerde görünmeye devam ediyordu.

Bu, hiçbir SEO denetim aracının yakalamadığı bir hataydı ve MCP sunucusu yazma egzersizi olmasa muhtemelen fark edilmeyecekti. Ajanlara veri açmak, veri erişim katmanınızı gözden geçirmeye zorlar. Kurumsal projelerde bu tek başına yeterli bir gerekçe olabilir.

MCP ve WebMCP Aynı Şey Değil

İsimler benziyor, katmanlar farklı. MCP sunucu tarafında çalışır ve modeli sistemlere bağlar. WebMCP tarayıcıda çalışır ve bir web sayfasının kendi fonksiyonlarını sayfayı ziyaret eden ajana açmasını sağlar.

İkisi rakip değil, farklı sorulara cevap veriyor. MCP "bu sistem hangi verileri sunuyor" sorusunu, WebMCP "bu sayfa ne yapabiliyor" sorusunu cevaplıyor. Bizim kurulumumuzda WebMCP tarafı araçları yeniden tanımlamıyor; kendi MCP sunucumuzun tools/list çıktısını okuyup ona vekillik ediyor. Böylece iki yüzey birbirinden ayrışamıyor, tek kaynak var.

WebMCP tarafını daha önce ayrıntılı yazmıştık: WebMCP: AI Ajanları Siteni Tıklayarak Değil Konuşarak Kullanırsa.

Terimler Sözlüğü

• MCP (Model Context Protocol): Yapay zeka modellerinin araçlara ve verilere tek standart arayüzle bağlanmasını sağlayan açık protokol.
• MCP sunucusu: Araçları ve verileri protokole uygun şekilde dışarı açan taraf.
• MCP istemcisi: Sunucuya bağlanan ve araçları modele sunan taraf (Claude, VS Code gibi).
• Araç (tool): Modelin çağırabileceği, adı, açıklaması ve parametre şeması olan tek bir işlev.
• EMA (Enterprise-Managed Authorization): Kurumun kimlik sağlayıcısının MCP erişimini yönetmesini sağlayan resmî uzantı.
• ID-JAG: EMA'nın dayandığı, kimlik iddiasını yetkiye çeviren JWT tabanlı yetkilendirme mekanizması.
• Durumsuz (stateless) taşıma: Sunucunun istekler arasında oturum tutmaması; ölçeklemeyi kolaylaştırır.
• Araç zehirlenmesi (tool poisoning): Araç açıklamalarına gizlenmiş talimatlarla model davranışının yönlendirilmesi.
• Bağlam şişmesi: Bağlı tüm sunucuların araç şemalarının bağlam penceresini doldurması.
• WebMCP: MCP'nin tarayıcı tarafındaki karşılığı; sayfanın fonksiyonlarını ajana açar.

Sık Sorulan Sorular

MCP, API'lerin yerini mi alıyor? Hayır. MCP API'lerin önüne konan bir katmandır. Altta yine kendi servisleriniz çalışır; MCP onları modelin anlayacağı biçimde tarif eder.

Sadece Anthropic modelleriyle mi çalışıyor? Hayır. Protokol Aralık 2025'te Agentic AI Foundation'a devredildi ve OpenAI, Google, Microsoft, IBM, Amazon tarafından destekleniyor.

Kurumsal bir sistemi MCP ile açmak ne kadar sürer? Salt-okunur bir sunucunun ilk sürümü genellikle günler alır. Süreyi belirleyen kısım protokol değil, yetkilendirme, denetim kaydı ve hangi verinin dışarı açılacağına karar verme sürecidir.

Yazma yetkisi vermek gerekiyorsa ne yapmalı? Kimlik doğrulamayı önce kurun. Kullanıcı adına yetkilendirme, araç bazında izin, hız sınırı ve denetim kaydı olmadan yazma aracı açmayın. Ara çözüm olarak ajanın formu doldurup insanın onaylayıp göndermesi modeli iyi çalışır.

Var olan API'lerimizi olduğu gibi MCP'ye açabilir miyiz? Teknik olarak evet ama genelde kötü sonuç verir. İç API'ler geliştiriciler için tasarlanmıştır; araç açıklamaları ve şemalar model için yeniden yazılmalıdır. Doğrudan sarmalama, modelin yanlış aracı seçmesine yol açar.

Üçüncü taraf MCP sunucularına bağlanmak güvenli mi? Yayıncısına duyduğunuz güven kadar. Bağlandığınız sunucunun sahibi, araç açıklamaları üzerinden modelinizin davranışını etkileyebilir. Kurumsal ortamda üçüncü taraf sunucular gözden geçirmeden ve ağ seviyesinde sınırlandırılmadan bağlanmamalıdır.

Kurumsal Dağıtım Öncesi Kontrol Listesi

• Salt-okunur başlayın; yazma araçlarını ayrı bir proje olarak planlayın
• Kimlik sağlayıcınızla entegrasyonu (EMA / ID-JAG) baştan tasarlayın
• Araç bazında yetki verilebildiğinden emin olun, tek anahtarla her şeyi açmayın
• Her araç çağrısını kim, ne zaman, hangi parametrelerle sorularına cevap verecek şekilde loglayın
• Araç açıklamalarını model için yazın, iç dokümantasyonu kopyalamayın
• Bağlanacak sunucu sayısını sınırlayın; bağlam şişmesi maliyeti gerçektir
• Üçüncü taraf sunucuları gözden geçirin ve ağ seviyesinde kısıtlayın
• Veri erişim katmanınızı gözden geçirin: hangi kayıtlar gerçekten dışarı açılmalı?
• Yayınladığınız her metadata'nın arkasında çalışan bir uç olduğundan emin olun
• Spesifikasyon sürümünüzü takip edin; protokol hızlı ilerliyor

Kapanış

MCP'nin çözdüğü problem yeni değil. Sistemleri birbirine bağlamanın maliyeti yazılımın en eski faturalarından biri ve MCP bu faturayı çarpımdan toplamaya indiriyor. Teknik kazanç gerçek.

Ama kurumsal tarafta işi belirleyen kısım burası değil. Protokolü bir hafta sonu kurarsınız; kimin hangi araca hangi kullanıcı adına eriştiğini yönetmek, denetim kaydını tutmak ve bunu güvenlik ekibine anlatmak aylar alır. 2026'da olgunlaşan da tam olarak bu katman oldu.

Tavsiyemiz sade: salt-okunur bir sunucuyla başlayın, yetkilendirmeyi kurumun geri kalanıyla aynı kapıya bağlayın, yazma yetkisini ayrı bir ürün gibi ele alın. Yapay zeka tarafındaki mimari ve entegrasyon çalışmalarını AI Çözümleri hizmetimiz altında, teknik liderlik ihtiyacını ise CTO as a Service altında yürütüyoruz. Tarayıcı tarafındaki ajan katmanı için WebMCP yazımıza, AI görünürlüğünün ölçümü için GEO KPI yazımıza bakabilirsiniz.