מאת Matt Connor 2026-07-15 · עודכן 2026-08-31

הרצת שרתי MCP על גבי VPS: מדריך מעשי

Q: כיצד מנפים שגיאות בשרת שאינו עולה?

ראשית, בדקו את claude mcp list. אם ✗ Failed to connect מציג שגיאה עם spawn ... ENOENT, המשמעות היא שהפקודה או סביבת הריצה חסרות, לכן תקנו את ה-path או התקינו אותן. אם השרת מתחבר אך מתנתק עם שגיאת JSON parse, ייתכן שהשרת כותב לוגים ל-stdout ומשבש את זרם ה-JSON-RPC; העבירו את כל הלוגים ל-stderr. לכל בעיה אחרת, הריצו את הפקודה המדויקת תחת ה-MCP Inspector, שמפעיל את השרת בסביבה מבודדת, כך שתוכלו להבחין בין באג בשרת לבין בעיית תצורה בלקוח.

למדו כיצד להריץ שרתי MCP בתצורת stdio ו-remote HTTP על שרת VPS. המדריך מפרט הגדרות systemd, אבטחת TLS, אימות משתמשים ומניעת חשיפת נקודות קצה ללא הרשאה ב-JSON-RPC.

מה אתם בונים

שתי תצורות MCP פעילות על שרת VPS יחיד. הראשונה היא שרת stdio, כלי למערכת קבצים או למסד נתונים ש־Claude Code מפעיל כתהליך בן (child process) ומתקשר איתו דרך צינור (pipe). השנייה היא שרת remote HTTP שרץ כשירות רשת קבוע ברקע תחת systemd ו־nginx כ־reverse proxy עם TLS, וניתן לגישה מכל לקוח MCP שתגדירו. ההתקנה של כל אחת מהן מצומצמת. רוב המדריך הזה מתמקד בשני האתגרים המורכבים באמת: שמירה על תקינות זרם ה־JSON-RPC, והימנעות מוחלטת מחשיפת נקודת קצה (endpoint) של כלי ללא אימות לאינטרנט הציבורי.

מהו MCP בפועל

Model Context Protocol הוא תקן המאפשר ללקוח AI, כגון Claude Code, Claude Desktop, ה-Gemini CLI על גבי VPS, או סקריפט משלכם, לקרוא למשאבים חיצוניים ולהפעיל כלים חיצוניים. המודל עצמו אינו מריץ דבר. הוא פונה ללקוח, הלקוח מתקשר ב-JSON-RPC 2.0 מול שרת MCP, והשרת מריץ את הכלי ומחזיר את התוצאה. הלקוח הזה הוא הרכיב שאליו מתכוונים כשמדברים על agent harness: הלולאה שעוטפת את המודל ומנהלת את רשימת הכלים, בדיקות ההרשאות ומצב הסשן; MCP הוא פשוט הדרך להרחיב את רכיב הכלים. מדובר בתקן אחד, כך ששרת שתכתבו פעם אחת יעבוד מול כל לקוח התומך ב-MCP. אם ההפרדה הזו חדשה לכם, ובמיוחד השאלה כיצד מודל מחליט מתי להשתמש בכלי, כדאי להקדיש שעה ל-מסלול מדורג ביסודות הסוכנים לפני שתעניקו לאחד השרתים האלו הרשאות גישה אמיתיות.

קיימים שני ערוצי תעבורה (transports), וכל המשך המדריך הזה מחולק לפיהם:

stdio. הלקוח מפעיל את השרת כתהליך בן (child process) ומחליף הודעות JSON-RPC מופרדות בשורות חדשות דרך ה-standard input וה-standard output שלו. אין רשת, אין פורט, אין אימות; גבול האמון הוא התהליך עצמו. כמעט כל כלי מקומי פועל בשיטה זו.
Streamable HTTP (והגרסה הישנה שלו, HTTP+SSE). השרת הוא שירות אינטרנט שרץ באופן קבוע. הלקוח מתחבר דרך HTTP והשרת יכול להזרים תגובות בחזרה כ-Server-Sent Events. כך משתפים שרת אחד בין לקוחות רבים, או מריצים כלי שחייב להיות פעיל בשרת באופן קבוע.

