SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-08-30

VPS वर MCP सर्व्हर कसे चालवावे: संपूर्ण मार्गदर्शक

तुमच्या VPS वर stdio आणि remote HTTP वापरून MCP सर्व्हर सेटअप करा. systemd, TLS आणि सुरक्षित प्रमाणीकरण पद्धतींचा वापर करून AI एजंटसाठी टूल्स कशी कार्यान्वित करावीत हे शिका.

तुम्ही काय तयार करत आहात

एकाच VPS वर दोन कार्यरत MCP सेटअप. पहिले एक stdio सर्व्हर, जे एक फाइलसिस्टम किंवा डेटाबेस टूल आहे. Claude Code याला चाइल्ड प्रोसेस म्हणून लाँच करते आणि पाइपद्वारे संवाद साधते. दुसरे एक remote HTTP सर्व्हर, जे systemd आणि TLS सह nginx रिव्हर्स प्रॉक्सीच्या मागे दीर्घकाळ चालणारी नेटवर्क सेवा म्हणून कार्यरत असते. हे कोणत्याही MCP क्लायंटद्वारे वापरता येते. यापैकी कोणत्याही सेटअपची स्थापना सोपी आहे. या मार्गदर्शकाचा मुख्य भाग अशा दोन गोष्टींवर केंद्रित आहे ज्या सहसा अडचणी निर्माण करतात: JSON-RPC स्ट्रीम स्वच्छ ठेवणे आणि प्रमाणीकरण नसलेले टूल एंडपॉइंट कधीही सार्वजनिक इंटरनेटवर उघडे न ठेवणे.

MCP म्हणजे नेमके काय आहे

Model Context Protocol (MCP) ही एक प्रमाणित पद्धत आहे, ज्याद्वारे AI क्लायंट (उदा. Claude Code, Claude Desktop, VPS वरील Gemini CLI, किंवा तुमची स्वतःची स्क्रिप्ट) बाह्य टूल्सना कॉल करू शकतात आणि बाह्य संसाधने वाचू शकतात. मॉडेल स्वतः काहीही रन करत नाही. ते क्लायंटला विनंती करते, क्लायंट MCP server शी JSON-RPC 2.0 मध्ये संवाद साधतो, सर्व्हर टूल रन करतो आणि निकाल परत देतो. जेव्हा लोक agent harness बद्दल बोलतात, तेव्हा त्यांचा अर्थ हा क्लायंटच असतो: मॉडेलच्या भोवती असलेले ते लूप, ज्याकडे टूल्सची यादी, परवानगी तपासणी आणि सेशन स्टेट असते. MCP हे केवळ त्यातील टूलचा भाग विस्तारित करण्याचे एक साधन आहे. हे एकच प्रोटोकॉल असल्याने, तुम्ही एकदा लिहिलेला सर्व्हर MCP ला सपोर्ट करणाऱ्या प्रत्येक क्लायंटसोबत काम करतो. जर हे विभाजन तुमच्यासाठी नवीन असेल, आणि विशेषतः मॉडेल एखादे टूल वापरण्याचा निर्णय कसा घेते हा प्रश्न असेल, तर agent fundamentals चा टप्प्याटप्प्याने प्रवास वाचण्यासाठी एक तास देणे फायदेशीर ठरेल, विशेषतः या सर्व्हर्सना प्रत्यक्ष क्रेडेंशियल्स देण्यापूर्वी.

यामध्ये दोन ट्रान्सपोर्ट्स आहेत आणि या मार्गदर्शिकेचा उर्वरित भाग त्या दोन विभागांत विभागलेला आहे:

  • stdio. क्लायंट सर्व्हरला चाइल्ड प्रोसेस म्हणून सुरू करतो आणि त्याच्या standard input आणि standard output द्वारे newline-delimited JSON-RPC मेसेजची देवाणघेवाण करतो. यामध्ये कोणतेही नेटवर्क, पोर्ट किंवा ऑथेंटिकेशन नसते; विश्वासाची सीमा (trust boundary) ही ती प्रोसेस स्वतः असते. जवळजवळ सर्व स्थानिक टूल्स याच पद्धतीने काम करतात.
  • Streamable HTTP (आणि त्याचा जुना प्रकार, HTTP+SSE). सर्व्हर ही एक दीर्घकाळ चालणारी वेब सर्व्हिस असते. क्लायंट HTTP द्वारे कनेक्ट होतो आणि सर्व्हर Server-Sent Events द्वारे प्रतिसाद स्ट्रीम करू शकतो. एकाच सर्व्हरला अनेक क्लायंटसोबत शेअर करण्यासाठी किंवा कायमस्वरूपी सर्व्हरवर राहणारे टूल चालवण्यासाठी ही पद्धत वापरली जाते.

