MCP Registry: GitHub, server.json और अपना सर्वर कैसे लिस्ट करें

एक अच्छा MCP सर्वर, जिसे कोई खोज न सके, लगभग मौजूद न होने जैसा है। आधिकारिक MCP Registry इसी समस्या को एक JSON फ़ाइल, एक सत्यापित नाम और एक कमांड से हल करती है, और इस रास्ते में GitHub तीन अलग जगहों पर सामने आता है: लॉगिन, namespace और रिलीज़ ऑटोमेशन। यह लेख registry docs की सटीक फ़ाइलों और कमांड्स को फ़ॉलो करता है, ताकि आपका सर्वर पाँचवीं बार नहीं, पहली ही कोशिश में registry में पहुँच जाए।

💡 त्वरित जवाब: एक server.json लिखें, साबित करें कि वह जिस पैकेज की ओर इशारा करता है वह आपका है, mcp-publisher login github चलाएँ, फिर mcp-publisher publish चलाएँ। नीचे हर चरण समझाया गया है कि वह क्यों ज़रूरी है और उसे छोड़ने पर क्या बिगड़ता है।

MCP Registry असल में क्या है

MCP Registry सार्वजनिक रूप से उपलब्ध MCP सर्वरों के लिए आधिकारिक, केंद्रीकृत metadata repository है, जिसे Anthropic, GitHub, PulseMCP और Microsoft का समर्थन प्राप्त है। यह सितंबर 2025 में preview के रूप में खुली थी, API अक्टूबर 2025 के अंत से v0.1 पर फ़्रीज़ है, और docs में अब भी preview का बैनर है, इसलिए छोटे बदलावों की उम्मीद रखें। लाइव सर्विस registry.modelcontextprotocol.io पर है।

Metadata, कोड नहीं

Registry आपका कोड कभी स्टोर नहीं करती। वह एक रिकॉर्ड स्टोर करती है जो npm, PyPI, NuGet, crates.io, किसी container registry या GitHub release पर मौजूद पैकेज की ओर इशारा करता है। इसे कंटेनर पोर्ट की तरह समझें: मैनिफ़ेस्ट बताता है कि हर बॉक्स में क्या है और वह कहाँ से आया, जबकि कार्गो कहीं और रहता है। इसीलिए क्रम मायने रखता है। पहले पैकेज प्रकाशित करें, और उसके बाद ही registry की एंट्री।

GitHub कहाँ आता है

GitHub इस प्रक्रिया को तीन जगह छूता है:

• पहचान। GitHub से लॉग इन करें, और आपके सर्वर का नाम io.github.username/ से शुरू होना चाहिए, या यूज़रनेम की जगह आपके संगठन का नाम होना चाहिए।
• मेटाडेटा। server.json में एक repository ऑब्जेक्ट होता है, जिसमें "source": "github" और रेपो का URL रहता है।
• ऑटोमेशन। GitHub Actions OIDC के ज़रिए रजिस्ट्री से ऑथेंटिकेट कर सकता है, और इसके लिए कोई सीक्रेट स्टोर नहीं करना पड़ता।

इसके अलावा एक अलग storefront भी है। GitHub अपना MCP Registry github.com/mcp पर चलाता है, और GitHub ने घोषणा की है कि ओपन सोर्स community registry में खुद प्रकाशित किए गए सर्वर वहाँ "अपने आप दिखने लगेंगे"। इसे वादा नहीं, बोनस मानें: प्रकाशित करने के बाद GitHub लिस्टिंग खुद जाँच लें।

सर्वर कौन लिस्ट कर सकता है

ओपन सोर्स और क्लोज़्ड सोर्स, दोनों तरह के सर्वर स्वीकार किए जाते हैं, बस एक शर्त है: सर्वर सार्वजनिक रूप से पहुँच योग्य होना चाहिए। इसका मतलब है एक सार्वजनिक पैकेज (जैसे npm पैकेज, या सार्वजनिक registry पर Docker image) या एक remote endpoint जो किसी private network के अंदर बंद न हो। mcp.acme-corp.internal जैसे internal host पर चल रहे सर्वर, या private package registry के पीछे मौजूद सर्वर, इसके दायरे से बाहर हैं। उनके लिए अपनी private registry चलाएँ।

यह भी जानने लायक है: होस्ट ऐप्स को आधिकारिक registry सीधे पढ़ने के लिए नहीं बनाया गया है। Marketplaces और aggregators नियमित अंतराल पर, जैसे हर घंटे, उससे डेटा लेते हैं और उस पर अपनी curation और ratings जोड़ते हैं। आपकी लिस्टिंग इन्हीं के ज़रिए आगे पहुँचती है।