בחרו ב-stdio כאשר הכלי שייך למכונה אחת ולמשתמש אחד. בחרו ב-HTTP כאשר מדובר בשירות משותף.

דרישות קדם ומלכודות נפוצות

הניחו כי ברשותכם שרת VPS מסוג KVM עם Ubuntu 24.04 וגישת root או sudo. מעבר לכך:

סביבת הרצה (runtime) עבור השרת. רוב שרתי הייחוס כתובים ב-Node או ב-Python. הגרסה שמגיעה עם Ubuntu 24.04 היא Node 18, אך חבילות MCP רבות דורשות כיום Node 20 ומעלה. לכן, התקינו גרסת LTS עדכנית מ-NodeSource או מ-nvm במקום להסתמך על apt. גרסה Python 3.12 כבר מותקנת כברירת מחדל.
שם מתחם (domain) ורשומת DNS מסוג A, אך רק עבור שרת ה-HTTP המרוחק; TLS מחייב שם שמתרגם לכתובת ה-IP של ה-VPS. דוגמת ה-stdio אינה דורשת DNS כלל.
512 MB RAM הם די והותר. שרתי MCP הם תהליכי JSON-RPC רזים; צריכת הזיכרון תלויה במה שהכלי שלכם ניגש אליו (מנהל מסד נתונים, מטמון קבצים), ולא בפרוטוקול עצמו.
המפרט צעיר ומשתנה. גרסת ה-2025-03-26 החליפה את HTTP+SSE ב-Streamable HTTP והגדירה את SSE כטכנולוגיה מיושנת (deprecated). עם זאת, SSE עדיין עובד ושרתים רבים עדיין תומכים בו, לכן התייחסו לכל הגדרת transport כאל נתון שיש לאמת מול הערות השחרור (release notes) של השרת, ולא כאל אמת מוחלטת.

שלב 1: חיבור שרת stdio לתוך Claude Code

התחילו עם שרת מערכת הקבצים; הוא רשמי, מתוחזק באופן פעיל ואינו דורש דבר מלבד Node. הפקודה הבאה רושמת אותו ב-Claude Code ומגבילה אותו לפרויקט הנוכחי, כך שהוא נשמר בקובץ שניתן לבצע לו commit:

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

למפריד -- יש חשיבות: כל מה שמופיע אחריו הוא הפקודה ש-Claude Code יריץ, ולא flag עבור Claude Code עצמו. פעולה זו כותבת .mcp.json בשורש הפרויקט:

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

כרגע לא רץ דבר. בפעם הבאה שתפעילו את Claude Code בספרייה זו, הסוכן יקרא את .mcp.json, יפעיל את npx -y @modelcontextprotocol/server-filesystem ... כתהליך בן (child process), ויבצע את ה-handshake של MCP דרך ה-stdin/stdout של אותו תהליך. ודאו שהחיבור הצליח:

claude mcp list

שרת תקין מדפיס את הפקודה שלו ואת סימן ה-V הירוק, filesystem: npx -y @modelcontextprotocol/server-filesystem ... - ✓ Connected. בתוך הסשן, פקודת ה-slash‏ /mcp מציגה את הכלים שהשרת חושף (read_file, write_file, list_directory), והסוכן יכול כעת להפעיל אותם על הנתיבים שהרשיתם. כלי מסד נתונים פועל באותו אופן; החליפו את החבילה והעבירו מחרוזת התחברות כארגומנט האחרון, אך בדקו במאגר (repository) של השרת מהו שם החבילה העדכני, שכן שרת ה-Postgres הרשמי החליף ידיים יותר מפעם אחת.

