​​​​​ Yapay zeka ekosisteminde her geçen gün yeni kavramla karşılaşıyoruz; agent, RAG, tool calling, context engineering derken liste uzayıp gidiyor. Büyük dil modelleri çok iyi evet, bunda hemfikiriz. Fakat günün sonunda hep aynı sınırda takılıyorlar; model kendi eğitim verisiyle ve o an verdiğimiz bağlamla kısıtlı kalıyor. Şirket içindeki belgelere, veritabanına, Jira veya Confluence gibi sistemlerdeki kayıtlara, kod repolarına veya monitoring sistemi gibi yerlere erişemediği sürece gerçek iş akışlarında her zaman bir adım eksik kalıyor. Bu noktada devreye MCP (Model Context Protocol) giriyor.

MCP Nedir ve Neden İhtiyacımız Var?

Resmi dokümantasyonunda da geçtiği üzere, MCP, AI uygulamalarını harici dış veri kaynakları ve araçlara bağlayan açık kaynaklı bir protokoldür. Bu protokol sayesinde Claude, ChatGPT, Gemini veya benzer modeller dış dünyadaki servislere, dosyalara veya özel servislere erişerek çok daha isabetli kararlar alabilir ve agentic sistemlerde spesifik aksiyonlar gerçekleştirebilir.

Aslında modelleri dış sistemlere bağlamak yeni bir fikir değil. Bugüne kadar custom API entegrasyonları, plugin yapıları veya function calling gibi yöntemlerle bu sorunu çözmeye çalışıyorduk. Fakat burada bir ölçeklenebilirlik problemi vardı.

Bir tarafta farklı AI istemcileri (Claude, Gemini, Copilot vb.) dururken, diğer tarafta bağlanmamız gereken onlarca sistem var; PostgreSQL, Jira, Confluence, log sunucuları vb. Her model için her sisteme ayrı bir entegrasyon yazmaya kalktığınızda bir noktadan sonra asıl işi bırakıp sadece entegrasyon kodu yazar hale geliyorsunuz. Buna çözüm olarak, Claude dil modellerini de geliştiren Anthropic firması, bir standart belirleyelim diyerek MCP’yi yayınladı.

MCP’nin ne olduğunu en iyi anlatan benzetme kendi resmi dokümantasyonunda da geçen USB-C benzetmesidir. MCP, yapay zeka dünyasının USB-C portudur deniliyor. Nasıl ki USB-C farklı cihazları tek bir portta buluşturuyorsa, MCP de benzer şekilde AI uygulamaları ve dış sistemler arasına o evrensel iletişim katmanını kuruyor.

MCP Mimarisinde Kim Kimdir?

 

Teknik mimariyi kafamızda oturtmak için üç temel bileşeni bilmemiz gerekiyor: Host, Client, Server. Host, Claude Desktop, Cursor veya kendi geliştirdiğiniz özel bir AI asistanı gibi, kullanıcının doğrudan muhatap olduğu ana uygulamadır. Client, host uygulamasının içinde çalışan ve sunucu (server) bağlantısını yöneten parçadır. Kullanıcı genelde bu katmanı görmez; her MCP Server için ayrı bir client arkaplanda bu iletişimi yürütür. Son olarak server ise, ilgili dosyaya, veritabanına veya API’ye gidip veriyi çeken, modelin dış dünyaya açılan güvenli kapısıdır.​

Süreç oldukça basit işler; kullanıcı soru sorar, host bunu yorumlar, client bağlı server’ların sunduğu araçları (tools) bilir, model gerekirse uygun aracı çağırır ve server işlemi yapıp sonucu döner. Model de aldığı bu gerçek veriyi kullanarak size çok daha bağlamlı bir cevap üretir. 

Bir MCP Server Bize Ne Sağlar?