जेव्हा टूल एका मशीनसाठी आणि एका वापरकर्त्यासाठी असते, तेव्हा stdio निवडा. जेव्हा ती एक सामायिक सर्व्हिस असते, तेव्हा HTTP निवडा.

पूर्वअटी आणि काही महत्त्वाच्या गोष्टी

एक नवीन Ubuntu 24.04 KVM VPS आणि त्यावर root किंवा sudo ॲक्सेस आहे असे गृहीत धरा. याव्यतिरिक्त खालील गोष्टी आवश्यक आहेत:

  • सर्व्हर ज्या रनटाइममध्ये लिहिला आहे तो. बहुतेक संदर्भ सर्व्हर Node किंवा Python मध्ये आहेत. Ubuntu 24.04 मध्ये Node 18 येते, परंतु अनेक सध्याची MCP पॅकेजेसना Node 20 किंवा त्यापेक्षा नवीन आवृत्तीची आवश्यकता असते. त्यामुळे apt वर अवलंबून राहण्याऐवजी NodeSource किंवा nvm द्वारे सध्याची LTS आवृत्ती इंस्टॉल करा. Python 3.12 आधीच उपलब्ध आहे.
  • एक डोमेन आणि DNS A record. हे फक्त रिमोट HTTP सर्व्हरसाठी आवश्यक आहे, कारण TLS साठी अशा नावाची गरज असते जे या VPS वर रिझॉल्व्ह होईल. stdio उदाहरणासाठी कोणत्याही DNS ची गरज नाही.
  • 512 MB RAM पुरेशी आहे. MCP सर्व्हर्स हे हलके JSON-RPC प्रोसेस असतात; मेमरीचा वापर हा प्रोटोकॉलवर अवलंबून नसून तुमचे टूल कशावर प्रक्रिया करते (उदा. डेटाबेस ड्रायव्हर, फाईल कॅशे) यावर अवलंबून असतो.
  • ही स्पेसिफिकेशन नवीन आहे आणि त्यात बदल होत आहेत. 2025-03-26 च्या रिव्हिजनने HTTP+SSE ऐवजी Streamable HTTP चा वापर सुरू केला आहे आणि SSE ला deprecated घोषित केले आहे. SSE अजूनही काम करते आणि अनेक सर्व्हर्स ते वापरतात, त्यामुळे कोणत्याही ट्रान्सपोर्ट पिनला अंतिम सत्य मानण्याऐवजी सर्व्हरच्या रिलीज नोट्सनुसार वेळोवेळी तपासा.

पायरी 1: Claude Code मध्ये stdio सर्व्हर जोडणे

filesystem सर्व्हरपासून सुरुवात करा. तो अधिकृत आहे, सक्रियपणे मेंटेन केला जातो आणि त्यासाठी फक्त Node ची आवश्यकता आहे. खालील एक कमांड त्याला Claude Code सोबत रजिस्टर करते आणि सध्याच्या प्रोजेक्टपुरते मर्यादित ठेवते, जेणेकरून ती फाइल कमिट करता येईल:

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

-- सेपरेटर महत्त्वाचा आहे: त्यानंतर येणारी प्रत्येक गोष्ट Claude Code द्वारे चालवली जाणारी कमांड आहे, 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 ... ला चाइल्ड प्रोसेस म्हणून सुरू करतो आणि त्या प्रोसेसच्या stdin/stdout द्वारे MCP हँडशेक पूर्ण करतो. ते यशस्वी झाल्याची खात्री करा:

claude mcp list

