VPS üzerinde MCP sunucusu nasıl kurulur?

Ne inşa ediyorsunuz

Tek bir VPS üzerinde iki adet çalışan MCP kurulumu. Birincisi, Claude Code tarafından bir alt süreç olarak başlatılan ve bir pipe üzerinden iletişim kuran, dosya sistemi veya veritabanı aracı olan bir stdio sunucusu. İkincisi ise systemd ve TLS destekli bir nginx reverse proxy arkasında uzun ömürlü bir ağ servisi olarak çalışan, işaret ettiğiniz herhangi bir MCP istemcisi tarafından erişilebilen uzak HTTP sunucusu. Her ikisinin kurulumu da oldukça küçüktür. Bu kılavuzun büyük bir kısmı, aslında sorun çıkaran iki konuya odaklanmaktadır: JSON-RPC akışını temiz tutmak ve kimlik doğrulaması yapılmamış bir araç uç noktasını asla genel internete açmamak.

MCP'nin gerçekte ne olduğu

Model Context Protocol; bir yapay zeka istemcisinin (Claude Code, Claude Desktop, VPS üzerinde Gemini CLI veya kendi yazdığınız bir betik), harici araçları çağırması ve harici kaynakları okuması için kullanılan standart bir yöntemdir. Modelin kendisi herhangi bir işlem çalıştırmaz. İstemciye talepte bulunur, istemci bir MCP sunucusu ile JSON-RPC 2.0 üzerinden haberleşir, sunucu aracı çalıştırır ve sonucu geri iletir. İnsanların agent harness dediklerinde kastettikleri şey bu istemcidir: modelin etrafındaki, araç listesini, izin denetimlerini ve oturum durumunu yöneten döngü; MCP ise bu yapının araç tarafını genişletmenizi sağlayan basit bir protokoldür. Tek bir protokol sayesinde, bir kez yazdığınız sunucu, MCP destekleyen tüm istemcilerle çalışır. Eğer bu ayrım sizin için yeniyse ve özellikle modelin bir araca başvurmaya nasıl karar verdiği konusu ilginizi çekiyorsa, bu sunuculardan birine gerçek kimlik bilgileri vermeden önce agent temellerine dair aşamalı bir yol haritası üzerinde bir saat vakit ayırmanız faydalı olacaktır.

İki tür taşıma yöntemi mevcuttur ve bu kılavuzun geri kalanı bu iki yöntem etrafında şekillenir:

• stdio. İstemci, sunucuyu bir alt süreç (child process) olarak başlatır ve standart girdi/çıktı (stdin/stdout) üzerinden satır sonu karakteriyle ayrılmış JSON-RPC mesajları alışverişi yapar. Ağ bağlantısı, port veya kimlik doğrulama yoktur; güven sınırı sürecin kendisidir. Neredeyse tüm yerel araçlar bu şekilde çalışır.
• Streamable HTTP (ve onun eski sürümü olan HTTP+SSE). Sunucu, sürekli çalışan bir web servisidir. İstemci HTTP üzerinden bağlanır ve sunucu, yanıtları Server-Sent Events (SSE) aracılığıyla akış olarak gönderebilir. Bir sunucuyu birden fazla istemciyle paylaşmak veya kalıcı olarak sunucuda çalışması gereken bir araç çalıştırmak istediğinizde bu yöntem kullanılır.

Araç tek bir makineye ve tek bir kullanıcıya aitse stdio yöntemini seçin. Paylaşılan bir servis ise HTTP yöntemini tercih edin.

Ön gereksinimler ve dikkat edilmesi gereken noktalar

root veya sudo yetkilerine sahip, temiz bir Ubuntu 24.04 KVM VPS kullandığınızı varsayıyoruz. Bunların dışında şunlar gereklidir:

• Sunucunun yazıldığı çalışma zamanı. Çoğu referans sunucu Node veya Python ile yazılmıştır. Ubuntu 24.04, Node 18 sürümüyle gelir; ancak güncel birçok MCP paketi Node 20 veya daha yeni bir sürüm gerektirir. Bu nedenle apt paketine güvenmek yerine NodeSource veya nvm üzerinden güncel bir LTS sürümü kurun. Python 3.12 halihazırda yüklüdür.
• Bir alan adı ve DNS A kaydı. Bu sadece uzak HTTP sunucusu için gereklidir; TLS, bu VPS'e yönlenen bir alan adına ihtiyaç duyar. stdio örneği için herhangi bir DNS kaydına gerek yoktur.
• 512 MB RAM fazlasıyla yeterlidir. MCP sunucuları hafif JSON-RPC süreçleridir; bellek kullanımı protokolün kendisinden değil, aracınızın etkileşime girdiği bileşenlerden (veritabanı sürücüsü, dosya önbelleği vb.) kaynaklanır.
• Spesifikasyon henüz yeni ve gelişmektedir. 2025-03-26 tarihli revizyon, HTTP+SSE yapısını Streamable HTTP ile değiştirmiş ve SSE'yi kullanımdan kaldırmıştır. SSE hala çalışmaktadır ve birçok sunucu bu yapıyı desteklemeye devam etmektedir; bu nedenle herhangi bir taşıma protokolü kısıtlamasını mutlak bir kural olarak değil, sunucunun sürüm notlarına göre tekrar kontrol edilmesi gereken bir yapılandırma olarak değerlendirin.

Adım 1: Bir stdio sunucusunu Claude Code'a bağlama

Dosya sistemi sunucusuyla başlayın; resmi, aktif olarak bakımı yapılan ve Node dışında hiçbir şeye ihtiyaç duymayan bir sunucudur. Aşağıdaki tek komut, sunucuyu Claude Code'a kaydeder ve mevcut proje ile sınırlandırarak işlenebilir (committable) bir dosyaya yazılmasını sağlar:

cd /home/matt/projects/api
claude mcp add --scope project --transport stdio filesystem \
  -- npx -y @modelcontextprotocol/server-filesystem /home/matt/projects/api

-- ayırıcısı önemlidir: bu ifadeden sonra gelen her şey Claude Code'un çalıştıracağı komuttur, Claude Code'un bir bayrağı değildir. Bu işlem, proje kök dizininde bir .mcp.json oluşturur:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/home/matt/projects/api"
      ]
    }
  }
}

Henüz hiçbir şey çalışmıyor. Bu dizinde Claude Code'u bir sonraki başlatışınızda, aracı .mcp.json dosyasını okur, npx -y @modelcontextprotocol/server-filesystem ... sürecini bir alt süreç olarak başlatır ve bu sürecin stdin/stdout kanalları üzerinden MCP el sıkışmasını gerçekleştirir. Bağlantının kurulduğunu doğrulayın:

claude mcp list

Sağlıklı bir sunucu, kendi komutunu ve yeşil bir onay işareti olan filesystem: npx -y @modelcontextprotocol/server-filesystem ... - ✓ Connected ifadesini yazdırır. Oturum içinde, /mcp eğik çizgi komutu sunucunun sunduğu araçları listeler (read_file, write_file, list_directory) ve aracı artık bu araçları izin verdiğiniz yollar üzerinde kullanabilir. Bir veritabanı aracı da aynı yapıdadır; paketi değiştirin ve son argüman olarak bir bağlantı dizgisi (connection string) geçin. Ancak, referans Postgres sunucusu birden fazla kez el değiştirdiği için güncel paket adı konusunda sunucunun kendi deposunu kontrol edin.

Aracıyı sunucu üzerinde çalıştırmanın temel amacı budur: Claude Code oturumu VPS üzerinde tmux içinde yaşar ve stdio sunucuları, ağ üzerinden gidiş-dönüş süresi olmaksızın, proje dosyalarına ve yerel servislere doğrudan erişimle hemen yanında çalışır. Aracı hem write_file hem de read_file yetkilerine sahip olduğunda, bu erişimi çalışan en küçük değişikliğe odaklanan bir beceri ile eşleştirmek faydalıdır; çünkü bir dosya sistemi aracı, kapsamlı bir yeniden yazımı iki satırlık bir düzeltme kadar kolay hale getirir. Aynı bağlantı mantığı yerel dosyaların ötesine de uzanır: VPS üzerinde halihazırda bir arama motoru çalıştırıyorsanız, kendi SearXNG örneğinizi bir arama aracı olarak aracıya verebilirsiniz. Bu, sorguları kendi sunucunuzda tutar ancak güvenilmeyen sayfa metinlerini doğrudan aracının üzerinde işlem yapacağı bağlama çeker.

Adım 2: Uzak bir HTTP sunucusu oluşturma