Bir server geliştirdiğinizde modele temelde üç ana yetenek kazandırabilirsiniz: Tools, Resources, Prompts. Tools ile modelin aksiyon almasını sağlayan, LLM tarafından çağrılabilen fonksiyonlar sağlarız. Bu fonksiyonlarla servis veya veritabanlardaki verileri getirebilir veya bazı aksiyonları tetikleyebiliriz. Resources, modelin okuması için sunulan dosya benzeri veri kaynaklarıdır. Veritabanı şemaları, konfigürasyon dosyaları veya uygulama metadataları bu gruba girer. Prompts ise belirli görevler için hazırlanmış, kullanıcıların işini kolaylaştıran, tekrar kullanılabilir şablonlardır. Örneğin “bu kodu review et” dediğimizde neye göre nasıl review etmesi gerektiğini belirten yönerge ve kuralları prompts içinde tutup ihtiyaç durumunda tekrar yazmadan kullanabiliriz.

Ek bir not düşmekte fayda var, iletişim sadece tool çağırmaktan ibaret değildir. Bir MCP Server da client üzerinden model completion (tamamlama) isteyebilir veya elicitation ve loglama gibi primitive özelliklerini kullanabilir.

Klasik API’dan Ne Farkı Var?

Backend geliştiricisi olarak en çok karşılaştığımız soru “Biz zaten REST API yazıyoruz, MCP ekstra ne katıyor?”. Aslında MCP’yi API’nin bir alternatifi olarak düşünmemek gerekiyor. Siz bir API yazdığınızda endpoint’leri ve auth yapılarını sadece siz ve orada geliştirme yapan ekip üyeleriniz bilir. Bunu LLM modeline kullandırmak için de ayrıca tool şeması, parametre tipleri ve güvenlik kontrolleri tanımlamanız gerekir. MCP Server ise mevcut API’nizi veya veritabanınızı modele standart ve keşfedilebilir bir formatta sunan bir katmandır. Client, `tools/list` komutuyla server’daki yetenekleri keşfeder (isim, açıklama ve input schema bilgileriyle birlikte) ve uygun bulursa `tools/call` ile işlemi çalıştırır. Yani yeni bir iş mantığı yazmıyoruz ve olan servislerimizi AI için güvenli ve standart bir şekilde konuşulabilir hale getiriyoruz.

Python ile Basit Bir MCP Server Yazımı

Resmi olarak desteklenen birçok SDK mevcut; TypeScript, Python, C#, Go vb. Hızlıca görebilmek adına Tier 1 destek seviyesinde olan Python ve FastMCP kütüphanesini kullanarak basit bir örnek yapalım. FastMCP, type hint’leri okuyarak tool tanımlarını otomatik üretir.

Önce projemizi kuralım:​


uv init mcp-demo
cd mcp-demo
uv venv
source .venv/bin/activate
uv add "mcp[cli]"

Ardından `server.py` adında bir dosya oluşturup kodumuzu yazıyoruz:


from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Demo MCP Server")


@mcp.tool()
def toplam(a: int, b: int) -> int:
    """İki sayıyı toplar."""
    return a + b
 
@mcp.tool()
def musteri_durumu_getir(musteri_no: str) -> dict:
    """Müşteri numarasına göre örnek müşteri durumunu döner."""
    return {
        "musteriNo": musteri_no,
        "durum": "Aktif",
        "segment": "Kurumsal"
    }
 
def main():
    mcp.run(transport="stdio")
 
if __name__ == "__main__":
    main()


Bu sunucuyu `uv run server.py` komutuyla ayağa kaldırabilirsiniz. Örneğin Claude Desktop uygulamasının yapılandırma dosyasına bu server’ı eklemek isterseniz, ilgili istemcinin `mcpServers` alanına absolute (mutlak) dosya yolunu belirterek bir konfigürasyon eklemeniz gerekir:​


{
  "mcpServers": {
    "demo": {
      "command": "uv",
      "args": [
        "--directory",
        "/ABSOLUTE/PATH/TO/mcp-demo",
        "run",
        "server.py"
      ]
    }
  }
}​​


Burada dikkat edilmesi gereken detay, özellikle local stdio server’larda relative (göreceli) path kullanımının sorun çıkarabilmesidir. Bu yüzden resmi dokümantasyonda mutlaka absolute path kullanılmasını önerilmiş. Ayrıca geliştirdiğiniz server’ı doğrudan host uygulamasına bağlamadan önce `npx @modelcontextprotocol/inspector` komutuyla interaktif MCP Inspector üzerinde test edip debug etmek, hataları bulmayı çok daha kolaylaştıracaktır.