एक सुस्थितीत असलेला सर्व्हर त्याची कमांड आणि हिरवी टिक, filesystem: npx -y @modelcontextprotocol/server-filesystem ... - ✓ Connected दाखवतो. सेशनच्या आत, /mcp स्लॅश कमांड सर्व्हरद्वारे उपलब्ध करून दिलेली टूल्स (read_file, write_file, list_directory) यांची यादी दाखवते आणि एजंट आता तुम्ही परवानगी दिलेल्या पाथवर ती टूल्स वापरू शकतो. डेटाबेस टूलची पद्धतही अशीच आहे, फक्त पॅकेज बदला आणि शेवटचा आर्ग्युमेंट म्हणून कनेक्शन स्ट्रिंग द्या. मात्र, सध्याच्या पॅकेजच्या नावासाठी सर्व्हरच्या स्वतःच्या रिपॉझिटरीमध्ये तपासा, कारण संदर्भ म्हणून वापरला जाणारा Postgres सर्व्हर अनेकदा बदलला आहे.

एजंटला सर्व्हरवर चालवण्याचा मुख्य उद्देश हाच आहे: Claude Code सेशन VPS वर tmux मध्ये राहते, आणि त्याचे stdio सर्व्हर थेट प्रोजेक्ट फाइल्स आणि स्थानिक सेवांच्या ॲक्सेससह त्याच्या शेजारी चालतात, ज्यामुळे नेटवर्कचा विलंब होत नाही. एकदा का एजंटकडे write_file आणि read_file दोन्ही आले की, त्या क्षमतेची जोड सर्वात लहान आणि प्रभावी बदलाकडे नेणाऱ्या कौशल्याशी देणे फायदेशीर ठरते, कारण filesystem टूलमुळे मोठा बदल करणे हे दोन ओळींच्या दुरुस्तीइतकेच सोपे होते. हे कनेक्शन स्थानिक फाइल्सच्या पलीकडेही जाते: जर तुम्ही VPS वर आधीच सर्च इंजिन चालवत असाल, तर तुम्ही तुमचे स्वतःचे SearXNG इन्स्टन्स एजंटला सर्च टूल म्हणून देऊ शकता, ज्यामुळे क्वेरीज तुमच्या सर्व्हरवरच राहतात, पण अविश्वसनीय पेज टेक्स्ट थेट एजंटच्या कॉन्टेक्स्टमध्ये येते, ज्यावर तो प्रक्रिया करतो.

पायरी 2: रिमोट HTTP सर्व्हर तयार करणे

stdio सर्व्हर त्याच्या मूळ प्रक्रियेसोबत (parent) बंद होतो आणि प्रत्येक क्लायंटसाठी तो एकदाच सुरू केला जातो. त्यामुळे जर तुम्ही एकाच मशीनवर दोन Claude Code सत्रे चालवली जी एकमेकांना काम सोपवतात, तर प्रत्येकाला त्या टूलची स्वतःची स्वतंत्र प्रत मिळते. जेव्हा तुम्हाला असे टूल हवे असते जे प्रत्येक क्लायंटसाठी चालू राहते, जसे की सामायिक ops टूल, डेटाबेस गेटवे, किंवा अशी गोष्ट जी तुमचा लॅपटॉप आणि CI दोन्ही कॉल करतात, तेव्हा तुम्हाला HTTP ट्रान्सपोर्ट आणि एका खऱ्या सर्व्हिसची गरज असते. अधिकृत SDK वापरून एक टूल एक्स्पोज करणारा किमान Python सर्व्हर खालीलप्रमाणे आहे:

# /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 कडे एक स्थिर इंटरप्रिटर पाथ असेल:

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 सह सेवा सुरू ठेवा

जेव्हा एजंट एखाद्या टूलला कॉल करतो आणि ते बंद असते, तेव्हा ते टूल नसण्यापेक्षाही वाईट असते. जेव्हा क्लायंट स्वतः एक दीर्घकाळ चालणारी प्रक्रिया असते, तेव्हा हे अधिक महत्त्वाचे ठरते: एक always-on agent जो रीबूटनंतरही आपली मेमरी आणि शेड्युल कायम ठेवतो तो कोणाच्याही देखरेखीशिवाय ठराविक वेळेत या टूल्सना कॉल करेल, त्यामुळे सर्व्हरने स्वतःहून पुन्हा सुरू होणे आवश्यक आहे. /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

