MCP Server Nasıl Oluşturulur?

Model Context Protocol (MCP) sunucusu, yapay zeka modellerinin şirket içi veri tabanlarına, kurumsal dosya sistemlerine ve harici servis araçlarına güvenli, çift yönlü ve standartlaştırılmış bir protokolle bağlanmasını sağlayan açık kaynaklı bir mimari standarttır.

Yapay zeka modellerinin kurumsal verilerle etkileşime girme biçimi, izole API uç noktalarından dinamik ve standart protokol katmanlarına doğru evrilmektedir. Karar vericiler ve yazılım ekipleri için veri silolarını LLM (Büyük Dil Modeli) ekosistemine entegre etmek çoğu zaman yüksek bakım maliyeti, güvenlik açıkları ve entegrasyon karmaşası yaratır. Bu rehberde, Anthropic tarafından açık standart olarak sunulan Model Context Protocol altyapısını merkeze alarak MCP Server Nasıl Oluşturulur? sorusunun operasyonel, mimari ve güvenlik yanıtlarını bulacaksınız. Kurulum aşamalarından yetkilendirme modellerine, SDK tercihlerinden kurumsal istemci entegrasyonuna kadar tüm süreci teknik detaylarıyla ele alıyoruz.

Model Context Protocol (MCP) Nedir ve Kurumsal Mimarideki Rolü

Model Context Protocol (MCP), büyük dil modelleri ile dış veri kaynakları ve araçlar arasında evrensel, güvenli ve çift yönlü bir iletişim standardı belirleyen açık kaynaklı bir protokoldür. Geleneksel yaklaşımlarda her LLM aracı için özel bağlayıcılar (custom connectors) veya izole fonksiyon çağrıları (function calling şablonları) yazılması gerekirken, MCP bu süreci standart bir istemci-sunucu (client-server) mimarisine dönüştürür.

Protokolün kurumsal sistemlerdeki birincil rolü, verinin bulunduğu ortamdan taşınmadan, doğrudan ihtiyaç anında modele bağlamsal (in-context) olarak aktarılmasını sağlamaktır. Bu durum, veri kopyalama maliyetlerini ortadan kaldırır ve hassas kurumsal bilginin merkezi olmayan, kontrollü uç noktalarda tutulmasına olanak tanır. MCP sunucusu, veri kaynağının önünde akıllı bir bekçi katmanı oluşturarak modelin sadece izin verilen yetki alanında sorgulama yapabilmesini sağlar.

LLM'ler ve Veri Kaynakları Arasındaki Standart Köprü

Geliştiriciler daha önce her yeni model sağlayıcısı (OpenAI, Anthropic, yerel açık kaynaklı modeller) için ayrı API entegrasyon katmanları inşa etmek zorundaydı. MCP, JSON-RPC 2.0 mesajlaşma standardı üzerine oturarak bu parçalanmış yapıyı birleştirir. Bir MCP istemcisi (örneğin bir AI IDE aracı veya masaüstü asistanı), bağlı olduğu MCP sunucusuna sorgu gönderdiğinde, sunucu işletim sistemi komutları, veritabanı sorguları veya web kancaları (webhooks) aracılığıyla veriyi toplar ve standart formatta geri döndürür.

Bu standartlaşma sayesinde tek bir defa geliştirilen MCP sunucusu; PostgreSQL veritabanı, yerel dosya sistemi, GitHub deposu veya kurumsal ERP yazılımı gibi kaynakları destekleyen tüm yapay zeka istemcilerine anında açabilir. Geliştirme maliyetleri düşerken kurumsal veri mimarisinin yeniden kullanılabilirliği (reusability) maksimum seviyeye çıkar.

Geleneksel API Entegrasyonları ile MCP Arasındaki Yapısal Farklar

Geleneksel REST ve GraphQL mimarileri, önceden tanımlanmış parametrelerle istemci tarafından doğrudan tetiklenen deterministik uç noktalar sunar. MCP ise yapay zeka modellerinin "akıl yürütme ve planlama" döngülerine uygun semantik meta veriler (metadata) taşır. Model, sunucunun kabiliyetlerini inceleyerek hangi aracı ne zaman çağıracağına kendi bağlamsal kararıyla varır.

Aşağıdaki tablo, geleneksel kurumsal entegrasyon yöntemleri ile Model Context Protocol arasındaki temel operasyonel ve mimari ayrımları özetlemektedir:

MCP Sunucusu Oluştururken Güvenlik, İzinler ve Risk Yönetimi