Geliştirme sırasında stdout üzerinden log basmamaya özellikle dikkat etmelisiniz. Çünkü stdio transport bu kanalı protokol mesajları (JSON-RPC) için kullanır; loglarınızı stderr’e veya ayrı bir dosyaya yazmalısınız. 

Local vs Remote MCP Server Farkı

Bir MCP Server, ihtiyacınıza göre local veya remote çalışabilir. Local server’larda genelde stdio transport ile kullanıcının kendi bilgisayarında çalışır. Burada dosya sistemi erişimi için yalnızca belirli klasörlere izin verilmesi ve her aksiyon için kullanıcı onayı alınması çok kritiktir. Kişisel geliştirme ortamları veya local araçlar için idealdir.

Remote server'lar​ ise internet üzerinden, çoğunlukla Streamable HTTP transport ile erişilebilen yapılardır. Kurumsal düzeyde paylaşımlı bir Jira, Confluence veya merkezi bir log sistemine entegre olacaksanız, server-side authentication gerektiren bu mimari çok daha uygundur.

Kurumsal Ölçekte MCP ve Güvenlik

Kurumsal bir senaryoda şirketin tüm sistemlerini (loglar, veritabanları, repolar vs.) tek bir büyük entegrasyon üzerinden vermek yerine, her sistem veya yetenek grubu için ayrı MCP Server’lar kurgulamak yapıyı çok daha sürdürülebilir kılar. Ancak onlarca server ve tool olduğunda hepsini her sohbetin başında modele göndermek hem ciddi token maliyeti yaratır hem de modelin doğru tool seçmesini zorlaştırır. Bu durumlar için best practice olarak, tüm tool’ları en başta yüklemek yerine ihtiyaç oldukça ilgili tool detaylarını bağlama dahil eden “progressive tool discovery” yöntemi kullanılmalıdır.

Bir diğer ve en önemli konu ise güvenliktir. MCP ile modelin artık sadece metin üretmediğini ve aksiyon alabildiğini biliyoruz. Daha önce Turkcell Medium makalesinde​ bahsettiğim LLM Injection tehlikeleri burada tam anlamıyla kendini gösteriyor diyebiliriz. Modelden gelen inputlar kesinlikle güvenilmez kabul edilmeli ve tool açıklamaları veya dönen sonuçların bile bir prompt injection yüzeyi oluşturabileceği unutulmamalıdır.

MCP resmi güvenlik dokümantasyonu; confused deputy problem, SSRF, session hijacking ve token passthrough gibi zafiyetlere karşı geliştiricileri uyarır. Server’lara gereğinden fazla yetki (örneğin sadece okuma gereken yere yazma izni) verilmemeli ve kritik operasyonlarda kesinlikle kullanıcı onayı kurgulanmalıdır. Hassas verilere erişen server’lar için OAuth 2.1 veya şirkette kullanılan güvenli bir oturum sistemi kullanılması tavsiye edilir.

Kapanış

Eğer dış sistemlerle konuşmayan, kapsamı çok dar basit bir chatbot geliştiriyorsanız doğrudan function calling işinizi görebilir, MCP server burada gereksiz kaçabilir. Ancak birden fazla AI client’ın bağlanacağı, standart, yönetilebilir ve kurumsal seviyede tekrar kullanılabilir asistanlar (IDE entegrasyonları, operasyon asistanları, kurumsal bilgi erişim botları vb.) kurmak istiyorsanız MCP kesinlikle kullanmanız gereken bir yapıdır.

Burada unutulmaması gereken örnek bir nokta var; MCP, sihirli bir değnek değil. Sadece sistemleri bağlamak için standart ve ölçeklenebilir bir iletişim katmanı sunuyor. Sistemi güvenli kurgulamak, sınırları doğru çizmek, hangi işlemlerin onaya bağlanacağını planlamak ve bağlamı doğru yönetmek ise tamamen biz geliştiricilerin elinde.

Bir sonraki yazıda görüşmek üzere, sevgiler.​