ExecStart मधील venv Python चा पूर्ण पाथ (absolute path) अनिवार्य आहे, तो /usr/bin/python3 कडे निर्देशित करा आणि प्रक्रिया ModuleNotFoundError: No module named 'mcp' सह सुरू होईल, कारण सिस्टम इंटरप्रिटरला तुमचे 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) आणि वैध JSON पेलोड नव्हते, आणि तुम्हाला नेमके हेच हवे आहे: हे सिद्ध करते की पोर्ट प्रतिसाद देत आहे आणि प्रोटोकॉलनुसार बोलत आहे. Connection refused किंवा रिकामे उत्तर म्हणजे प्रक्रिया तुम्ही विचार करता तिथे बाउंड (bound) नाही; journalctl -u mcp-ops -n 50 वाचा.

पायरी 4: TLS आणि रिव्हर्स प्रॉक्सी सेट करणे

सर्व्हर localhost वर विनंत्या स्वीकारतो. बाहेरून प्रवेश मिळवण्यासाठी nginx वर TLS टर्मिनेट करा आणि विनंत्या आत पाठवा. nginx इन्स्टॉल करा, Certbot आणि Let's Encrypt on nginx वापरून प्रमाणपत्र मिळवा आणि त्यानंतर location ब्लॉक लिहा. यामध्ये बफरिंग बंद करणे अत्यंत महत्त्वाचे आहे, कारण 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 with automatic TLS हे काम तुमच्यासाठी करते. ते आपोआप प्रमाणपत्र जारी करते आणि hostname नुसार ट्रॅफिक राउट करते; तुम्हाला फक्त MCP कंटेनरला लेबल्स जोडायची असतात. दोन्हीपैकी कोणत्याही पद्धतीत, आता फक्त रिव्हर्स प्रॉक्सीच सार्वजनिक पोर्टवर उपलब्ध आहे आणि ती अशा सर्व्हिसकडे निर्देश करते जी तुम्ही अजून सुरक्षित केलेली नाही. URL कुठेही रजिस्टर करण्यापूर्वी ही सुरक्षा निश्चित करा.

पायरी 5: या विषयातील सर्वात महत्त्वाची सुरक्षा नियमावली

कोणताही प्रमाणीकरण नसलेला (unauthenticated) MCP endpoint कधीही उघडा ठेवू नका. MCP सर्व्हर हे केवळ read-only API नसते. ते तुमच्या फाइल्स, डेटाबेस आणि काही वेळा शेलवरही नियंत्रण मिळवून देते. इंटरनेटवर उघडे असलेले /mcp म्हणजे तुमच्या AI एजंटसारखीच क्षमता असलेला एक अनोळखी व्यक्ती आहे: ते तुमच्या टूल्सची यादी पाहू शकतात आणि नंतर ते वापरू शकतात. याकडे प्रमाणीकरण नसलेले admin socket म्हणूनच पहा, कारण ते तसेच असते. चोरलेल्या टोकनमुळे किती नुकसान होऊ शकते हे त्यामागील सर्व्हरवर अवलंबून असते: openGym workout tracker सोबत येणारा read-only MCP सर्व्हर फक्त ट्रेनिंग डेटा देऊ शकतो, तर filesystem किंवा shell टूल संपूर्ण सर्व्हरचा ताबा देऊ शकते.

प्राधान्यक्रमानुसार तीन सुरक्षा उपाय:

  1. ते सार्वजनिक करू नका. सर्व्हरला 127.0.0.1 वर ठेवा आणि तुमच्या लॅपटॉपवरून SSH tunnel द्वारे प्रवेश करा: ssh -L 8000:127.0.0.1:8000 matt@vps, त्यानंतर क्लायंटला http://127.0.0.1:8000/mcp कडे निर्देशित करा. यामुळे काहीही उघड होत नाही.
  2. ते खाजगी नेटवर्कवर ठेवा. self-hosted WireGuard VPN च्या टनेल ॲड्रेसवर बाइंड करा आणि फक्त VPN मधील वापरकर्त्यांनाच प्रवेश द्या. सार्वजनिक इंटरनेटसाठी पोर्ट बंद राहील.
  3. जर ते सार्वजनिक करणे अनिवार्य असेल, तर टोकनची सक्ती करा. योग्य मार्ग म्हणजे HTTP transport द्वारे समर्थित MCP OAuth flow वापरणे. किमान व्यावहारिक उपाय म्हणजे प्रॉक्सीवर तपासले जाणारे shared bearer token; हे स्वस्त आहे आणि यादृच्छिक हल्ले (drive-by attacks) पूर्णपणे थांबवते:
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 सेट करा जेणेकरून secret कधीही .mcp.json मध्ये plaintext स्वरूपात साठवले जाणार नाही, Claude Code वाचताना ${MCP_TOKEN} ला environment मधून एक्सपँड करते.

