Blog

Uzak MCP sunucusu, yapay zeka istemcilerinin araçlara ve verilere yerel bir süreç üzerinden değil, HTTP üzerinden erişmesini sağlayan bir mimaridir. Model Context Protocol (MCP) tabanlı bir sunucuyu internete açmak istediğinizde iş üç temel adıma indirgenir: servisi bir konteyner içine paketlemek, HTTPS arkasında çalıştırmak ve herhangi bir istemci araç çağırmadan önce kimlik doğrulamasını zorunlu kılmak. Güncel taşıma katmanı Streamable HTTP olduğu için, küçük bir Node.js ya da Python servisi tek başına yeterli olur; kritik olan nokta bu servisin dış dünyaya açık, çok istemcili ve güvenli biçimde sunulmasıdır. Bu rehberde bir VPS hosting hizmeti üzerinde Docker, HTTPS ve kimlik doğrulama katmanlarını adım adım kuruyoruz.

Uzak MCP sunucusu nedir, yerel kurulumdan farkı ne?

MCP, yapay zeka modellerinin dış sistemlerdeki araçları, dosyaları ve veri kaynaklarını standart bir sözleşmeyle keşfetmesini sağlayan açık bir protokoldür. Protokolün ilk sürümlerinde yaygın kullanım biçimi, sunucunun istemciyle aynı makinede çalıştığı stdio taşımasıydı. Bu model hızlı prototipleme için pratiktir ancak birkaç ciddi sınırla gelir:

• Sunucu yalnızca onu başlatan istemciye hizmet eder; masaüstü uygulaması kapandığında araçlar da kaybolur.
• Her kullanıcı için ayrı kurulum, ayrı bağımlılık yönetimi ve ayrı sürüm takibi gerekir.
• Mobil istemciler, tarayıcı tabanlı ajanlar ve bulut üzerinde çalışan otomasyonlar yerel sürece erişemez.
• Kimlik doğrulama, hız sınırlama ve denetim kaydı gibi kurumsal gereksinimler büyük ölçüde devre dışı kalır.

Uzak MCP sunucusu bu tabloyu tersine çevirir: servis merkezi bir adreste çalışır, tüm istemciler aynı uç noktaya bağlanır ve yetkilendirme sunucu tarafında uygulanır. Streamable HTTP taşıması, tek bir uç nokta üzerinden hem klasik istek/yanıt akışını hem de sunucudan istemciye akan olay (streaming) yanıtlarını destekler. Bu da uzun süren araç çağrılarında bağlantının kopmadan ilerleme bilgisi gönderebilmesi anlamına gelir.

Ölçüt	Yerel (stdio) MCP	Uzak (Streamable HTTP) MCP
Erişim	Tek makine, tek istemci	Ağ üzerinden çok sayıda istemci
Kurulum	Her kullanıcıda tekrar edilir	Merkezi, tek seferlik
Kimlik doğrulama	Genellikle yok	Token, OAuth, kapsam tabanlı
Ölçekleme	Makine kaynaklarıyla sınırlı	Konteyner ve replika ile yatay ölçek
Denetim ve log	Sınırlı	Merkezi loglama ve izleme

Altyapı seçimi ve ön hazırlık

MCP sunucusu, konteyner çalıştırabilen herhangi bir sanal sunucuda barındırılabilir. Paylaşımlı hosting paketleri Docker ve serbest port yönetimi sunmadığı için bu senaryo için uygun değildir; kök erişimli bir VPS ya da daha yüksek kaynak ihtiyacı olan iş yükleri için VDS tercih edilir. Boyutlandırma yaparken şu kabaca değerler yol gösterici olur:

• Prototip ve tek kullanıcı: 2 vCPU, 2 GB RAM, 20 GB SSD yeterlidir.
• Küçük ekip (10-30 istemci): 2-4 vCPU, 4-8 GB RAM; ters proxy ve konteyner aynı makinede çalışabilir.
• Yoğun araç çağrısı veya paralel oturumlar: 4+ vCPU, 8+ GB RAM, ayrı veritabanı ve loglama bileşeni.

Kuruluma geçmeden önce elinizde şunlar olmalı: güncel bir Linux dağıtımı (Ubuntu LTS veya Debian kararlı sürüm), sunucunun statik IP adresi, bir alt alan adı (örneğin mcp.ornek.com) ve bu alt alan adı için domain kaydı tarafında tanımlanmış bir A/AAAA kaydı. DNS yayılımı tamamlanmadan TLS sertifikası almaya çalışmak, en sık karşılaşılan zaman kaybı nedenidir.

1. Adım: Sunucuyu Docker ile paketleme