זוהי כל המהות של הרצת הסוכן על השרת: סשן Claude Code חי על ה-VPS בתוך tmux, ושרתי ה-stdio שלו רצים ממש לצידו עם גישה ישירה לקובצי הפרויקט ולשירותים המקומיים, ללא צורך ב-round-trip ברשת. ברגע שהסוכן מחזיק ב-write_file וגם ב-read_file, כדאי לשלב את הטווח הזה עם מיומנות שמכוונת אותו לשינוי הקטן ביותר שעובד, כיוון שכלי מערכת קבצים הופך שכתוב נרחב לקל בדיוק כמו תיקון של שתי שורות. החיבור הזה מתרחב מעבר לקבצים מקומיים: אם אתם כבר מריצים מנוע חיפוש על ה-VPS, אתם יכולים להעניק לסוכן את מופע ה-SearXNG שלכם ככלי חיפוש, מה ששומר את השאילתות על השרת שלכם אך מושך טקסט של דפים לא מהימנים ישירות לתוך ההקשר (context) שהסוכן פועל לפיו.

שלב 2: בניית שרת HTTP מרוחק

שרת stdio מסיים את פעולתו יחד עם תהליך האב שלו, והוא נוצר מחדש עבור כל לקוח. לכן, אם תריצו שתי סשנים של Claude Code על אותו שרת שמעבירים עבודה זה לזה, כל אחד מהם יקבל עותק פרטי משלו של הכלי. כאשר דרוש לכם כלי שנותר פעיל עבור כל לקוח — כלי תפעולי משותף, שער למסד נתונים, או כל שירות שגם המחשב הנייד שלכם וגם מערכת ה-CI שלכם פונים אליו — עליכם להשתמש ב-HTTP transport ובשירות של ממש. להלן שרת Python מינימלי המשתמש ב-SDK הרשמי וחושף כלי אחד:

# /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")

שימו לב ל-host="127.0.0.1". השרת מאזין ל-localhost בלבד; שום גורם מחוץ לשרת לא יכול להגיע אליו ישירות, וזה בדיוק המצב הרצוי כל עוד לא הוגדרה אימות (auth). התקינו אותו בתוך virtualenv משלו כדי להבטיח של-systemd יהיה נתיב יציב למפרש (interpreter):

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]"

שלב 3: שמירה על פעילות באמצעות systemd

כלי שאינו זמין כאשר הסוכן פונה אליו גרוע מכלי שאינו קיים כלל. הדבר קריטי במיוחד כאשר הלקוח עצמו הוא תהליך ארוך-טווח: סוכן הפועל תמיד ושומר על הזיכרון והתזמון שלו גם לאחר אתחול יקרא לכלים אלו לפי לוח זמנים ללא השגחה אנושית, לכן השרת חייב לחזור לפעילות באופן עצמאי. צרו את /etc/systemd/system/mcp-ops.service:

[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

הנתיב המלא ל-Python בתוך ה-venv ב-ExecStart אינו אופציונלי; הצביעו על /usr/bin/python3 והתהליך יתחיל עם ModuleNotFoundError: No module named 'mcp', כיוון שה-interpreter של המערכת מעולם לא הכיר את ה-pip install שלכם. הפעילו ובדקו:

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 צריך להיות active (running). ה-curl יחזיר HTTP/1.1 400 Bad Request עם שגיאת JSON-RPC בגוף התגובה; הבקשה לא הכילה session או payload תקין בפורמט JSON, וזה בדיוק מה שאתם רוצים: זה מוכיח שהפורט מגיב ודובר את הפרוטוקול. Connection refused או תגובה ריקה משמעותם שהתהליך אינו מאזין בכתובת שחשבתם; קראו את journalctl -u mcp-ops -n 50.

שלב 4: הגדרת TLS ו-reverse proxy בחזית

השרת מאזין ב-localhost. כדי לגשת אליו מכל מקום, יש לבצע TLS termination ב-nginx ולבצע proxy פנימה. התקינו את nginx, השיגו תעודה באמצעות Certbot ו-Let's Encrypt ב-nginx, ולאחר מכן כתבו את בלוק ה-location. החלק הקריטי הוא ביטול ה-buffering, כיוון שברירת המחדל של nginx היא להמתין לסיום התגובה, מה שגורם לעצירה ממושכת של זרם SSE:

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. אם אתם כבר מריצים צי של מכולות, אותה משימה תתבצע עבורכם על ידי Traefik reverse proxy עם TLS אוטומטי; הוא מנפיק את התעודה ומנתב לפי שם מתחם, ואתם רק צריכים להוסיף תוויות (labels) למכולת ה-MCP. כך או כך, ה-reverse proxy הוא כעת הרכיב היחיד בפורט ציבורי, והוא מצביע על שירות שטרם אובטח. בצעו זאת לפני רישום ה-URL בכל מקום.

שלב 5: כלל האבטחה המכריע בנושא זה

לעולם אל תחשפו נקודת קצה של MCP ללא אימות. שרת MCP אינו API לקריאה בלבד. הוא מעניק גישה לכלים, לקבצים שלכם, למסד הנתונים שלכם, ולעיתים גם ל-shell. שרת /mcp פתוח באינטרנט הציבורי הוא זר בעל הרשאות זהות לאלו של סוכן ה-AI שלכם: הוא יכול להציג את רשימת הכלים שלכם, ואז להפעיל אותם. התייחסו אליו בדיוק כמו אל socket ניהולי ללא אימות, כי זה בדיוק מה שהוא. הנזק שעלול להיגרם מגניבת אסימון (token) תלוי גם בשרת שמאחוריו: שרת ה-MCP לקריאה בלבד שמגיע עם כלי המעקב openGym יכול לכל היותר להחזיר נתוני אימון, בעוד שכלי המבוסס על מערכת קבצים או shell מעניק שליטה מלאה על השרת.

שלוש דרכי הגנה, לפי סדר עדיפות:

אל תפרסמו אותו. השאירו את השרת על 127.0.0.1 וגשו אליו מהמחשב הנייד שלכם באמצעות מנהרת SSH: ssh -L 8000:127.0.0.1:8000 matt@vps, ולאחר מכן כוונו את הלקוח ל-http://127.0.0.1:8000/mcp. שום דבר לא נחשף החוצה.
הציבו אותו ברשת פרטית. קשרו את כתובת המנהרה ל-שרת WireGuard VPN בניהול עצמי ואפשרו רק לעמיתי ה-VPN לגשת אליו. האינטרנט הציבורי יראה פורט סגור.
אם הוא חייב להיות ציבורי, דרשו אסימון. הפתרון התקין הוא תהליך ה-OAuth של MCP שנתמך באופן טבעי על ידי תעבורת HTTP. המינימום הפרגמטי הוא אסימון bearer משותף שנבדק ב-proxy; זהו פתרון זול שמונע גישה אקראית לחלוטין:

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...
}

צרו את האסימון באמצעות openssl rand -hex 32, ולעולם אל תקשרו את השרת עצמו ל-0.0.0.0 ללא אחד מהאמצעים הללו לפניו. הלקוח שולח את האסימון כ-header. ב-Claude Code:

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

הגדירו את MCP_TOKEN ב-shell שלכם כדי שהסוד לעולם לא יישמר ב-.mcp.json כטקסט גלוי; Claude Code מרחיב את ${MCP_TOKEN} מתוך משתני הסביבה בזמן הקריאה.

כל אמצעי הגנה לעיל מגן על נקודת הקצה ולא על הסוכן שכבר מחזיק באסימון, וזהו החצי השני של הבעיה: אם הלקוח שלכם הוא DeepSeek Harness, תוספים המגבילים אילו כלים סוכן רשאי להפעיל וסורקים את פלט הכלים עבור הוראות מוזרקות מכסים את הצד הזה.

שלב 6: ניפוי שגיאות באמצעות ה-MCP Inspector

כאשר שרת מתנהג באופן לא תקין, אל תנסו לנחש את הסיבה מתוך ה-agent; הפעילו אותו ישירות באמצעות ה-Inspector, לקוח הבדיקות הרשמי מבוסס האינטרנט. עבור שרת stdio, הזינו לו את אותה הפקודה שה-agent מריץ:

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