वरील प्रत्येक उपाय endpoint चे रक्षण करतो, परंतु ज्या एजंटकडे आधीच टोकन आहे, तो दुसरा भाग आहे: जर तुमचा क्लायंट DeepSeek Harness असेल, तर एजंट कोणती टूल्स वापरू शकतो यावर मर्यादा घालणारे आणि टूल आउटपुटमधील इंजेक्ट केलेल्या सूचना स्कॅन करणारे प्लगइन्स या बाजूने सुरक्षा प्रदान करतात.

पायरी 6: MCP Inspector वापरून डीबग करा

जेव्हा सर्व्हर नीट काम करत नसेल, तेव्हा एजंटच्या आतून अंदाज लावू नका. त्याऐवजी अधिकृत वेब-आधारित टेस्ट क्लायंट असलेल्या Inspector द्वारे ते थेट चालवा. stdio सर्व्हरसाठी, एजंट जी कमांड चालवतो तीच कमांड त्याला द्या:

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

हे http://localhost:6274 वर एक UI सुरू करते (नवीन आवृत्त्या MCP_PROXY_AUTH_TOKEN क्वेरी स्ट्रिंगसह एक URL प्रिंट करतात, तीच लिंक वापरा अन्यथा UI तुम्हाला नाकारेल) आणि 6277 वर एक प्रॉक्सी सुरू करते. Connect वर क्लिक करा, त्यानंतर List Tools वर क्लिक करा आणि शेवटी प्रत्यक्ष आर्ग्युमेंट्ससह Call Tool वापरा. जर ते Inspector मध्ये काम करत असेल पण एजंटमध्ये अयशस्वी होत असेल, तर त्रुटी तुमच्या क्लायंट कॉन्फिगरेशनमध्ये आहे, सर्व्हरमध्ये नाही. रिमोट HTTP सर्व्हरसाठी, Streamable HTTP ट्रान्सपोर्ट निवडा, https://mcp.example.com/mcp प्रविष्ट करा, Authorization हेडर जोडा आणि कनेक्ट करा. कोणताही एजंट गुंतण्यापूर्वी ऑथेंटिकेशन आणि प्रॉक्सी योग्य असल्याची खात्री करण्याचा हा सर्वात जलद मार्ग आहे.

सर्व्हर अपडेट ठेवणे

MCP वेगाने विकसित होत आहे, त्यामुळे ठराविक वेळापत्रकानुसार पॅचिंग करा. npx -y वापरून सुरू केलेले Node सर्व्हर्स प्रत्येक वेळी नवीन आवृत्ती घेतात, जे सोयीचे असले तरी पुनरावृत्ती करण्यायोग्य (reproducible) नसते. तुम्ही चाचणी केलेली नेमकी आवृत्ती निश्चित करा, ती npm view @modelcontextprotocol/server-filesystem version मधून वाचा आणि .mcp.json (@modelcontextprotocol/server-filesystem@<version>) मधील पॅकेज नावापुढे जोडा. एकदा सर्व्हर महत्त्वाचा झाला की, त्याची आवृत्ती जाणीवपूर्वक वाढवा. systemd अंतर्गत चालणारे Python सर्व्हर्स sudo -H -u mcp /opt/mcp-ops/.venv/bin/pip install -U "mcp[cli]" आणि त्यानंतर sudo systemctl restart mcp-ops वापरून अपडेट करा. अपग्रेड करताना तुमचा SDK ज्या spec revision ला लक्ष्य करतो, त्यावर लक्ष ठेवा. SSE-to-Streamable-HTTP सीमेपलीकडे होणारा बदल तुमच्या क्लायंटला आवश्यक असलेल्या ट्रान्सपोर्ट पद्धतीत बदल घडवू शकतो.

