AI Genel Çalışma Rehberi

Blog / Rehber

MCP Nedir? Model Context Protocol'e Türkçe Giriş

12 dk okumaMCPModel Context ProtocolTool CallingJSON-RPCOAuth

Bir dil modeli tek başına yalnızca metin üretir. Bir dosyayı okuması, veritabanına sorgu atması ya da bir ağ cihazından durum bilgisi alması için onu dış dünyaya bağlayan bir katman gerekir. Model Context Protocol (MCP), bu bağlantıyı standart hale getiren açık bir protokoldür: bir AI uygulaması ile ona veri ve yetenek sağlayan sistemler arasındaki konuşmanın kurallarını tanımlar.

Bu yazıda MCP'nin hangi problemi çözdüğünü, mimarisini, sunduğu yapı taşlarını ve bir tool çağrısının uçtan uca nasıl aktığını anlatıyoruz.

TL;DR

MCP hangi problemi çözüyor?

MCP'den önce her AI uygulaması her entegrasyonu kendi yöntemiyle yazıyordu. Beş farklı AI uygulamasını on farklı sisteme bağlamak isteyen bir ekip, pratikte elli ayrı entegrasyonla uğraşıyordu. Her entegrasyonun kendi kimlik doğrulaması, hata modeli ve veri formatı vardı.

MCP bu çarpımı toplama çevirir: bir sistem için bir kez MCP server yazarsınız, MCP destekleyen her uygulama onu kullanabilir. Bir uygulamaya bir kez MCP client desteği eklenir, mevcut tüm server'lara bağlanabilir. Bu yüzden MCP için sıkça "AI uygulamalarının USB-C'si" benzetmesi yapılır.

MCP'nin bir tool calling alternatifi olmadığını da baştan söylemek gerekir. Tool calling, modelin "şu aracı şu parametrelerle çağır" diyebilmesidir ve model API'sinin bir özelliğidir. MCP ise o araçların nereden geldiğini, nasıl keşfedildiğini ve nasıl çalıştırıldığını standartlaştırır. Model yine tool calling yapar; host bu çağrıyı MCP üzerinden doğru server'a iletir.

Mimari: host, client ve server

MCP'de üç rol vardır:

RolNe yaparÖrnek
HostKullanıcının etkileştiği AI uygulaması. Modeli çalıştırır, hangi server'lara bağlanılacağına ve hangi işleme izin verileceğine karar verir.Masaüstü AI asistanı, IDE, kendi yazdığınız agent
ClientHost'un içinde, tek bir server ile birebir bağlantıyı yöneten bileşen. Her server için ayrı bir client oluşur.Host'un MCP kütüphanesi
ServerBir sistemi (dosya sistemi, veritabanı, API, ağ cihazı) MCP üzerinden sunan program.GitHub server'ı, PostgreSQL server'ı, kendi iç API'niz için yazdığınız server

Önemli bir ayrıntı: model server'la doğrudan konuşmaz. Model yalnızca host'un ona verdiği tool listesini görür ve bir tool çağırmak istediğini söyler. Çağrıyı server'a iletmek, sonucu modele geri vermek ve gerekirse kullanıcıdan onay almak host'un işidir. Güvenlik kararlarının host'ta toplanması bu yüzden mümkündür.

Yapı taşları: tools, resources ve prompts

Bir server, bağlandığı uygulamaya üç tür yetenek sunabilir. Aralarındaki fark, kimin kontrol ettiğidir:

Yapı taşıKim kullanırNe işe yararÖrnek
ToolsModel (host onayıyla)Bir işlem yapar, yan etkisi olabilircreate_issue, run_query, get_interface_status
ResourcesUygulamaOkunabilir veri sağlar; modelin bağlamına eklenirBir dosyanın içeriği, bir tablonun şeması
PromptsKullanıcıHazır, parametreli şablonlar"Bu PR'ı incele", "Olay raporu hazırla"

Her tool bir ad, bir açıklama ve parametreleri tanımlayan bir JSON Schema ile gelir. Model hangi tool'u ne zaman kullanacağına bu açıklamaya bakarak karar verir. Bu yüzden iyi bir tool açıklaması, iyi bir fonksiyon adı kadar önemlidir.

Bağlantı yalnızca server'dan client'a doğru çalışmaz. Client da server'a bazı yetenekler sunabilir:

Taşıma katmanı: stdio ve Streamable HTTP

MCP mesajları JSON-RPC 2.0 formatındadır: her istek bir method, bir id ve params taşır; cevap aynı id ile döner. Bu mesajların nasıl taşınacağı ise iki yolla tanımlanır:

Hangi taşımayı kullanırsanız kullanın, üstteki mesajlar aynıdır. Aynı server'ı geliştirirken stdio ile, üretimde HTTP ile çalıştırabilirsiniz.

Bir tool çağrısının yolculuğu

Aşağıdaki akış, kullanıcının "Ankara'daki switch'in uplink portu açık mı?" diye sorduğu bir senaryoyu gösteriyor:

sequenceDiagram participant U as Kullanıcı participant H as Host (AI uygulaması) participant M as Model participant S as MCP server H->>S: initialize (protokol sürümü, client yetenekleri) S-->>H: server yetenekleri (tools, resources…) H->>S: tools/list S-->>H: tool tanımları (ad, açıklama, JSON Schema) U->>H: "Ankara switch'inin uplink portu açık mı?" H->>M: kullanıcı mesajı + tool tanımları M-->>H: tool_use: get_interface_status(device, port) H->>U: (gerekirse) onay iste H->>S: tools/call get_interface_status S-->>H: sonuç: {"status": "up", "speed": "10G"} H->>M: tool sonucu M-->>H: "Evet, uplink portu açık ve 10G hızında çalışıyor." H->>U: cevap

Akışın üç aşaması var:

  1. Tanışma (initialize): Client ve server desteklenen protokol sürümünü ve yeteneklerini karşılıklı bildirir. Örneğin server "tools sunuyorum ve liste değişirse bildiririm" der.
  2. Keşif (tools/list): Host, server'ın sunduğu tool'ları öğrenir ve bunları modele tool tanımı olarak verir.
  3. Çağrı (tools/call): Model bir tool kullanmak istediğinde host çağrıyı server'a iletir, sonucu modelin bağlamına ekler ve model cevabını üretir.

Bir tools/call isteği JSON-RPC olarak şöyle görünür:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_interface_status",
    "arguments": { "device": "ank-sw-01", "port": "Ethernet1/49" }
  }
}

Uzak server'larda yetkilendirme

Yerel bir stdio server'ı, onu başlatan kullanıcının yetkileriyle çalışır. Uzak bir HTTP server'ında ise "bu isteği kim, hangi yetkiyle yapıyor?" sorusunun cevaplanması gerekir. MCP spesifikasyonu bunun için OAuth 2.1 tabanlı bir akış tanımlar:

Güvenlik: dikkat edilmesi gerekenler

MCP, modelin dış dünyada işlem yapabilmesini sağladığı için yeni saldırı yüzeyleri de getirir. En sık karşılaşılanlar:

Pratikte bu riskler tek bir katmanda çözülmez. Güvenilir server'ları seçmek, host'ta yazma işlemleri için onay istemek, tool sonuçlarını talimat değil veri olarak ele almak ve çağrıları kimin hangi yetkiyle yaptığını loglamak birlikte uygulanır. Kurumsal ortamlarda bu kontroller çoğu zaman bir AI gateway ve policy katmanında merkezileştirilir.

Nereden başlamalı?

Kaynaklar