הכלי מפעיל ממשק משתמש ב-http://localhost:6274 (גרסאות עדכניות מדפיסות URL עם מחרוזת שאילתה MCP_PROXY_AUTH_TOKEN; השתמשו בקישור המדויק הזה, אחרת הממשק ידחה אתכם) ו-proxy בפורט 6277. לחצו על Connect, לאחר מכן על List Tools, ולבסוף על Call Tool עם ארגומנטים אמיתיים. אם הכלי עובד ב-Inspector אך נכשל ב-agent, הבאג נמצא בתצורת הלקוח שלכם ולא בשרת. עבור שרת HTTP מרוחק, בחרו ב-transport מסוג Streamable HTTP, הזינו את https://mcp.example.com/mcp, הוסיפו את ה-header מסוג Authorization והתחברו. זו הדרך המהירה ביותר לוודא שהאימות (auth) וה-proxy תקינים לפני שמעורבים רכיבי agent כלשהם.

שמירה על עדכניות השרתים

הפלטפורמה MCP מתפתחת במהירות, לכן יש להקפיד על לוח זמנים לעדכונים. שרתי Node שמופעלים עם npx -y מושכים את הגרסה העדכנית ביותר בכל הרצה; זה נוח אך אינו מאפשר שחזור מדויק. ברגע ששרת הופך למשמעותי, יש לקבע את הגרסה המדויקת שבדקתם, לקרוא אותה מתוך npm view @modelcontextprotocol/server-filesystem version ולהוסיף אותה לשם החבילה בתוך .mcp.json (@modelcontextprotocol/server-filesystem@<version>), ולבצע שדרוג גרסה באופן יזום. שרתי Python המנוהלים תחת systemd מתעדכנים באמצעות sudo -H -u mcp /opt/mcp-ops/.venv/bin/pip install -U "mcp[cli]" ולאחריו sudo systemctl restart mcp-ops. בעת שדרוג, עקבו אחר גרסת ה-spec שאליה ה-SDK שלכם מכוון; מעבר בין ה-SSE ל-Streamable-HTTP עלול לשנות את פרוטוקול התעבורה שהלקוחות שלכם נדרשים לבקש.

מצבי כשל והודעות שגיאה נפוצות

הסוכן מדווח על כשל בשרת. claude mcp list מדפיס ✗ Failed to connect, וה־TUI מדווח על MCP server 'filesystem' failed to start. הרצו את claude --debug ובדרך כלל תראו Error: spawn npx ENOENT; הפקודה אינה נמצאת ב־PATH של הסוכן. סביבת הריצה חסרה או אינה במיקום שבו הסוכן מחפש: Node לא מותקן, npx חסר, או שנעשה שימוש ב־Python מתוך virtualenv ללא נתיב מלא. תקנו את הפקודה לנתיב מוחלט או התקינו את סביבת הריצה, ולאחר מכן התחברו מחדש.

שרת stdio מתחבר ומתנתק מיד. הלקוח מתעד שגיאת ניתוח JSON, משהו כמו Unexpected token 'S', "Server sta"... is not valid JSON או Failed to parse message. הסיבה תמיד זהה: השרת כתב שורת לוג ל-stdout. בחיבור stdio, ה-stdout הוא ערוץ ה-JSON-RPC, לכן כל טקסט חורג משחית את הזרם והלחיצת יד (handshake) נכשלת. ב-Node, הפקודה console.log כותבת ל-stdout; השתמשו ב-console.error. ב-Python, פקודת print() פשוטה כותבת ל-stdout; כתבו לוגים באמצעות logging המוגדר ל-sys.stderr, או העבירו file=sys.stderr. הכלל מוחלט: ב-stdio, רק JSON-RPC ב-stdout, כל תוכן אנושי ב-stderr.

שרת מרוחק מגיע ל-timeout או נסגר באמצע לחיצת היד. הלקוח נכשל עם MCP error -32000: Connection closed, או שה-Inspector נתקע בשלב ה-Connect ולעולם לא מציג כלים. מאחורי nginx, מדובר בבעיית buffering: ה-proxy מחזיק את זרם ה-SSE במקום לשלוח אותו מיד, לכן הלקוח ממתין לתגובה שלעולם לא מגיעה. הוסיפו את proxy_buffering off; (ואת שאר הבלוק בשלב 4) ל-location. אשרו זאת עם curl -N מול הכתובת הציבורית; עליכם לראות נתוני אירועים מגיעים בהדרגה, ולא כולם בבת אחת בסיום.