अपयशाचे प्रकार आणि दिसणारे संदेश

एजंट सर्व्हर अयशस्वी झाल्याचे दर्शवतो. claude mcp list हे ✗ Failed to connect प्रिंट करते आणि TUI मध्ये MCP server 'filesystem' failed to start असा अहवाल मिळतो. claude --debug चालवल्यास तुम्हाला सहसा Error: spawn npx ENOENT दिसेल, याचा अर्थ कमांड एजंटच्या PATH मध्ये नाही. रनटाइम गहाळ आहे किंवा एजंट ज्या ठिकाणी शोधत आहे तिथे उपलब्ध नाही: Node इन्स्टॉल केलेले नाही, npx अनुपस्थित आहे किंवा bare name द्वारे संदर्भित virtualenv Python वापरले जात आहे. कमांडचा पूर्ण पाथ (absolute path) द्या किंवा रनटाइम इन्स्टॉल करा आणि पुन्हा कनेक्ट करा.

stdio सर्व्हर कनेक्ट होतो, पण लगेच डिस्कनेक्ट होतो. क्लायंट लॉगमध्ये JSON पार्स एरर दिसते, जसे की Unexpected token 'S', "Server sta"... is not valid JSON किंवा Failed to parse message. याचे कारण नेहमी एकच असते: सर्व्हरने stdout वर लॉग लाईन लिहिली आहे. stdio वर, stdout हेच JSON-RPC चॅनेल असते, त्यामुळे कोणताही अतिरिक्त मजकूर स्ट्रीम खराब करतो आणि हँडशेक अयशस्वी होतो. Node मध्ये, console.log हे stdout वर जाते, त्याऐवजी console.error वापरा. Python मध्ये, साधे print() हे stdout वर जाते, म्हणून लॉग लिहिताना logging चा वापर करा जे sys.stderr वर कॉन्फिगर केलेले असेल, किंवा file=sys.stderr पास करा. नियम स्पष्ट आहे: stdio वर, stdout वर फक्त JSON-RPC असावे, मानवी वाचनासाठीचे सर्व मजकूर stderr वर असावेत.

रिमोट सर्व्हर टाइम आउट होतो किंवा हँडशेक दरम्यान बंद होतो. क्लायंट MCP error -32000: Connection closed सह अयशस्वी होतो, किंवा इन्स्पेक्टर Connect वर अडकून राहतो आणि टूल्सची यादी दाखवत नाही. nginx च्या मागे हे बफरिंगमुळे घडते: प्रॉक्सी SSE स्ट्रीम फ्लश करण्याऐवजी स्वतःकडे धरून ठेवते, त्यामुळे क्लायंट अशा प्रतिसादाची वाट पाहतो जो कधीच पोहोचत नाही. proxy_buffering off; (आणि स्टेप 4 मधील उर्वरित ब्लॉक) location मध्ये जोडा. सार्वजनिक URL वर curl -N वापरून खात्री करा, तुम्हाला इव्हेंट डेटा टप्प्याटप्प्याने येताना दिसेल, शेवटी एकदम नाही.

ऑथेंटिकेशन नाकारले जाते. क्लायंट Error POSTing to endpoint (HTTP 401) किंवा स्पष्टपणे 401 Unauthorized असा अहवाल देतो. एकतर हेडर गहाळ आहे, टोकन चुकीचे आहे, किंवा क्लायंटने कॉन्फिगरेशन वाचले तेव्हा शेल व्हेरिएबल रिकामे होते. ही एक सामान्य चूक आहे, कारण जर व्हेरिएबल सेट नसेल तर ${MCP_TOKEN} काहीही विस्तार करत नाही आणि nginx ला Bearer हे मूल्य नसलेले दिसते. व्हेरिएबल इको (echo) करून तपासा, हेडर पुन्हा जोडा आणि nginx if मधील टोकनशी बाइट्स तंतोतंत जुळतात याची खात्री करा.