पहले अपना namespace चुनें

server.json में name फ़ील्ड आपके सर्वर की स्थायी पहचान है, और आपकी लॉगिन विधि तय करती है कि आप कौन से नाम इस्तेमाल कर सकते हैं।

तुरंत नतीजे के लिए GitHub नाम

जब आप एक व्यक्तिगत डेवलपर या ओपन सोर्स प्रोजेक्ट हों, तो GitHub वाला रास्ता चुनें। CLI एक OAuth device flow चलाता है, आप उसे ब्राउज़र में मंज़ूरी देते हैं, और कुछ मिनटों में काम हो जाता है। कोई DNS पैनल नहीं, होस्ट करने के लिए कोई फ़ाइल नहीं। इसकी कीमत नाम है: io.github.alice/weather-server एक साइड प्रोजेक्ट के लिए ठीक लगता है, लेकिन किसी कंपनी के ब्रांड को आमतौर पर अपना domain चाहिए।

DNS या HTTP से Domain नाम

Domain-आधारित नाम किसी ऐसे domain के उल्टे रूप में होते हैं जो आपके नियंत्रण में हो, जैसे com.example/acme-analytics। आप नियंत्रण दो तरीकों में से किसी एक से साबित करते हैं:

1. DNS। openssl से एक Ed25519 (या ECDSA P-384) जोड़ी बनाएँ, फिर सार्वजनिक हिस्से को example.com. IN TXT "v=MCPv1; k=ed25519; p=<base64>" फ़ॉर्म में TXT record के रूप में प्रकाशित करें। propagation में कुछ मिनट लग सकते हैं।
2. HTTP। वही v=MCPv1; ... लाइन एक फ़ाइल के रूप में https://example.com/.well-known/mcp-registry-auth पर होस्ट करें।

इसके बाद mcp-publisher login dns --domain example.com या mcp-publisher login http --domain example.com से लॉग इन करें, और अपनी जोड़ी का प्राइवेट हिस्सा जोड़ें, जैसा ऑथेंटिकेशन डॉक्स में दिखाया गया है। जो टीमें लैपटॉप पर प्राइवेट फ़ाइल नहीं रखना चाहतीं, वे इसकी जगह Google या Azure की क्लाउड साइनिंग सेवाओं से साइन कर सकती हैं।

server.json चरण-दर-चरण लिखें

Skeleton बनाएँ

पब्लिशर को Homebrew (brew install mcp-publisher) से इंस्टॉल करें या रजिस्ट्री के GitHub रिलीज़ से बाइनरी डाउनलोड करें। फिर अपने सर्वर प्रोजेक्ट के अंदर यह चलाएँ:

mcp-publisher --help
mcp-publisher init

प्रॉम्प्ट कॉपी करें

init कमांड एक server.json टेम्पलेट लिखता है और आपके प्रोजेक्ट से जो भर सकता है, उसे भर देता है।

एक न्यूनतम काम करने वाली फ़ाइल

Docs में एक local npm सर्वर के लिए जो ढाँचा दिखाया गया है, वह यह है:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.my-username/weather",
  "description": "An MCP server for weather information.",
  "repository": {
    "url": "https://github.com/my-username/mcp-weather-server",
    "source": "github"
  },
  "version": "1.0.1",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@my-username/mcp-weather-server",
      "version": "1.0.1",
      "transport": {
        "type": "stdio"
      }
    }
  ]
}

प्रॉम्प्ट कॉपी करें

init जो $schema लाइन बनाता है, उसे रखें, क्योंकि schema की तारीख समय के साथ बदलती है। तीन फ़ील्ड सबसे ज़्यादा परेशानी देते हैं। name को आपके पैकेज के अंदर के ownership proof से मेल खाना होगा (इस पर नीचे और बात है)। packages[].identifier किसी ऐसी चीज़ की ओर इशारा करना चाहिए जो पहले से प्रकाशित हो। और transport.type बताता है कि क्लाइंट सर्वर से कैसे बात करें, जहाँ stdio का मतलब है एक local process।

क्या एनवायरनमेंट वेरिएबल चाहिए? उन्हें isRequired और isSecret फ़्लैग के साथ पैकेज एंट्री में जोड़ें, ताकि क्लाइंट उनके लिए पूछें और इनपुट को छिपाकर रखें।