Kurumsal bir ortama bağlanan yapay zeka sistemlerinde en büyük endişe kaynağı kontrolsüz veri erişimi ve yetkisiz işlem yürütmedir. Bir MCP sunucusu doğrudan şirket veritabanına veya kritik API'lere erişim hakkına sahip olduğunda, modelin yapacağı bir hata veya maruz kalacağı bir saldırı felaketle sonuçlanabilir. Bu nedenle sunucu tasarımının ilk adımı kod yazmak değil, güvenlik çerçevesini (security perimeter) çizmektir.

Yetki sınırlandırması (sandboxing), veri izolasyonu ve istemci bazlı rol yönetimi, MCP sunucusu geliştirmede temel tasarım prensipleri arasında yer almalıdır. Sunucunun sunduğu araçlar (Tools), prensip olarak "en az ayrıcalık" (Principle of Least Privilege) ilkesine göre sınırlandırılmalıdır.

Veri İzolasyonu, Yetki Sınırlandırması (Sandboxing) ve KVKK/GDPR Uyumu

Bir MCP sunucusu geliştirirken kaynakların (Resources) ve araçların (Tools) erişim alanı işletim sistemi düzeyinde izole edilmelidir. Yerel dosya sistemine erişen bir sunucu tasarlanıyorsa, sunucunun erişebileceği kök dizin (root directory) kesin bir şekilde sınırlandırılmalı ve ../ gibi dizin geçişi (path traversal) açıklarına karşı girdi sanitizasyonu uygulanmalıdır.

Kişisel verilerin işlenmesi bağlamında (KVKK ve GDPR gereksinimleri doğrultusunda), MCP sunucusu üzerinden LLM bağlamına iletilen verilerin anonimleştirilmesi veya maskelenmesi kritik bir adımdır. Örneğin, bir müşteri veritabanı sunucusu çalıştırılıyorsa, kredi kartı numaraları, T.C. kimlik numaraları veya e-posta adresleri sunucu katmanında regex filtrelerinden geçirilmeli ve istemciye sadece maskelenmiş veri teslim edilmelidir. Verinin LLM sağlayıcısının sunucularına gitmeden önce yerel sunucuda filtrelenmesi, uyumluluk cezalarının önüne geçer.

Prompt Injection, Halüsinasyon ve Veri Sızıntısı Risklerini Azaltma

Büyük dil modelleri, kullanıcı girdileri veya üçüncü parti web içerikleri üzerinden gelen dolaylı prompt injection (Indirect Prompt Injection) saldırılarına karşı kırılgandır. Kötü niyetli bir metin, modele MCP sunucusu üzerinden hassas bir dosyanın içeriğini okumasını veya veritabanındaki bir tabloyu silmesini emredebilir.

Bu riskleri bertaraf etmek için aşağıdaki koruma mekanizmaları MCP sunucusu koduna entegre edilmelidir:

• Sıkı Şema Doğrulaması: Girdi parametreleri JSON Schema standartlarına göre kesin tiplerle doğrulanmalı, beklenmeyen anahtarlar derhal reddedilmelidir.

• Salt Okunur (Read-Only) Varsayılanlar: Veritabanı MCP sunucularında işlem yaparken başlangıçta sadece SELECT yetkisi tanımlanmalı; UPDATE, INSERT veya DELETE işlemleri ayrı ve ek güvenlikli araçlara bölünmelidir.

• İkincil Onay Mantığı: Sunucu kritik bir komut çalıştırmadan önce istemciye onay gereksinimi (confirmation_required: true) bayrağı iletmelidir.

İnsan Denetimi (Human-in-the-Loop) Mekanizması Tasarlamak

Tam otonom araç çalıştırma senaryoları, özellikle finansal transferler, e-posta gönderimleri ve üretim veritabanı değişiklikleri gibi geri döndürülemez işlemlerde yüksek risk taşır. Model Context Protocol mimarisinde insan denetimi (human-in-the-loop), sunucunun tehlikeli eylemleri yürütmeden önce bir operatör onayı beklemesi prensibine dayanır.

MCP protokolü, istemciye aracın yan etkilerini (side-effects) bildirme yeteneğine sahiptir. Bir sunucu oluştururken tahribat yaratabilecek her araç için meta veriler açıkça belirtilmeli ve istemcinin kullanıcı arayüzünde "Bu işlem veritabanında değişiklik yapacaktır, onaylıyor musunuz?" uyarısı tetiklenmelidir. Bu yapı, modelin halüsinasyon görerek yanlış bir tabloyu güncellemesi veya yetkisiz bir API çağrısı yapması durumunda kurumsal bariyer vazifesi görür.

Adım Adım MCP Sunucusu Nasıl Oluşturulur? (Mimari Yol Haritası)