אימות נדחה. הלקוח מדווח על Error POSTing to endpoint (HTTP 401) או פשוט על 401 Unauthorized. או שה-header חסר, או שה-token שגוי, או שמשתנה ה-shell היה ריק כאשר הלקוח קרא את התצורה. זו מלכודת נפוצה, שכן ${MCP_TOKEN} מתרחב לכלום אם המשתנה לא מוגדר, ו-nginx רואה Bearer ללא ערך. הציגו את המשתנה עם echo, הוסיפו מחדש את ה-header, וודאו שהבתים המדויקים תואמים ל-token ב-if של nginx.

השירות לא עולה תחת systemd. הפקודה journalctl -u mcp-ops מציגה ModuleNotFoundError: No module named 'mcp', או ש-ExecStart מצביע על ה-Python של המערכת במקום על המפרש של ה-venv. לחלופין, Address already in use מעיד על כך שתהליך אחר תופס את פורט 8000; מצאו אותו בעזרת sudo ss -ltnp | grep 8000.

FAQ

מהו בדיוק שרת MCP?

זוהי תוכנית החושפת כלים ומשאבים ללקוח AI באמצעות פרוטוקול Model Context Protocol, תוך שימוש ב-JSON-RPC 2.0. מודל ה-AI לעולם אינו מריץ את הכלי בעצמו; הוא פונה ללקוח שלו, הלקוח קורא לשרת ה-MCP, והשרת מבצע את הפעולה ומחזיר תוצאה. מכיוון שהפרוטוקול הוא סטנדרטי, שרת אחד עובד עם כל לקוח תואם, בין אם מדובר ב-Claude Code, ב-Claude Desktop או ב-Gemini CLI.

מה ההבדל בין תעבורת stdio לבין HTTP?

שרת stdio מופעל על ידי הלקוח כתהליך בן (child process) ומתקשר דרך stdin/stdout, לכן הוא חי ומת יחד עם לקוח אחד על מכונה אחת ואינו זקוק לרשת או לאימות. שרת HTTP הוא שירות רשת הפועל ברקע ולקוחות רבים יכולים לגשת אליו בו-זמנית, ולכן הוא מחייב TLS ואימות. השתמשו ב-stdio עבור כלים מקומיים למשתמש יחיד; השתמשו ב-HTTP (או ב-Streamable HTTP בשרתים עדכניים) עבור כל שירות משותף או קבוע.

כיצד מאבטחים שרת MCP מרוחק?

הניחו שהוא מעניק גישה לקבצים, למסד הנתונים או ל-shell שלכם, ולעולם אל תחשפו אותו ללא אימות. הדרך הטובה ביותר היא להשאיר אותו מאוגד ל-localhost ולגשת אליו דרך מנהרת SSH או VPN פרטי; אם הוא חייב להיות ציבורי, הציבו אותו מאחורי reverse proxy האוכף bearer token או את תהליך ה-OAuth של MCP. צרו את ה-token באמצעות openssl rand -hex 32 ולעולם אל תאגדו את השרת ל-0.0.0.0 ללא אחד מאמצעי הגנה אלו לפניו.

כיצד מנפים שגיאות בשרת שאינו עולה?

ראשית, בדקו את claude mcp list. אם ✗ Failed to connect מציג שגיאה עם spawn ... ENOENT, המשמעות היא שהפקודה או סביבת הריצה חסרות, לכן תקנו את ה-path או התקינו אותן. אם השרת מתחבר אך מתנתק עם שגיאת JSON parse, ייתכן שהשרת כותב לוגים ל-stdout ומשבש את זרם ה-JSON-RPC; העבירו את כל הלוגים ל-stderr. לכל בעיה אחרת, הריצו את הפקודה המדויקת תחת ה-MCP Inspector, שמפעיל את השרת בסביבה מבודדת, כך שתוכלו להבחין בין באג בשרת לבין בעיית תצורה בלקוח.

#mcp #claude-code #ai-agents #self-hosting #systemd