Bir stdio sunucusu, üst süreci kapandığında sonlanır ve her istemci için ayrı ayrı başlatılır. Bu nedenle, sunucu üzerinde birbirine iş devreden iki Claude Code oturumu çalıştırırsanız, her biri aracın kendi özel kopyasına sahip olur. Her istemci için sürekli çalışan bir araca, paylaşılan bir operasyon aracına, veritabanı ağ geçidine veya hem dizüstü bilgisayarınızın hem de CI sisteminizin çağırabileceği bir yapıya ihtiyaç duyduğunuzda, HTTP taşıma katmanına ve gerçek bir servise gereksinim duyarsınız. İşte resmi SDK kullanılarak tek bir aracı dışa aktaran minimal bir Python sunucusu:

# /opt/mcp-ops/server.py
from mcp.server.fastmcp import FastMCP
import subprocess

mcp = FastMCP("ops-tools", host="127.0.0.1", port=8000)

@mcp.tool()
def disk_free() -> str:
    """Return `df -h` for the server."""
    out = subprocess.run(["df", "-h"], capture_output=True, text=True)
    return out.stdout

if __name__ == "__main__":
    # Serves Streamable HTTP at /mcp on 127.0.0.1:8000
    mcp.run(transport="streamable-http")

Not: host="127.0.0.1". Sunucu yalnızca localhost üzerinde dinleme yapar; kimlik doğrulama mekanizması kurulmadan önce dışarıdan doğrudan erişilememesi tam olarak istenen durumdur. systemd'nin kararlı bir yorumlayıcı yoluna sahip olması için sunucuyu kendi virtualenv ortamına kurun:

sudo useradd --system --home /opt/mcp-ops --shell /usr/sbin/nologin mcp
sudo install -d -o mcp -g mcp /opt/mcp-ops
sudo -H -u mcp python3 -m venv /opt/mcp-ops/.venv
sudo -H -u mcp /opt/mcp-ops/.venv/bin/pip install "mcp[cli]"

Adım 3: systemd ile ayakta tutma

Aracı (agent) ihtiyaç duyduğunda çalışmayan bir araç, hiç olmamasından daha kötüdür. İstemcinin kendisi uzun ömürlü bir süreç olduğunda bu durum daha da kritikleşir: belleğini koruyan ve yeniden başlatmalar arasında zamanlama yapan sürekli çalışan bir aracı, başında kimse yokken bu araçları belirli bir takvimde çağıracaktır; bu nedenle sunucunun da kendi kendine ayağa kalkması gerekir. /etc/systemd/system/mcp-ops.service dosyasını oluşturun:

[Unit]
Description=MCP ops-tools server
After=network.target

[Service]
Type=simple
User=mcp
WorkingDirectory=/opt/mcp-ops
ExecStart=/opt/mcp-ops/.venv/bin/python /opt/mcp-ops/server.py
Restart=on-failure
RestartSec=2
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true

[Install]
WantedBy=multi-user.target

ExecStart içindeki venv Python yolunun mutlak olması zorunludur; yolu /usr/bin/python3 konumuna işaret edin. Süreç ModuleNotFoundError: No module named 'mcp' ile başlar, çünkü sistem yorumlayıcısı pip install dosyanızı görmez. Servisi etkinleştirin ve kontrol edin:

sudo systemctl daemon-reload
sudo systemctl enable --now mcp-ops
sudo systemctl status mcp-ops
curl -si -H 'Accept: application/json, text/event-stream' \
  -H 'Content-Type: application/json' \
  -X POST http://127.0.0.1:8000/mcp

status çıktısı active (running) değerini göstermelidir. curl, gövdesinde bir JSON-RPC hatası ile HTTP/1.1 400 Bad Request yanıtını döndürür. İstek herhangi bir oturum veya geçerli bir JSON yükü taşımamaktadır; tam olarak istenen durum budur: bu, portun yanıt verdiğini ve protokolü konuştuğunu kanıtlar. Connection refused veya boş bir yanıt, sürecin düşündüğünüz yere bağlı olmadığını gösterir; journalctl -u mcp-ops -n 50 dosyasını inceleyin.

Adım 4: TLS ve reverse proxy kurulumu

Sunucu localhost üzerinde dinleme yapar. Dışarıdan erişim sağlamak için TLS sonlandırmasını nginx üzerinde yapmalı ve trafiği içeriye yönlendirmelisiniz. nginx kurulumunu yapın, nginx üzerinde Certbot ve Let's Encrypt kullanarak bir sertifika alın ve ardından location bloğunu yazın. Kritik nokta, tampon belleği (buffering) devre dışı bırakmaktır; çünkü nginx'in varsayılan davranışı yanıt tamamlanana kadar bekletmektir ve bu durum SSE akışını kalıcı olarak durdurur:

server {
    listen 443 ssl;
    server_name mcp.example.com;

    # ssl_certificate lines managed by Certbot

    location /mcp {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;

        # The four lines that make SSE work through nginx:
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 3600s;
        chunked_transfer_encoding off;
    }
}

sudo nginx -t && sudo systemctl reload nginx komutu ile yeniden yükleyin. Eğer halihazırda bir container filosu çalıştırıyorsanız, aynı işlem otomatik TLS özellikli Traefik reverse proxy tarafından sizin yerinize yapılır; bu araç sertifikayı oluşturur ve ana bilgisayar adına göre yönlendirme yapar, sizin ise sadece MCP container'ına etiketleri eklemeniz yeterlidir. Her iki durumda da reverse proxy artık genel port üzerindeki tek bileşendir ve henüz güvenliğini sağlamadığınız bir servise işaret etmektedir. URL'yi herhangi bir yerde kaydettirmeden önce bu güvenlik açığını giderin.

Adım 5: Bu konuyu domine eden güvenlik kuralı

Kimlik doğrulaması yapılmamış bir MCP uç noktasını asla dış dünyaya açmayın. Bir MCP sunucusu salt okunur bir API değildir. Araç erişimi sağlar; dosyalarınıza, veritabanınıza ve bazen bir kabuğa (shell) erişim yetkisi verir. Genel internete açık bir /mcp, yapay zeka temsilcinizle aynı yetkilere sahip bir yabancıdır: araçlarınızı listeler ve ardından onları çalıştırır. Buna kimlik doğrulaması olmayan bir yönetici soketi gibi davranın, çünkü gerçekte olan budur. Çalınan bir token'ın size ne kadara mal olacağı, arkasındaki sunucuya da bağlıdır: openGym antrenman takip uygulamasıyla birlikte gelen salt okunur MCP sunucusu yalnızca eğitim verilerini geri verebilirken, bir dosya sistemi veya kabuk aracı tüm sunucunun kontrolünü ele geçirmenize olanak tanır.

Tercih sırasına göre üç savunma yöntemi:

1. Yayınlamayın. Sunucuyu 127.0.0.1 üzerinde tutun ve dizüstü bilgisayarınızdan bir SSH tüneli ile erişin: ssh -L 8000:127.0.0.1:8000 matt@vps, ardından istemciyi http://127.0.0.1:8000/mcp adresine yönlendirin. Hiçbir şey dış dünyaya açılmaz.
2. Özel bir ağa yerleştirin. Bir self-hosted WireGuard VPN tünel adresine bağlayın ve yalnızca VPN eşlerinin erişmesine izin verin. Genel internet, kapalı bir port görür.
3. Eğer halka açık olması gerekiyorsa, bir token zorunlu tutun. Doğru çözüm, HTTP taşıyıcısının yerel olarak desteklediği MCP OAuth akışıdır. Pratik minimum çözüm ise proxy katmanında kontrol edilen paylaşımlı bir bearer token kullanmaktır; bu yöntem ucuzdur ve rastgele saldırıları tamamen durdurur:

location /mcp {
    if ($http_authorization != "Bearer REPLACE_WITH_LONG_RANDOM") {
        return 401;
    }
    proxy_pass http://127.0.0.1:8000;
    # ...buffering-off block from above...
}

Token'ı openssl rand -hex 32 ile oluşturun ve yukarıdakilerden biri olmadan sunucuyu asla 0.0.0.0 adresine bağlamayın. İstemci, token'ı bir başlık (header) olarak gönderir. Claude Code içinde:

claude mcp add --scope project --transport http ops-tools https://mcp.example.com/mcp \
  --header 'Authorization: Bearer ${MCP_TOKEN}'

MCP_TOKEN değerini kabuğunuzda ayarlayın, böylece gizli anahtar .mcp.json dosyasına düz metin olarak yazılmaz. Claude Code, ${MCP_TOKEN} değişkenini okuma sırasında ortamdan genişletir.

Yukarıdaki her savunma yöntemi, token'ı zaten elinde bulunduran temsilciden ziyade uç noktayı korur. Sorunun diğer yarısı ise şudur: Eğer istemciniz DeepSeek Harness ise, temsilcinin hangi araçları çağırabileceğini sınırlayan ve araç çıktılarını enjekte edilmiş komutlar için tarayan eklentiler bu tarafı kapsar.

Adım 6: MCP Inspector ile hata ayıklama

Bir sunucu düzgün çalışmadığında, tahmin yürütmek yerine resmi web tabanlı test istemcisi olan Inspector ile doğrudan müdahale edin. Stdio tabanlı bir sunucu için, aracıya (agent) verdiğiniz komutun aynısını kullanın:

npx @modelcontextprotocol/inspector \
  npx -y @modelcontextprotocol/server-filesystem /tmp

Bu işlem http://localhost:6274 üzerinde bir arayüz başlatır (güncel sürümler MCP_PROXY_AUTH_TOKEN sorgu dizisi içeren bir URL yazdırır; arayüzün reddetmemesi için bu bağlantıyı tam olarak kullanın) ve 6277 portunda bir proxy oluşturur. Connect butonuna, ardından List Tools seçeneğine tıklayın ve gerçek argümanlarla Call Tool işlemini gerçekleştirin. Eğer sunucu Inspector üzerinde çalışıyor ancak aracıda hata veriyorsa, sorun sunucuda değil, istemci yapılandırmasındadır. Uzak HTTP sunucusu için Streamable HTTP taşıma yöntemini seçin, https://mcp.example.com/mcp adresini girin, Authorization başlığını ekleyin ve bağlanın; bu yöntem, herhangi bir aracı devreye girmeden önce kimlik doğrulama ve proxy ayarlarının doğruluğunu kanıtlamanın en hızlı yoludur.

Sunucuları güncel tutma

MCP hızla gelişmektedir, bu nedenle yamaları bir takvime göre uygulayın. npx -y ile başlatılan Node sunucuları, her oluşturulma anında en güncel sürümü çeker; bu yöntem pratik olsa da tekrarlanabilir değildir. Bir sunucu önem kazandığında, test ettiğiniz sürümü sabitleyin; sürüm numarasını npm view @modelcontextprotocol/server-filesystem version dosyasından okuyun ve .mcp.json içindeki paket adına ekleyin (@modelcontextprotocol/server-filesystem@<version>), ardından güncellemeleri bilinçli olarak yapın. systemd altında çalışan Python sunucuları, sudo -H -u mcp /opt/mcp-ops/.venv/bin/pip install -U "mcp[cli]" ve ardından sudo systemctl restart mcp-ops komutlarıyla güncellenir. Yükseltme yaparken SDK'nızın hedeflediği spesifikasyon revizyonunu takip edin; SSE'den Streamable-HTTP sınırına geçiş, istemcilerinizin talep etmesi gereken taşıma protokolünü değiştirebilir.

Hata modları ve karşılaşacağınız dizeler

Aracı sunucunun başarısız olduğunu gösteriyor. claude mcp list, ✗ Failed to connect çıktısını verir ve TUI üzerinde MCP server 'filesystem' failed to start raporlanır. claude --debug komutunu çalıştırdığınızda genellikle Error: spawn npx ENOENT ifadesini görürsünüz; bu, komutun aracın PATH dizininde bulunmadığı anlamına gelir. Çalışma zamanı (runtime) eksiktir veya aracın aradığı konumda değildir: Node yüklü değildir, npx mevcut değildir veya doğrudan adıyla çağrılan bir virtualenv Python ortamı bulunamamıştır. Komutu mutlak yol (absolute path) ile güncelleyin veya çalışma zamanını yükleyip yeniden bağlanın.

Bir stdio sunucusu bağlanıyor ancak hemen ardından bağlantıyı kesiyor. İstemci günlüklerinde Unexpected token 'S', "Server sta"... is not valid JSON veya Failed to parse message gibi bir JSON ayrıştırma hatası görünür. Bunun nedeni her zaman aynıdır: sunucu stdout kanalına bir günlük satırı yazmıştır. Stdio üzerinde stdout, JSON-RPC kanalıdır; bu nedenle buraya yazılan herhangi bir metin akışı bozar ve el sıkışma (handshake) başarısız olur. Node ortamında console.log doğrudan stdout'a yazar, bunun yerine console.error kullanın. Python'da ise doğrudan print() kullanımı stdout'a çıktı verir; günlükleri sys.stderr olarak yapılandırılmış logging ile yazın veya file=sys.stderr parametresini kullanın. Kural kesindir: stdio üzerinde stdout'ta yalnızca JSON-RPC verisi bulunmalı, insan tarafından okunabilir tüm çıktılar stderr'e yönlendirilmelidir.