Teknik bir MCP sunucusu geliştirmek; ortamın hazırlanması, uygun SDK seçimi, protokol ilkellerinin (primitives) kodlanması ve taşıma katmanının (transport layer) yapılandırılması olmak üzere dört ana teknik aşamadan oluşur. Süreç, geliştiricinin ihtiyaç duyduğu veri kaynağı karmaşıklığına bağlı olarak ortalama birkaç saat içinde tamamlanabilir.

Doğru mimariyi kurgulamak için öncelikle protokolün sunduğu üç temel yapı taşını kavramak gerekir:

1. Resources (Kaynaklar): Modelin pasif olarak okuyabileceği dosya, veritabanı kaydı veya log gibi veri kaynakları (REST mimarisindeki GET isteklerine benzer).

2. Tools (Araçlar): Modelin aktif olarak çalıştırabileceği, parametre alabilen ve sistem üzerinde işlem yürüten fonksiyonlar (POST/PUT/DELETE benzeri eylemler).

3. Prompts (İstem Şablonları): Kullanıcıların belirli görevleri yürütmesi için sunucu tarafından önceden optimize edilmiş prompt kalıpları.

Geliştirme Ortamının Hazırlanması: TypeScript SDK vs Python SDK

Anthropic, Model Context Protocol için iki resmi SDK sunmaktadır: @modelcontextprotocol/sdk (TypeScript/JavaScript) ve mcp (Python). Geliştirme ortamı seçimi projenin hedeflerine ve entegre edilecek veri kaynaklarının ekosistemine göre belirlenmelidir.

• TypeScript / Node.js Tercihi: Web tabanlı API'ler, mikroservisler, JSON işleme yoğunluklu mimariler ve kurumsal Node.js altyapıları için idealdir. Hızlı I/O performansı ve güçlü tip denetimi (TypeScript) sunar.

• Python Tercihi: Veri bilimi, makine öğrenmesi modelleri, Pandas/NumPy ile veri manipülasyonu veya yerel otomasyon scriptleri entegre edilecekse en uygun çözümdür. FastMCP gibi üst seviye kütüphanelerle geliştirme süresini minimuma indirir.

Geliştirme için sisteminizde Node.js (v18+) veya Python (v3.10+) kurulu olmalıdır. Paket yöneticisi olarak TypeScript için npm veya pnpm, Python için ise modern paket yöneticisi olan uv tercih edilmesi önerilir.

Temel Protokol Bileşenlerinin İnşası: Tools, Resources ve Prompts

Sunucunun mantıksal omurgasını oluştururken her bileşenin sorumluluk alanı kesin bir şekilde ayrılmalıdır. Bir SQLite veritabanı veya şirket içi dosya deposu için MCP sunucusu inşa edildiğini varsayalım.

Sunucu tarafında bir Tool tanımlanırken, LLM'in bu aracı ne zaman ve nasıl çağıracağını anlayabilmesi için açıklayıcı bir description ve Zod/Pydantic şeması tanımlanır:

// TypeScript SDK ile Basit Bir MCP Tool Tanımı Örneği
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ListToolsRequestSchema, CallToolRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import { z } from "zod";

const server = new Server(
  { name: "corporate-data-server", version: "1.0.0" },
  { capabilities: { tools: {}, resources: {} } }
);

// Araç Listesini İstemciye Bildirme
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "query_sales_db",
        description: "Kurumsal satış veritabanında SQL sorgusu çalıştırır. Sadece SELECT komutları kabul edilir.",
        inputSchema: {
          type: "object",
          properties: {
            sqlQuery: { type: "string", description: "Çalıştırılacak SQL SELECT sorgusu" }
          },
          required: ["sqlQuery"]
        }
      }
    ]
  };
});

// Aracın Çalıştırılma Mantığı
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "query_sales_db") {
    const query = String(request.params.arguments?.sqlQuery);
    
    // Basit Güvenlik Denetimi
    if (!query.trim().toUpperCase().startsWith("SELECT")) {
      throw new Error("Güvenlik İhlali: Sadece okuma (SELECT) sorgularına izin verilmektedir.");
    }

    // Veritabanı sorgu mantığı burada işletilir...
    const mockResult = [{ id: 101, region: "EMEA", revenue: 450000 }];
    
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(mockResult, null, 2)
        }
      ]
    };
  }
  throw new Error("Bilinmeyen araç çağrısı.");
});

İletişim Katmanı ve Taşıma Protokolü: Stdio ve SSE (Server-Sent Events)