वर्ज़न के नियम जो परेशान करते हैं

हर प्रकाशन के लिए एक अनूठा version चाहिए, और एक बार प्रकाशित होने के बाद वह वर्ज़न और उसका metadata बदला नहीं जा सकता। Semantic versioning की सिफ़ारिश की गई है, हालाँकि कोई भी string स्वीकार होती है। Version ranges जानबूझकर अस्वीकार की जाती हैं।

दो आदतें आपको परेशानी से बचाती हैं। पहली, सर्वर का वर्ज़न पैकेज के वर्ज़न से मिलाकर रखें, ताकि server.json में 1.2.3 npm पर 1.2.3 से मेल खाए। दूसरी, अगर आपको पैकेज को छुए बिना सिर्फ़ registry metadata ठीक करना है, तो 1.2.3-1 जैसा prerelease प्रकाशित करें। एक चेतावनी ध्यान रखें: semver prerelease को उसके regular वर्ज़न से पहले रखता है, इसलिए 1.2.3 के बाद 1.2.3-1 प्रकाशित करने पर उसे latest के रूप में चिह्नित नहीं किया जाएगा।

remotes वाले रिमोट सर्वर

होस्टेड सर्वर packages के बदले, या उसके साथ, एक remotes array इस्तेमाल करते हैं:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.example/acme-analytics",
  "description": "Real-time business intelligence and reporting platform",
  "version": "2.0.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://analytics.example.com/mcp",
      "headers": [
        {
          "name": "Authorization",
          "description": "Bearer token for your account",
          "isRequired": true,
          "isSecret": true
        }
      ]
    }
  ]
}

प्रॉम्प्ट कॉपी करें

Remote अपने URL पर सार्वजनिक रूप से पहुँच योग्य होना चाहिए। Streamable HTTP को प्राथमिकता दें; SSE transport deprecated है, इसलिए "sse" remote सिर्फ़ मौजूदा क्लाइंट्स के लिए जोड़ें। Multi-tenant सेटअप https://{tenant_id}.analytics.example.com/mcp जैसे URL variables इस्तेमाल कर सकते हैं, जिनमें से हर एक isRequired, default या choices के साथ वर्णित होता है। और अगर आप पैकेज और remote दोनों भेजते हैं, तो दोनों सूचीबद्ध करें: होस्ट ऐप वह इंस्टॉल तरीका चुनता है जो उसे पसंद है।

साबित करें कि पैकेज आपका है

Registry जाँचती है कि पैकेज सचमुच उस नाम का है जिसे आप दावा कर रहे हैं। यह जाँच छोड़ने पर प्रकाशन "Registry validation failed for package" के साथ विफल हो जाता है। हर पैकेज प्रकार का अपना proof होता है।

हर पैकेज प्रकार के लिए एक जाँच

npm के लिए, package.json में यह ऐसा दिखता है:

{
  "name": "@my-username/mcp-weather-server",
  "version": "1.0.1",
  "mcpName": "io.github.my-username/weather"
}

प्रॉम्प्ट कॉपी करें

कुछ बारीकियों पर लोग अटक जाते हैं। npm की जाँच सिर्फ़ सार्वजनिक npm रजिस्ट्री का इस्तेमाल करती है, और PyPI व NuGet भी अपनी आधिकारिक रजिस्ट्री तक सीमित हैं। crates.io HTML टिप्पणियाँ हटा देता है, इसलिए Cargo का टोकन दिखने वाला टेक्स्ट होना चाहिए, छिपी टिप्पणी नहीं। कंटेनर इमेज के लिए identifier registry/namespace/repository:tag के अनुसार होता है, और समर्थित होस्ट हैं Docker Hub, GitHub Container Registry (ghcr.io), Google Artifact Registry, Azure Container Registry और Microsoft Container Registry। GitHub या GitLab रिलीज़ पर होस्ट की गई MCPB फ़ाइलों के लिए हैश openssl dgst -sha256 your-file.mcpb से निकालें। रजिस्ट्री उस हैश की पुष्टि नहीं करती, लेकिन क्लाइंट इंस्टॉल करने से पहले करते हैं।

💡 टिप: server.json में सर्वर का नाम और पैकेज के अंदर का proof अक्षर-दर-अक्षर मेल खाने चाहिए। एक भटका हुआ capital letter भी validation विफल करने के लिए काफ़ी है।

अपने terminal से प्रकाशित करें

GitHub से लॉगिन करें

अपने प्रोजेक्ट फ़ोल्डर से login चलाएँ:

mcp-publisher login github

प्रॉम्प्ट कॉपी करें

CLI एक बार इस्तेमाल होने वाला कोड और एक URL प्रिंट करता है:

To authenticate, please:
1. Go to: https://github.com/login/device
2. Enter code: ABCD-1234
3. Authorize this application
Waiting for authorization...

प्रॉम्प्ट कॉपी करें

लिंक खोलें, code paste करें, approve करें, और terminal लॉगिन की पुष्टि कर देगा। अगर बाद में "Invalid or expired Registry JWT token" दिखे, तो session समाप्त हो चुका है। लॉगिन दोबारा चलाएँ।

प्रकाशित करें और सत्यापित करें

पैकेज npm पर लाइव हो और server.json सेव हो जाए, तब प्रकाशित करें:

mcp-publisher publish

प्रॉम्प्ट कॉपी करें

एक स्वस्थ run registry URL और आपके सर्वर का नाम उसके वर्ज़न के साथ प्रिंट करता है। इसे public API के ज़रिए सत्यापित करें:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.my-username/weather"

प्रॉम्प्ट कॉपी करें

आपके सर्वर का metadata उस JSON में दिखना चाहिए जो वापस आता है। डाउनस्ट्रीम marketplaces अपने शेड्यूल पर refresh होते हैं, इसलिए वहाँ लिस्टिंग दिखने की उम्मीद करने से पहले उन्हें थोड़ा समय दें, और github.com/mcp पर भी उसे ढूँढें।

अपडेट भी इसी रास्ते पर चलते हैं। पैकेज का वर्ज़न बढ़ाएँ, उसे npm पर प्रकाशित करें, server.json को उसी के अनुसार बढ़ाएँ, और mcp-publisher publish फिर से चलाएँ। हर प्रकाशन अपना अलग, अपरिवर्तनीय वर्ज़न होता है, और registry सबसे नए semantic वर्ज़न को latest के रूप में चिह्नित करती है, ताकि मौजूदा रिलीज़ माँगने वाले क्लाइंट्स को सही वर्ज़न मिले।

GitHub Actions से रिलीज़ भेजें

टैग्ड रिलीज़ वर्कफ़्लो

एक बार मैन्युअल run काम कर जाए, तो उसे CI में ले जाएँ, ताकि हर version tag पैकेज और registry एंट्री को साथ-साथ प्रकाशित करे। यह वर्कफ़्लो GitHub OIDC इस्तेमाल करता है, वही तरीका जो docs सुझाते हैं:

name: Publish to MCP Registry

on:
  push:
    tags: ["v*"]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v5

      - name: Set up Node.js
        uses: actions/setup-node@v5
        with:
          node-version: "lts/*"

      - name: Install dependencies
        run: npm ci

      - name: Build package
        run: npm run build --if-present

      - name: Publish package to npm
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

      - name: Install mcp-publisher
        run: |
          curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher

      - name: Authenticate to MCP Registry
        run: ./mcp-publisher login github-oidc

      - name: Publish server to MCP Registry
        run: ./mcp-publisher publish

प्रॉम्प्ट कॉपी करें

रिलीज़ दो कमांड से होती है: git tag v1.0.0 और git push origin v1.0.0। एक चीज़ टेम्पलेट वैकल्पिक छोड़ता है, और वह है वर्ज़न बढ़ाना। अगर server.json में hardcoded वर्ज़न है, तो registry दोबारा प्रकाशन को अस्वीकार कर देगी, इसलिए publish चरण से पहले उसे tag से सेट करें। एक single-package सर्वर के लिए यह jq लाइन दोनों वर्ज़न फ़ील्ड अपडेट करती है:

VERSION=${GITHUB_REF#refs/tags/v}
jq --arg v "$VERSION" '.version = $v | .packages[0].version = $v' server.json > server.tmp && mv server.tmp server.json

प्रॉम्प्ट कॉपी करें

कौन से secrets चाहिए

• GitHub OIDC: रजिस्ट्री का कोई सीक्रेट नहीं चाहिए। आपको सिर्फ़ id-token: write अनुमति चाहिए।
• GitHub पर्सनल एक्सेस टोकन: इसे सीक्रेट के रूप में स्टोर करें और mcp-publisher login github --token चलाएँ, read:org और read:user स्कोप के साथ।
• DNS लॉगिन: अपनी Ed25519 जोड़ी का प्राइवेट हिस्सा सीक्रेट के रूप में स्टोर करें और उसे mcp-publisher login dns को दें।
• पैकेज रजिस्ट्री: ऊपर के वर्कफ़्लो को npm publish के लिए एक NPM_TOKEN सीक्रेट भी चाहिए।

उपयोगकर्ताओं के देखने से पहले errors ठीक करें

ज़्यादातर विफल प्रकाशन इन पाँच संदेशों में से किसी एक पर सिमट जाते हैं:

हर रिलीज़ से पहले यह छोटी सूची देखें:

• server.json में name mcpName के बराबर हो (या README token, या image label के बराबर)।
• server.json में पैकेज का वर्ज़न npm, PyPI या आपके container host पर पहले से मौजूद हो।
• सर्वर version पहले कभी प्रकाशित न हुआ हो, और वह range न हो।
• कोई भी remote URL सिर्फ़ आपके office नेटवर्क से नहीं, सार्वजनिक इंटरनेट से जवाब दे।
• सर्वर सार्वजनिक उपयोग के लिए बना हो। Private सर्वर private registry में रहने चाहिए।

PicassoIA के साथ ड्राफ़्ट बनाएँ और इलस्ट्रेट करें

server.json के लिए LLM एक तेज़ पहला ड्राफ़्ट बनाने वाली मशीन है, बशर्ते फ़ैसला registry करे। PicassoIA पर ऐसे लार्ज लैंग्वेज मॉडल होस्ट हैं जिन्हें आप सीधे ब्राउज़र से इस्तेमाल कर सकते हैं, जिनमें Claude Sonnet 5, GPT 5.6 Sol और Gemini 3.5 Flash शामिल हैं।

PicassoIA पर Sonnet 5 कैसे इस्तेमाल करें

1. PicassoIA पर Claude Sonnet 5 पेज खोलें और नई chat शुरू करें।
2. अपने package.json फ़ील्ड (नाम, वर्ज़न, विवरण, repository) और mcp-publisher init द्वारा बनाई गई $schema लाइन चिपकाएँ।
3. सिर्फ़ JSON माँगें, मॉडल से कहें कि $schema को न छुए, और गढ़े गए fields पर रोक लगाएँ।
4. नतीजा server.json में कॉपी करें, फिर आँख से जाँचें कि name आपके mcpName के बराबर है।
5. mcp-publisher publish चलाएँ। अगर validation शिकायत करे, तो सटीक error chat में वापस चिपकाएँ।

स्रोत के साथ छोटे प्रॉम्प्ट, लंबे विवरण वाले प्रॉम्प्ट से बेहतर काम करते हैं, क्योंकि जब मॉडल को असली फ़ाइल नहीं दिखती, तो वह विश्वसनीय लगने वाले fields खुद गढ़ लेता है। Actions वर्कफ़्लो का स्कैफ़ोल्ड भी चाहिए? उसके लिए GPT 5.6 Sol एक अच्छी दूसरी राय है।

PicassoIA एक developer API भी चलाता है, और यह दिखाने के लिए अच्छा उदाहरण है कि environmentVariables किस काम आते हैं। API https://api.picassoia.com/v1 पर है और दूसरे prediction APIs की तरह काम करता है: prediction बनाएँ, उसकी स्थिति poll करें, फिर परिणाम लें, और हर account पर एक साथ अधिकतम 5 predictions (अक्टूबर 2026 की शुरुआत तक)। एक काल्पनिक wrapper सर्वर अपने पैकेज के अंदर इस तरह की एंट्री के ज़रिए हर उपयोगकर्ता से उसका अपना credential एक बार माँगेगा:

"environmentVariables": [
  {
    "name": "PICASSOIA_TOKEN",
    "description": "Bearer credential for api.picassoia.com/v1",
    "isRequired": true,
    "isSecret": true,
    "format": "string"
  }
]

प्रॉम्प्ट कॉपी करें

Registry की एंट्री सिर्फ़ टेक्स्ट होती है, लेकिन README, सोशल कार्ड और लॉन्च पोस्ट, सबको तस्वीरें चाहिए। PicassoIA खोलें, कोई इमेज या वीडियो मॉडल चुनें, और अपने सर्वर के लिए एक हीरो इमेज या एक छोटा डेमो क्लिप जनरेट करें। पूरा मॉडल कैटलॉग picassoia.com/en/all-models पर है। तीन प्रॉम्प्ट आज़माएँ, सबसे अच्छा चुनें, और उसे अपने पहले mcp-publisher publish के साथ लगाएँ।