systemd अंतर्गत सर्व्हिस सुरू होत नाही. journalctl -u mcp-ops हे ModuleNotFoundError: No module named 'mcp' दर्शवते, ExecStart हे venv इंटरप्रिटरऐवजी सिस्टम Python कडे निर्देश करते. किंवा Address already in use, दुसरी प्रक्रिया 8000 पोर्ट वापरत आहे; ती शोधण्यासाठी sudo ss -ltnp | grep 8000 वापरा.

FAQ

MCP सर्व्हर म्हणजे नक्की काय?

हा एक असा प्रोग्राम आहे जो Model Context Protocol द्वारे JSON-RPC 2.0 चा वापर करून AI क्लायंटला टूल्स आणि रिसोर्सेस उपलब्ध करून देतो. AI मॉडेल स्वतः टूल चालवत नाही, तर ते आपल्या क्लायंटला विनंती करते, क्लायंट MCP सर्व्हरला कॉल करतो आणि सर्व्हर ती प्रक्रिया पूर्ण करून निकाल परत देतो. हा प्रोटोकॉल प्रमाणित असल्याने, एकच सर्व्हर कोणत्याही सुसंगत क्लायंटसोबत काम करतो, मग तो Claude Code, Claude Desktop किंवा Gemini CLI असो.

stdio आणि HTTP ट्रान्सपोर्टमध्ये काय फरक आहे?

stdio सर्व्हर क्लायंटद्वारे चाइल्ड प्रोसेस म्हणून सुरू केला जातो आणि तो stdin/stdout द्वारे संवाद साधतो. त्यामुळे तो एका मशीनवर एका क्लायंटसोबतच अस्तित्वात असतो आणि त्याला नेटवर्क किंवा ऑथेंटिकेशनची गरज नसते. HTTP सर्व्हर ही एक दीर्घकाळ चालणारी नेटवर्क सेवा आहे जिथे अनेक क्लायंट एकाच वेळी कनेक्ट होऊ शकतात, म्हणूनच त्याला TLS आणि ऑथेंटिकेशनची आवश्यकता असते. स्थानिक, सिंगल-युजर टूल्ससाठी stdio वापरा; तर शेअर केलेल्या किंवा कायमस्वरूपी सेवांसाठी HTTP (सध्याच्या सर्व्हरवर Streamable HTTP) वापरा.

रिमोट MCP सर्व्हर सुरक्षित कसा ठेवावा?

हे लक्षात ठेवा की तो तुमच्या फाइल्स, डेटाबेस किंवा शेलचे ॲक्सेस देतो, त्यामुळे तो कधीही विना-ऑथेंटिकेशन उघडा ठेवू नका. त्याला localhost वर मर्यादित ठेवून SSH टनेल किंवा खाजगी VPN द्वारे ॲक्सेस करणे सर्वोत्तम आहे. जर तो सार्वजनिक करणे अनिवार्य असेल, तर त्याला अशा reverse proxy च्या मागे ठेवा जो bearer token किंवा MCP OAuth फ्लो लागू करतो. openssl rand -hex 32 वापरून टोकन तयार करा आणि यापैकी कोणतीही सुरक्षा व्यवस्था नसेल तर सर्व्हरला कधीही 0.0.0.0 वर बाइंड करू नका.

सुरू न होणाऱ्या सर्व्हरचे डीबगिंग कसे करावे?

प्रथम claude mcp list, ✗ Failed to connect तपासा. spawn ... ENOENT चा अर्थ असा की कमांड किंवा रनटाइम उपलब्ध नाही, त्यामुळे पाथ (path) दुरुस्त करा किंवा ते इन्स्टॉल करा. जर तो कनेक्ट होऊन JSON parse error मुळे बंद होत असेल, तर सर्व्हर stdout वर लॉगिंग करत आहे आणि त्यामुळे JSON-RPC स्ट्रीम खराब होत आहे; सर्व लॉगिंग stderr वर हलवा. इतर कोणत्याही समस्येसाठी, तीच कमांड MCP Inspector अंतर्गत चालवा, जे सर्व्हरला स्वतंत्रपणे चालवते जेणेकरून तुम्हाला सर्व्हरमधील बग आणि क्लायंट-कॉन्फिगरेशनमधील बग यातील फरक ओळखता येईल.

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