MCP, istemci ve sunucu arasındaki fiziksel iletişimi soyutlayan iki temel taşıma (transport) mekanizması sunar. Mimarinizin yerel mi yoksa uzaktan erişilen bir bulut servisi mi olduğuna göre doğru mekanizmayı seçmelisiniz:

1. Standart Girdi/Çıktı (stdio): Sunucu, istemci tarafından bir alt işlem (child process) olarak başlatılır. Mesajlar standart girdi (stdin) ve standart çıktı (stdout) kanalları üzerinden JSON-RPC formatında iletilir. Claude Desktop, Cursor veya yerel AI istemcileri için en hızlı, en güvenli ve sıfır ağ yapılandırması gerektiren yöntemdir.

2. Server-Sent Events (SSE): Sunucunun bağımsız bir HTTP servisi olarak çalıştığı, uzak ağlarda veya Docker konteynerlerinde barındırıldığı senaryolarda kullanılır. İstemci sunucuya HTTP POST ile istek gönderir, sunucu ise yanıtları sürekli açık bir HTTP SSE kanalı üzerinden asenkron olarak geri akıtır. Kurumsal ağlarda merkezi bir MCP sunucu havuzu oluşturulacaksa SSE protokolü tercih edilmelidir.

Oluşturulan MCP Sunucusunu LLM İstemcilerine Entegre Etme

Kodlanan bir MCP sunucusunun gerçek dünya değerine ulaşması, uyumlu bir LLM istemcisine (MCP Client) bağlanmasıyla gerçekleşir. Günümüzde Anthropic Claude Desktop, Cursor AI, Windsurf ve Zed gibi modern geliştirici araçları yerel MCP istemcisi olarak çalışabilmektedir. Kurumsal ölçekte ise özel web arayüzleri ve LLM orkestrasyon motorları (LangChain, LlamaIndex vb.) MCP istemcisi rolünü üstlenebilir.

Entegrasyon süreci, istemcinin sunucuyu nasıl başlatacağını veya uzaktaki sunucuya nasıl bağlanacağını bildiren bir yapılandırma dosyasının hazırlanmasından ibarettir.

Yerel Testler İçin Claude Desktop Entegrasyonu

Geliştirilen bir MCP sunucusunu yerel ortamda doğrulamak için en pratik yöntem Claude Desktop istemcisini kullanmaktır. Claude Desktop, işletim sistemindeki bir JSON konfigürasyon dosyasını okuyarak tanımlı sunucuları stdio üzerinden otomatik olarak alt işlem olarak başlatır.

Yapılandırma dosyasının konumu işletim sistemine göre değişiklik gösterir:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

• Windows: %APPDATA%\Claude\claude_desktop_config.json

Aşağıdaki yapılandırma örneği, hem Node.js (TypeScript) ile derlenmiş bir sunucuyu hem de yerel bir Python sunucusunu Claude Desktop'a bağlamak için kullanılan standart JSON yapısını göstermektedir:

{
  "mcpServers": {
    "sales-analytics": {
      "command": "node",
      "args": ["/Users/kullanici/projects/mcp-sales-server/build/index.js"],
      "env": {
        "DB_CONNECTION_STRING": "postgresql://user:pass@localhost:5432/sales_db",
        "LOG_LEVEL": "info"
      }
    },
    "filesystem-assistant": {
      "command": "uv",
      "args": [
        "--directory",
        "/Users/kullanici/projects/mcp-python-server",
        "run",
        "server.py"
      ]
    }
  }
}

Bu yapılandırma kaydedilip Claude Desktop yeniden başlatıldığında, arayüzün sağ alt köşesinde yer alan "çekiç" (Tools) ikonunda yeni araçların listelendiği görülür. Model, kullanıcı bir soru sorduğunda bu araçları otomatik olarak tespit eder, girdi parametrelerini hazırlar ve çalıştırma talebini yerel sunucunuza iletir.

Kurumsal İstemciler İçin Güvenli Dağıtım (Deployment) Kuralları

Kurumsal üretim ortamlarında yüzlerce çalışanın yerel bilgisayarlarında ayrı ayrı veritabanı sürücüleri veya Python bağımlılıkları çalıştırması sürdürülebilir değildir. Bu senaryoda MCP sunucuları Docker konteynerleri haline getirilerek merkezi bir Kubernetes kümesinde veya dahili bulut sunucularında barındırılmalıdır.

Merkezi dağıtımlarda dikkat edilmesi gereken kurallar şunlardır:

• Tersine Proxy (Reverse Proxy) ve mTLS: SSE tabanlı MCP sunucularının önüne NGINX veya Envoy gibi bir tersine proxy konulmalı; istemci ile sunucu arasındaki iletişim karşılıklı TLS (mTLS) ve API anahtarlarıyla şifrelenmelidir.