MCP sunucusunu doğrudan ana makinede çalıştırmak yerine konteynere almak; sürüm sabitleme, geri alma kolaylığı ve süreç izolasyonu sağlar. Aşağıdaki örnek, Node.js tabanlı bir sunucuyu ayrıcalıksız bir kullanıcı altında çalıştıran minimal bir yapılandırmadır:

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN addgroup -S mcp && adduser -S mcp -G mcp
USER mcp
EXPOSE 8080
HEALTHCHECK CMD wget -qO- http://127.0.0.1:8080/health || exit 1
CMD ["node", "server.js"]

Servisi docker compose ile ayağa kaldırırken portu yalnızca yerel arayüze bağlamak, dış dünyaya açılan tek kapının ters proxy olmasını garantiler. Ek olarak kök dosya sistemini salt okunur hâle getirmek ve yetki yükseltmeyi engellemek iyi bir alışkanlıktır:

services:
  mcp:
    build: .
    restart: unless-stopped
    env_file: .env
    ports:
      - "127.0.0.1:8080:8080"
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true

Gizli anahtarları imajın içine gömmeyin. API anahtarları, veritabanı parolaları ve imzalama sırları .env dosyasında ya da harici bir sır yönetimi servisinde tutulmalı; imaj katmanlarında kalan bir sır, imajı çeken herkes tarafından okunabilir. Konteyner güvenliğinde en sık atlanan konulardan biri de budur; katmanların ve birimlerin beklenmedik biçimde veri sızdırması üzerine kaleme aldığımız konteyner veri sızıntısı analizi bu riskleri somut örneklerle anlatıyor.

2. Adım: HTTPS ve ters proxy yapılandırması

MCP istemcilerinin büyük bölümü yalnızca TLS üzerinden konuşur; sertifikası doğrulanamayan bir uç noktaya bağlanmayı reddeder. Bu nedenle TLS sonlandırmayı ters proxy katmanına taşımak hem yönetimi kolaylaştırır hem de uygulama kodunu sertifika yenileme mantığından kurtarır. Nginx kullanıyorsanız örnek blok şöyle görünür:

server {
    listen 443 ssl http2;
    server_name mcp.ornek.com;

    ssl_certificate     /etc/letsencrypt/live/mcp.ornek.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mcp.ornek.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 3600s;
        chunked_transfer_encoding on;
    }
}

Buradaki kritik satırlar proxy_buffering off ve uzun proxy_read_timeout değerleridir. Streamable HTTP akışı, sunucu yanıtı parça parça gönderirken proxy’nin yanıtı tamponlaması hâlinde kilitlenebilir. Ayrıca 80 numaralı portu kalıcı olarak 443’e yönlendirin, HSTS başlığını ekleyin ve ACME istemcisinin otomatik yenileme zamanlayıcısını mutlaka doğrulayın. Caddy gibi çözümler sertifika yönetimini kendiliğinden üstlendiği için tek sunuculu kurulumlarda daha az bakım gerektirebilir.

3. Adım: Kimlik doğrulama ve yetkilendirme

Uzak MCP sunucusunun en hassas bileşeni budur: araç çağrıları gerçek sistemlerde değişiklik yapabilir, dosya okuyabilir veya veritabanına yazabilir. Yetkilendirmeyi sonradan eklenen bir katman gibi değil, tasarımın parçası olarak düşünün.

Token tabanlı erişim

• Bearer token: Her istekte Authorization başlığında taşınan, sunucu tarafında doğrulanan bir anahtar. Basit kurulumlar için yeterlidir; anahtarları kullanıcı bazında üretin ve iptal edilebilir tutun.
• JWT doğrulama: İmza, iss, aud ve exp alanlarını eksiksiz kontrol edin. Yalnızca imzayı doğrulamak, süresi geçmiş veya başka bir servise verilmiş bir token’ı kabul etmek anlamına gelir.
• OAuth 2.1 akışı: Çok kullanıcılı ve üçüncü taraf istemcilerin bağlanacağı senaryolarda yetkilendirme sunucusu ile kaynak sunucusunu ayırın; erişim token’larını kısa ömürlü, yenileme token’larını döndürülebilir tutun.

Araç düzeyinde kapsam

Tek bir token’ın tüm araçlara erişmesi gereksiz risktir. Kapsam (scope) tanımlayarak örneğin yalnızca okuma araçlarına izin veren bir istemci ile yazma yetkisi olan bir ajanı ayırın. Sunucu tarafında her araç çağrısında kapsam denetimi yapın; istemcinin gönderdiği araç listesine güvenmeyin. Ayrıca istek hızını sınırlayın: yoğun bir ajan döngüsü, dakikada binlerce çağrı üreterek sunucuyu ve arka uçtaki servisleri kilitleyebilir.

Kimlik doğrulamayı bir web uygulaması güvenlik duvarı ile birlikte kullanmak, otomatik araç taraması ve anormal istek kalıplarını daha erken yakalamanızı sağlar. Yapay zeka destekli WAF kuralları ile imza tabanlı filtrelemeyi birleştiren yaklaşımlar burada da işe yarar.