Uzak sunucu zaman aşımına uğruyor veya el sıkışma sırasında bağlantıyı kapatıyor. İstemci MCP error -32000: Connection closed hatası verir veya Inspector Connect aşamasında takılıp araçları listelemez. Nginx arkasındaki bu durum bir tamponlama (buffering) sorunudur: proxy, SSE akışını anlık iletmek yerine tutar, bu yüzden istemci asla gelmeyecek bir yanıtı bekler. proxy_buffering off; ayarını (ve 4. Adımdaki bloğun geri kalanını) location dosyasına ekleyin. Genel URL üzerinde curl -N ile doğrulama yapın; olay verilerinin sonunda değil, kademeli olarak ulaştığını görmelisiniz.

Kimlik doğrulama reddediliyor. İstemci Error POSTing to endpoint (HTTP 401) veya doğrudan 401 Unauthorized hatası bildirir. Başlık eksik olabilir, token hatalı olabilir veya istemci yapılandırmayı okuduğu sırada kabuk değişkeni boş olabilir. Bu yaygın bir tuzaktır; çünkü ${MCP_TOKEN}, değişken tanımlanmamışsa boş bir değer döndürür ve Nginx bu durumda Bearer değerini boş görür. Değişkeni echo ile kontrol edin, başlığı yeniden ekleyin ve baytların Nginx if dosyasındaki token ile tam olarak eşleştiğini doğrulayın.

Servis systemd altında başlamıyor. journalctl -u mcp-ops komutu ModuleNotFoundError: No module named 'mcp' çıktısını verir; ExecStart, venv yorumlayıcısı yerine sistem Python'ını işaret ediyor olabilir. Veya Address already in use hatası alıyorsanız, başka bir süreç 8000 numaralı portu kullanıyordur; bu süreci sudo ss -ltnp | grep 8000 ile bulun.

FAQ

MCP sunucusu tam olarak nedir?

Model Context Protocol üzerinden bir yapay zeka istemcisine araçlar ve kaynaklar sunan, JSON-RPC 2.0 kullanan bir programdır. Yapay zeka modeli aracı kendisi çalıştırmaz; istemcisinden talep eder, istemci MCP sunucusunu çağırır, sunucu ise işlemi gerçekleştirip sonucu döndürür. Protokol standart olduğu için, tek bir sunucu; Claude Code, Claude Desktop veya Gemini CLI gibi uyumlu olan tüm istemcilerle çalışır.

stdio ve HTTP aktarımı arasındaki fark nedir?

Bir stdio sunucusu, istemci tarafından bir alt süreç (child process) olarak başlatılır ve stdin/stdout üzerinden iletişim kurar; bu nedenle tek bir makinede tek bir istemciyle yaşar ve ölür, ağ veya kimlik doğrulamasına ihtiyaç duymaz. HTTP sunucusu ise birçok istemcinin aynı anda erişebildiği, uzun süre çalışan bir ağ servisidir; bu yüzden TLS ve kimlik doğrulaması gerektirir. Yerel, tek kullanıcılı araçlar için stdio; paylaşılan veya kalıcı olan her şey için HTTP (mevcut sunucularda Streamable HTTP) kullanın.

Uzak bir MCP sunucusunu nasıl güvenli hale getiririm?

Sunucunun dosyalarınıza, veritabanınıza veya kabuğunuza araç erişimi sağladığını varsayın ve asla kimlik doğrulaması olmadan dış dünyaya açmayın. En iyi yöntem, sunucuyu localhost üzerinde tutmak ve bir SSH tüneli veya özel bir VPN üzerinden erişmektir; eğer herkese açık olması gerekiyorsa, bir bearer token veya MCP OAuth akışını zorunlu kılan bir reverse proxy arkasına yerleştirin. Token'ı openssl rand -hex 32 ile oluşturun ve önünde bu güvenlik önlemlerinden biri olmadan sunucuyu asla 0.0.0.0 adresine bağlamayın.

Başlamayan bir sunucuda hata ayıklamasını nasıl yaparım?

Öncelikle claude mcp list ve ✗ Failed to connect değerlerini kontrol edin; spawn ... ENOENT hatası, komutun veya çalışma zamanının eksik olduğu anlamına gelir, bu yüzden yolu düzeltin veya kurulumu yapın. Eğer bağlantı kuruluyor ancak JSON ayrıştırma hatasıyla düşüyorsa, sunucu stdout'a log yazıyor ve JSON-RPC akışını bozuyor demektir; tüm loglama işlemlerini stderr'e yönlendirin. Diğer tüm durumlar için, sunucuyu izole bir şekilde çalıştıran MCP Inspector altında tam komutu çalıştırın; böylece sunucu hatası ile istemci yapılandırma hatasını birbirinden ayırt edebilirsiniz.