• Durumsuz (Stateless) Tasarım: MCP sunucuları oturum durumunu yerel bellekte tutmamalıdır. Bir istemcinin kopup yeniden bağlandığı senaryolarda SSE akışının sorunsuz devam edebilmesi için durum bilgisi Redis gibi harici bir önbelleğe aktarılmalıdır.

• Kaynak Kısıtlamaları: Konteyner düzeyinde CPU ve RAM sınırlandırmaları uygulanmalıdır. Kontrolsüz bir SQL sorgusu veya sonsuz döngüye giren bir script, tüm ana makine kaynaklarını tüketmemelidir.

MCP Sunucuları İçin Performans Optimize Etme ve İzleme (Monitoring)

MCP sunucuları, yapay zeka istemcilerinin karar alma döngüsünün tam ortasında yer alır. Yavaş çalışan bir sunucu veya gereksiz şişirilmiş veri yükleri (payloads), hem son kullanıcı deneyimini bozar (yüksek gecikme / latency) hem de LLM token faturalarını katlanarak artırır.

Kurumsal ölçekte başarılı bir MCP mimarisi oluşturmak, sadece kodun çalışmasını sağlamakla bitmez; sürekli telemetri takibi, bağlam (context) optimizasyonu ve sıkı hata yönetimi gerektirir.

Veri Yükü (Payload) Optimizasyonu ve Token Tüketim Kontrolü

Model Context Protocol sunucuları veriyi doğrudan LLM'in bağlam penceresine (Context Window) aktarır. Bir veritabanından dönen 10.000 satırlık ham JSON çıktısı, tek bir sorguda yüz binlerce token tüketebilir. Bu durum bağlam penceresinin taşmasına (Context Overflow), modelin dikkat dağınıklığına (Lost in the Middle problemi) ve aşırı maliyetlere yol açar.

Token optimizasyonu için uygulanması gereken temel teknikler:

• Zorunlu Sayfalama (Pagination): Kaynak ve araç çıktılarında varsayılan olarak limit ve offset parametreleri uygulanmalıdır. Model bir defada maksimum 20-50 kayıt alabilmeli, devamı için açıkça bir sonraki sayfayı talep etmelidir.

• Veri Formatı Seçimi (JSON yerine Markdown / CSV): Yapılandırılmış tablo verileri için JSON formatı fazla miktarda tırnak, parantez ve anahtar tekrarı içerir. Ham JSON yerine CSV veya Markdown tablo formatında metin döndürmek, token tüketiminde %30 ile %50 arasında tasarruf sağlayabilir.

• Özetleme Katmanı (Summarization on Server): Büyük metin belgeleri döndürülürken, metnin tamamı yerine sunucu tarafında yerel ve hafif bir modelle (veya algoritmik yöntemlerle) çıkarılmış bağlamsal özet döndürülmelidir.

Yanıt Gecikmelerini (Latency) Azaltma ve Hata Yönetimi

Bir yapay zeka ajanının karmaşık bir görevi tamamlamak için arka arkaya 5 farklı MCP aracını çağırması gerekebilir. Bu tür zincirleme senaryolarda (tool-chaining), her bir araç çağrısındaki 1-2 saniyelik gecikme kullanıcı tarafında 10-15 saniyelik bekleme sürelerine dönüşür.

Sistem gecikmesini düşürmek ve dayanıklılığı artırmak için:

• Önbellekleme (Caching): Değişmeyen veriler (örneğin statik API dokümantasyonları, şirket organizasyon şemaları veya sık erişilen kataloglar) Redis veya yerel bellek (in-memory cache) üzerinde TTL (Time to Live) süreleriyle önbelleğe alınmalıdır.

• Asenkron ve Eşzamanlı İşlemler: Sunucu mimarisinde bloklayıcı (blocking) I/O çağrılarından kaçınılmalı, asenkron veritabanı sürücüleri (asyncpg, prisma, aiofiles) kullanılmalıdır.

• Yapılandırılmış Hata Mesajları: Bir araç başarısız olduğunda genel bir "500 Internal Server Error" yerine, modelin anlayabileceği ve rota düzeltebileceği açıklayıcı hatalar döndürülmelidir (Örn: "Kullanıcı bulunamadı. Lütfen sorguladığınız e-posta formatını kontrol edip tekrar deneyin."). Bu yöntem, modelin hatayı anlayıp kullanıcıyı bilgilendirmesini veya alternatif bir parametre ile işlemi yeniden denemesini sağlar.