Güvenlik sertleştirme kontrol listesi

• SSH için parola yerine anahtar kullanın, kök girişini kapatın ve standart dışı port tercih edin.
• Güvenlik duvarında yalnızca 22, 80 ve 443 portlarını açık bırakın; MCP uygulamasının portu dışarıya kapalı olsun.
• Konteynerleri ayrıcalıksız kullanıcı olarak çalıştırın, gereksiz Linux yeteneklerini (cap_drop: ALL) kaldırın.
• İmajları sabit sürüm etiketleriyle çekin ve düzenli olarak zafiyet taramasından geçirin.
• Çekirdek ve sistem paketlerini güncel tutun; TCP yığını gibi alt katmanlarda yayımlanan açıklar barındırma ortamını doğrudan etkiler.
• Tüm araç çağrılarını kimlik, zaman ve sonuç bilgisiyle loglayın; hassas alanları maskeleyin.
• Yedekleri şifreleyin ve geri yükleme adımını en az bir kez gerçekten test edin.

İzleme, güncelleme ve yedekleme

Bir MCP sunucusu iş üretmeye başladığında sessiz hatalar en büyük risktir. Sağlık uç noktası (/health) yalnızca sürecin ayakta olup olmadığını değil, bağımlı olduğu veritabanı ve dış servislere erişebildiğini de bildirmelidir. Ters proxy erişim kayıtlarını, konteyner çıktılarını ve uygulama düzeyi denetim kayıtlarını tek bir yerde toplayın; 5xx oranı, ortalama yanıt süresi ve araç başına hata sayısı için uyarı eşikleri tanımlayın.

Güncelleme stratejisi için mavi-yeşil ya da en azından iki aşamalı bir yaklaşım önerilir: yeni imajı ayrı bir konteynerde sağlık kontrolünden geçirin, ardından proxy yönlendirmesini değiştirin. Böylece protokol sürümü veya araç şeması değiştiğinde istemcilerin bağlantısı kesilmez. Yapılandırma dosyalarını, compose tanımlarını ve sır şablonlarını sürüm kontrolünde tutmak, felaket anında toparlanmayı dakikalara indirir.

Aynı sunucu üzerinde MCP dışında servisler de barındırıyorsanız kaynak paylaşımını baştan planlayın. Örneğin VPS üzerinde Supabase barındırırken dikkat edilmesi gereken bellek ve bağlantı limitleri, MCP konteynerinin de yanıt süresini doğrudan etkiler. Ayrı veritabanı konteynerleri, tek bir güçlü makineye yığmak yerine kaynakları net biçimde ayırmanızı sağlar.

Kullanım senaryoları ve pratik notlar

Uzak MCP sunucusunun en yaygın kullanımı, kurumsal sistemleri tek bir arayüz üzerinden yapay zeka ajanlarına açmaktır: CRM kayıtlarını okumak, destek biletlerini sınıflandırmak, içerik yönetim sistemindeki taslakları güncellemek gibi işler merkezi bir araç sunucusu üzerinden yürütülebilir. WordPress tabanlı sitelerde bu yaklaşımın nasıl uygulandığını WordPress MCP sunucuları yazımızda ayrıntılı olarak ele aldık. KOBİ ölçeğinde görev yükünün ajanlara devredilmesi de benzer bir mimariyi gerektirir: araçlar merkezi, erişim yetkilendirilmiş ve tüm çağrılar izlenebilir olmalıdır.

Son olarak protokolün evrimini takip edin. Taşıma katmanı ve yetkilendirme beklentileri zamanla değişebilir; istemci uyumluluğunu korumak için sunucunuzda sürüm müzakeresini destekleyin ve eski taşıma yöntemlerini kademeli olarak kapatın.

Sık yapılan hatalar

• Konteyner portunu doğrudan internete açmak ve ters proxy’yi atlamak.
• Proxy tamponlamasını kapatmayı unutmak; akış yanıtlarının askıda kalması.
• Kısa proxy_read_timeout değerleriyle uzun süren araç çağrılarını kesmek.
• Kimlik doğrulamayı yalnızca istemci tarafında uygulamak.
• Sırları imaj içine gömmek ve aynı token’ı tüm istemcilere dağıtmak.
• Sağlık kontrolü olmadığı için çöken konteynerin fark edilmemesi.

SSS

Uzak MCP sunucusu için paylaşımlı hosting kullanılabilir mi?

Genellikle hayır. Docker çalıştırma, serbest port yönetimi ve ters proxy yapılandırması gerektiği için kök erişimli bir sanal sunucu gerekir. Statik site ve blog gibi iş yükleri için sınırsız hosting paketleri yeterlidir; ancak MCP gibi sürekli çalışan, dış dünyaya açık ve yetkilendirme gerektiren servisler için VPS ya da VDS tercih edilmelidir.