Neon

आधिकारिक

Neon सर्वरलेस Postgres प्लेटफ़ॉर्म के साथ इंटरैक्ट करें

Neon MCP के साथ आप क्या कर सकते हैं?

  • प्रोजेक्ट और ब्रांच बनाएँ — सहायक से नया Postgres प्रोजेक्ट या स्कीमा में बदलाव के लिए feature-x जैसी ब्रांच बनाने को कहें।
  • SQL क्वेरी चलाएँ — Neon डेटाबेस पर एकल क्वेरी या कई स्टेटमेंट वाले ट्रांज़ैक्शन चलाएँ और परिणामस्वरूप पंक्तियाँ प्राप्त करें।
  • स्कीमा की जाँच करें — डेटाबेस में टेबलों की सूची बनाएँ और किसी टेबल के कॉलम, डेटा प्रकारों और बाधाओं का विवरण देखें।
  • सुरक्षित रूप से माइग्रेट करें — अस्थायी ब्रांच पर माइग्रेशन तैयार करें, फिर उसे पूरा करके बदलाव मुख्य ब्रांच पर लागू करें।
  • धीमी क्वेरी को बेहतर बनाएँ — धीमी क्वेरी खोजें, निष्पादन योजनाएँ देखें और अस्थायी ब्रांच पर सुझाए गए अनुकूलनों को परखें।
  • प्रोजेक्ट का सारांश देखें — Neon प्रोजेक्टों की सूची बनाएँ और ब्रांचों का विवरण देखें, ताकि पता चले कि हर प्रोजेक्ट में कौन-से डेटाबेस और टेबल हैं।

होस्ट किया गया MCP सर्वर

npx add-mcp 'https://mcp.neon.tech/mcp'

Claude Code, Codex, Cursor और अन्य में इंस्टॉल होता है

दस्तावेज़

Neon Logo fallback

Neon MCP Server

Install MCP Server in Cursor Add to Kiro

Neon MCP Server एक ओपन-सोर्स टूल है, जो आपको प्राकृतिक भाषा में Neon पर अपने Lakebase Postgres डेटाबेस के साथ इंटरैक्ट करने देता है।

License: MIT

Model Context Protocol (MCP) एक मानकीकृत प्रोटोकॉल है, जिसे बड़े भाषा मॉडल (LLM) और बाहरी सिस्टम के बीच संदर्भ प्रबंधित करने के लिए डिज़ाइन किया गया है। यह रिपॉज़िटरी Neon के लिए एक रिमोट MCP Server उपलब्ध कराती है।

Neon का MCP server प्राकृतिक भाषा में दिए गए अनुरोधों और Neon API के बीच एक सेतु का काम करता है। MCP पर निर्मित यह server आपके अनुरोधों को ज़रूरी API कॉल में बदलता है, जिससे आप प्रोजेक्ट और ब्रांच बनाने, क्वेरी चलाने और डेटाबेस माइग्रेशन करने जैसे काम आसानी से प्रबंधित कर सकते हैं।

Neon MCP server की कुछ प्रमुख सुविधाएँ:

  • प्राकृतिक भाषा में इंटरैक्शन: सहज, संवादात्मक कमांड का उपयोग करके Neon डेटाबेस प्रबंधित करें।
  • सरल डेटाबेस प्रबंधन: SQL लिखे बिना या सीधे Neon API का उपयोग किए बिना जटिल कार्रवाइयाँ करें।
  • गैर-डेवलपरों के लिए सुलभता: अलग-अलग तकनीकी पृष्ठभूमि वाले उपयोगकर्ताओं को Neon डेटाबेस के साथ इंटरैक्ट करने में सक्षम बनाएँ।
  • डेटाबेस माइग्रेशन का समर्थन: प्राकृतिक भाषा के ज़रिए शुरू किए गए डेटाबेस स्कीमा बदलावों के लिए Neon की ब्रांचिंग क्षमताओं का लाभ उठाएँ।

उदाहरण के लिए, Claude Code या किसी भी MCP Client में, आप Neon के साथ काम करने के लिए प्राकृतिक भाषा का उपयोग कर सकते हैं, जैसे:

  • Let's create a new Postgres database, and call it "my-database". Let's then create a table called users with the following columns: id, name, email, and password.
  • I want to run a migration on my project called "my-project" that alters the users table to add a new column called "created_at".
  • Can you give me a summary of all of my Neon projects and what data is in each one?

[!WARNING]
Neon MCP Server के सुरक्षा संबंधी विचार
Neon MCP Server प्राकृतिक भाषा में दिए गए अनुरोधों के ज़रिए डेटाबेस प्रबंधन की शक्तिशाली क्षमताएँ देता है। कार्रवाई करने से पहले LLM द्वारा अनुरोधित कार्रवाइयों की हमेशा समीक्षा करें और उन्हें अधिकृत करें। सुनिश्चित करें कि Neon MCP Server तक केवल अधिकृत उपयोगकर्ताओं और एप्लिकेशन की पहुँच हो।

Neon MCP Server केवल स्थानीय डेवलपमेंट और IDE इंटीग्रेशन के लिए है। हम प्रोडक्शन परिवेशों में Neon MCP Server का उपयोग करने की अनुशंसा नहीं करते। यह शक्तिशाली कार्रवाइयाँ कर सकता है, जिनसे अनजाने या अनधिकृत बदलाव हो सकते हैं।

अधिक जानकारी के लिए, MCP सुरक्षा मार्गदर्शन → देखें।

Neon MCP Server सेट अप करना

Neon MCP Server सेट अप करने के कुछ विकल्प हैं:

  1. API Key के साथ त्वरित सेटअप (Cursor, VS Code और Claude Code): एक ही कमांड से Neon का MCP Server, agent skills और VS Code एक्सटेंशन अपने-आप कॉन्फ़िगर करने के लिए neon@latest init चलाएँ।
  2. रिमोट MCP Server (OAuth आधारित प्रमाणीकरण): प्रमाणीकरण के लिए OAuth का उपयोग करके Neon के प्रबंधित MCP server से कनेक्ट करें। यह तरीका अधिक सुविधाजनक है, क्योंकि इसमें API keys प्रबंधित करने की ज़रूरत नहीं होती। इसके अलावा, नई सुविधाएँ और सुधार जारी होते ही आपको अपने-आप मिल जाएँगे।
  3. रिमोट MCP Server (API Key आधारित प्रमाणीकरण): प्रमाणीकरण के लिए API key का उपयोग करके Neon के प्रबंधित MCP server से कनेक्ट करें। यह तरीका तब उपयोगी है, जब आप किसी रिमोट agent को Neon से कनेक्ट करना चाहते हैं और OAuth उपलब्ध नहीं है। इसके अलावा, नई सुविधाएँ और सुधार जारी होते ही आपको अपने-आप मिल जाएँगे।

आवश्यकताएँ

  • एक MCP Client एप्लिकेशन।
  • एक Neon खाता।
  • Node.js (>= v18.0.0): nodejs.org से डाउनलोड करें।
  • अगर IP Allow सक्षम है, तो 34.192.103.46 और 23.22.233.166 को अपनी allowlist में जोड़ें (mcp.neon.tech स्थिर IPs)।

डेवलपमेंट के लिए, आपको Node.js 22+ की ज़रूरत होगी (pnpm, Corepack के ज़रिए उपलब्ध है — इसे सक्रिय करने के लिए corepack enable चलाएँ)।

विकल्प 1. API Key के साथ त्वरित सेटअप

क्या आप मैन्युअल रूप से API key नहीं बनाना चाहते?

एक ही कमांड से Neon का MCP Server अपने-आप कॉन्फ़िगर करने के लिए neon@latest init चलाएँ:

npx neon@latest init

यह Cursor, VS Code (GitHub Copilot) और Claude Code के साथ काम करता है। यह OAuth के ज़रिए प्रमाणीकरण करेगा, आपके लिए Neon API key बनाएगा और आपके एडिटर को अपने-आप कॉन्फ़िगर करेगा।

विकल्प 2. रिमोट होस्टेड MCP Server (OAuth आधारित प्रमाणीकरण)

प्रमाणीकरण के लिए OAuth का उपयोग करके Neon के प्रबंधित MCP server से कनेक्ट करें। यह सबसे आसान सेटअप है, इसके लिए इस server को स्थानीय रूप से इंस्टॉल करने की ज़रूरत नहीं है और client में Neon API key कॉन्फ़िगर करने की भी आवश्यकता नहीं है।

अपने workspace में पहचाने गए सभी agents और editors के लिए Neon MCP Server जोड़ने हेतु यह कमांड चलाएँ:

npx add-mcp "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema"

यह URL projects, branches, compute endpoints, querying और schema प्रकाशित करता है। /api/list-tools?category=projects&category=branches&category=endpoints&category=querying&category=schema के साथ इसका पूर्वावलोकन करें। बिना फ़िल्टर वाला URL हर श्रेणी प्रकाशित करता है:

npx add-mcp https://mcp.neon.tech/mcp

Neon MCP Server को केवल प्रोजेक्ट-स्कोप्ड सूची के बजाय वैश्विक MCP server सूची में जोड़ने के लिए -g फ़्लैग जोड़ें।

इसके बजाय, आप अपने client की MCP server कॉन्फ़िगरेशन फ़ाइल (जैसे, mcp.json, mcp_config.json) में निम्नलिखित "Neon" एंट्री जोड़ सकते हैं:

{
  "mcpServers": {
    "Neon": {
      "type": "http",
      "url": "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema"
    }
  }
}

Kiro: अपनी Kiro MCP कॉन्फ़िगरेशन फ़ाइल में निम्नलिखित जोड़ें (वैश्विक के लिए ~/.kiro/settings/mcp.json, या प्रोजेक्ट-स्कोप्ड के लिए .kiro/settings/mcp.json):

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema"
    }
  }
}

या इस README के शीर्ष पर मौजूद वन-क्लिक इंस्टॉल बटन का उपयोग करें। अधिक जानकारी के लिए, Kiro MCP दस्तावेज़ देखें।

  • अपने MCP client को रीस्टार्ट या रिफ़्रेश करें।
  • आपके ब्राउज़र में OAuth विंडो खुलेगी। अपने Neon खाते तक MCP client को पहुँच देने के लिए निर्देशों का पालन करें।

OAuth-आधारित प्रमाणीकरण के साथ, MCP server डिफ़ॉल्ट रूप से आपके व्यक्तिगत Neon खाते के अंतर्गत आने वाले projects पर काम करेगा। किसी संगठन के projects तक पहुँचने या उन्हें प्रबंधित करने के लिए, आपको MCP client के प्रॉम्प्ट में स्पष्ट रूप से org_id या project_id देना होगा।

विकल्प 3. रिमोट होस्टेड MCP Server (API Key आधारित प्रमाणीकरण)

अगर आपका client इसका समर्थन करता है, तो रिमोट MCP Server Authorization हेडर में API key का उपयोग करके प्रमाणीकरण भी समर्थित करता है।

Neon Console में Neon API key बनाएँ। इसके बाद, अपने workspace में पहचाने गए सभी agents और editors के लिए Neon MCP Server जोड़ने हेतु यह कमांड चलाएँ:

npx add-mcp "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema" --header "Authorization: Bearer <$NEON_API_KEY>"

इसके बजाय, आप अपने client की MCP server कॉन्फ़िगरेशन फ़ाइल (जैसे, mcp.json, mcp_config.json) में निम्नलिखित "Neon" एंट्री जोड़ सकते हैं:

{
  "mcpServers": {
    "Neon": {
      "type": "http",
      "url": "https://mcp.neon.tech/mcp?category=projects&category=branches&category=endpoints&category=querying&category=schema",
      "headers": {
        "Authorization": "Bearer <$NEON_API_KEY>"
      }
    }
  }
}

केवल संगठन के अंतर्गत आने वाले projects तक पहुँच सीमित करने के लिए संगठन की API key दें।

स्कोप और केवल-पढ़ने का मोड

Neon MCP OAuth scopes read और write का विज्ञापन करता है। आपका MCP client इनका अनुरोध कर सकता है, या आप OAuth अनुमतियों के UI में इन्हें चुन सकते हैं। अगर client फिर भी * भेजता है, तो इसे लिखने की अनुमति वाला माना जाएगा।

केवल-पढ़ने का मोड उपलब्ध टूल सीमित करता है और प्रोजेक्ट, ब्रांच बनाने या माइग्रेशन चलाने जैसी लिखने की कार्रवाइयों को अक्षम करता है। केवल-पढ़ने वाले टूल में projects की सूची बनाना, स्कीमा का विवरण देखना, डेटा क्वेरी करना और परफ़ॉर्मेंस मेट्रिक्स देखना शामिल है।

आप केवल-पढ़ने का मोड दो तरीकों से सेट कर सकते हैं:

  1. डिफ़ॉल्ट MCP URL (बदलने योग्य सहमति): https://mcp.neon.tech/mcp के साथ कनेक्ट करें और प्राधिकरण पेज पर Allow writes का चेक हटाएँ। वहाँ आप एक project, SQL के लिए Postgres role और टूल श्रेणियों का सबसेट भी चुन सकते हैं।
  2. पैरामीटर वाला MCP URL (निश्चित सहमति): MCP server URL में readonly, projectId, category और/या roleName जोड़ें। प्राधिकरण पेज उस अनुमति की पुष्टि करता है और बदलाव के विकल्प नहीं देता। अनुमति बदलने के लिए URL बदलें और फिर से प्राधिकृत करें।
{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?readonly=true"
    }
  }
}

क्वेरी पैरामीटर का व्यवहार:

  • API key फ़्लो: केवल-पढ़ने का मोड सक्षम करने का तरीका readonly=true है (इस फ़्लो में OAuth scope का आदान-प्रदान नहीं होता)। URL में किए गए बदलाव अगले अनुरोध पर लागू होते हैं।
  • OAuth फ़्लो: MCP URL में मौजूद projectId, category, readonly और roleName एक निश्चित अनुमति देते हैं, जिसकी पुष्टि प्राधिकरण के समय होती है। उस पेज पर readonly=true को लिखने की अनुमति तक नहीं बढ़ाया जा सकता। टोकन जारी होने के बाद, URL बदलने से उस टोकन की अनुमति नहीं बढ़ती; फिर से प्राधिकृत करें।

OAuth पंजीकरण के लिए, x-read-only बदलने योग्य सहमति पर लिखने की अनुमति का शुरुआती डिफ़ॉल्ट है। यह पुष्टि को लॉक नहीं करता और न ही readonly=false शामिल करने वाले पैरामीटर वाले URL की अनुमति को कम करता है। API-key अनुरोधों में हर अनुरोध पर x-read-only का पालन होता है, जो readonly क्वेरी पैरामीटर से नीचे लागू होता है।

ध्यान दें: केवल-पढ़ने का मोड उपलब्ध टूल सीमित करता है। run_sql उपलब्ध रहता है और हर क्वेरी को READ ONLY ट्रांज़ैक्शन में चलाता है। run_sql_transaction उपलब्ध नहीं है; हर स्टेटमेंट को run_sql के साथ चलाएँ। ये कॉल अलग-अलग चलती हैं और कोई ट्रांज़ैक्शन साझा नहीं करतीं। ट्रांज़ैक्शन के अर्थ बनाए रखने के लिए, लिखने की अनुमति वाले कनेक्शन का उपयोग करें।

पहुँच नियंत्रण के लिए URL क्वेरी पैरामीटर

अनुमति का संदर्भ (स्कोप श्रेणियाँ, project स्कोपिंग, केवल-पढ़ने का मोड, पिन किया गया Postgres role) MCP server URL पर URL क्वेरी पैरामीटर के ज़रिए कॉन्फ़िगर किया जाता है। API-key अनुरोधों में ये पैरामीटर हर अनुरोध पर लागू होते हैं। OAuth टोकन में प्राधिकरण के समय पुष्टि की गई या संपादित की गई अनुमति संग्रहीत होती है।

Paramविवरणउदाहरण
readonlyकेवल-पढ़ने का मोड सक्षम करें (true/false)?readonly=true
categoryविशिष्ट टूल श्रेणियों तक सीमित करें (दोहराया जा सकता है या CSV)?category=querying&category=schema
projectIdसभी कार्रवाइयों को एक project तक सीमित करें?projectId=proj-123
roleNameसभी SQL को owner के बजाय इस Postgres role के रूप में चलाएँ?roleName=app_reader

केवल-पढ़ने और project-स्कोप्ड का उदाहरण:

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?readonly=true&projectId=my-project-id"
    }
  }
}

श्रेणी-फ़िल्टर वाला उदाहरण (केवल querying और schema टूल):

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?category=querying&category=schema"
    }
  }
}

पिन किए गए Postgres role का उदाहरण (केवल-पढ़ने का मोड, एक project, SQL को app_reader के रूप में चलाना):

{
  "mcpServers": {
    "Neon": {
      "url": "https://mcp.neon.tech/mcp?readonly=true&projectId=my-project-id&roleName=app_reader"
    }
  }
}

roleName पूरे कनेक्शन के लिए Postgres लॉगिन role को पिन करता है। server द्वारा आपके लिए चलाया जाने वाला हर SQL (run_sql, run_sql_transaction, explain_sql_statement, get_database_tables, describe_table_schema, describe_branch, list_slow_queries, inspect_database, और माइग्रेशन तथा क्वेरी ट्यूनिंग के अंदर का SQL) उसी role के रूप में लॉग इन करता है, इसलिए Postgres की अनुमतियाँ तय करती हैं कि agent क्या पढ़ या बदल सकता है। इसके बिना, SQL डेटाबेस owner के रूप में चलता है। केवल-पढ़ने का मोड अब भी क्वेरी को READ ONLY ट्रांज़ैक्शन में चलाता है; पिन किया गया role एक ऐसी सीमा जोड़ता है जिसे Postgres लॉगिन पर लागू करता है, इसलिए ट्रांज़ैक्शन से बाहर निकलने वाला SQL भी केवल उसी role की अनुमतियों तक सीमित रहता है।

  • सर्वर भूमिका के क्रेडेंशियल को आंतरिक रूप से हल करता है और उन्हें कभी वापस नहीं करता। get_connection_string पिन किए गए कनेक्शन पर उपलब्ध नहीं है।
  • पिन की गई भूमिका से अलग role_name टूल आर्ग्युमेंट अस्वीकार कर दिया जाता है। इसे छोड़ने पर पिन की गई भूमिका इस्तेमाल होती है, मालिक की भूमिका कभी नहीं।
  • यदि भूमिका मौजूद नहीं है या लॉग इन नहीं कर सकती (उदाहरण के लिए ALTER ROLE … NOLOGIN), तो कोई SQL चलने से पहले कॉल विफल हो जाती है। यह किसी दूसरी भूमिका के रूप में दोबारा प्रयास नहीं करती।
  • मान एक सटीक Postgres भूमिका नाम होना चाहिए: अक्षर, अंक, _ या $, जिसकी शुरुआत किसी अक्षर या _ से हो और लंबाई अधिकतम 63 वर्ण हो। अन्य कोई भी मान (खाली, दोहराया हुआ, उद्धृत, हाइफ़न वाला) अनदेखा करने के बजाय 400 के साथ अस्वीकार कर दिया जाता है।
  • भूमिका लॉग इन कर सकने वाली (LOGIN) होनी चाहिए और आपके द्वारा क्वेरी की जाने वाली हर शाखा पर मौजूद होनी चाहिए। SQL में बनाई गई भूमिकाएँ (CREATE ROLE app_reader LOGIN PASSWORD '…') काम करती हैं, और Neon Console या API में बनाई गई भूमिकाएँ भी। भूमिका को उपयोग के लिए उपयोगी बनाने का तरीका है कि उसे आवश्यक विशेषाधिकार दिए जाएँ, और उससे अधिक नहीं: केवल-पढ़ने वाले एजेंटों के लिए, जिन तालिकाओं को उन्हें देखना चाहिए उन पर SELECT दें और इसे neon_superuser में न जोड़ें। access: "read_only" के साथ create_postgres_role ऐसे कनेक्शन से ऐसी भूमिका बनाता है जिसमें roleName नहीं है; इसके द्वारा बनाई गई जिन भूमिकाओं में access नहीं है, वे neon_superuser में शामिल हो जाती हैं।
  • OAuth: MCP URL पर roleName एक निश्चित ग्रांट बनाता है। प्राधिकरण पृष्ठ भूमिका दिखाता है और जारी किया गया टोकन रिफ़्रेश के दौरान भी इसे बनाए रखता है। बाद में URL बदलने से टोकन नहीं बदलता; फिर से प्राधिकृत करें। डिफ़ॉल्ट URL (जिसमें सहमति संपादित की जा सकती है) के साथ, इसके बजाय वैकल्पिक Postgres role फ़ील्ड में भूमिका दर्ज करें; डेटाबेस मालिक को बनाए रखने के लिए इसे खाली छोड़ें। इस विकल्प से पहले जारी किए गए टोकन में कोई पिन की गई भूमिका नहीं होती और वे पहले की तरह काम करते हैं।
  • API key: हर अनुरोध पर URL से भूमिका पढ़ी जाती है। जो कोई कनेक्शन URL संपादित कर सकता है और जिसके पास API key है, वह इसे बदल या हटा सकता है, इसलिए URL को ऐसी कॉन्फ़िगरेशन में रखें जिसे एजेंट नियंत्रित न करता हो।
  • पिन केवल SQL कनेक्शन पर लागू होता है। Management API टूल अब भी API key या OAuth टोकन की अपनी पहुँच के साथ काम करते हैं; उदाहरण के लिए, compare_database_schema की गणना Neon API करती है और यह भूमिका के ग्रांट से सीमित नहीं होता। उन टूल को भी सीमित करने के लिए roleName को readonly=true और category के साथ इस्तेमाल करें।

आप /api/list-tools एंडपॉइंट का उपयोग करके किसी भी कॉन्फ़िगरेशन के लिए दिखने वाले टूल का पूर्वावलोकन कर सकते हैं (प्रमाणीकरण आवश्यक नहीं):

curl "https://mcp.neon.tech/api/list-tools?readonly=true&category=querying"
केवल-पढ़ने के मोड में उपलब्ध टूल

कस्टम टूल: list_organizations, describe_branch, run_sql, get_database_tables, describe_table_schema, list_slow_queries, explain_sql_statement, inspect_database, get_neon_auth_config, search, fetch, search_docs, get_doc, send_feedback, list_incidents।

जनरेट किए गए Management API टूल जो GET हैं और सीक्रेट वापस नहीं करते, साथ ही query_logs (POST, केवल-पढ़ने वाला)। सटीक सेट का पूर्वावलोकन /api/list-tools?readonly=true से करें।

ऐसे टूल जिन्हें लिखने की पहुँच चाहिए:

  • जनरेट किए गए Management API राइट (create_project, create_branch, delete_project, …)
  • get_connection_string (कनेक्शन स्ट्रिंग में विशेषाधिकार-युक्त भूमिका का पासवर्ड होता है, इसलिए इसे केवल-पढ़ने के मोड में रोका जाता है; इसके बजाय इसे Neon Console से कॉपी करें)
  • run_sql_transaction (इसके स्टेटमेंट एक ही सेशन में चलते हैं, इसलिए COMMIT या SET TRANSACTION READ WRITE स्टेटमेंट केवल-पढ़ने वाले ट्रांज़ैक्शन को समाप्त कर देगा)
  • prepare_database_migration, complete_database_migration
  • prepare_query_tuning, complete_query_tuning

ट्रांसपोर्ट संगतता

https://mcp.neon.tech/mcp स्टेटलेस Streamable HTTP का उपयोग करता है। यह MCP 2026-07-28 प्रोटोकॉल और 2025-युग के क्लाइंट के लिए स्टेटलेस फ़ॉलबैक का समर्थन करता है। पुराने HTTP+SSE /sse और /message एंडपॉइंट 410 Gone लौटाते हैं।

Streamable HTTP क्लाइंट को https://mcp.neon.tech/mcp से कनेक्ट करें। केवल स्थानीय stdio सर्वर का समर्थन करने वाले क्लाइंट के लिए, क्लाइंट कॉन्फ़िगरेशन में यह जोड़ें ताकि mcp-remote Streamable HTTP सेतु का काम करे:

{
  "mcpServers": {
    "Neon": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.neon.tech/mcp"]
    }
  }
}

गलत फ़ॉर्मैट वाले Origin हेडर वाले अनुरोध को 403 Forbidden मिलता है। किसी भी सीरियलाइज़ किए गए origin को स्वीकार किया जाता है, जिसमें वेब पेज, ब्राउज़र एक्सटेंशन, डेस्कटॉप वेबव्यू और null शामिल हैं, इसलिए ब्राउज़र-आधारित क्लाइंट कनेक्ट कर सकते हैं। Origin के बिना आने वाले अनुरोधों पर इसका कोई प्रभाव नहीं पड़ता।

रिमोट सर्वर आर्किटेक्चर

रिमोट सर्वर Vercel पर mcp.neon.tech में Next.js App Router एप्लिकेशन के रूप में चलता है।

[!NOTE] रूट / पथ Neon MCP Server docs पर रीडायरेक्ट करता है। कोई लैंडिंग पेज नहीं है।

मुख्य कार्यान्वयन क्षेत्र:

  • app/api/[transport]/route.ts: स्टेटलेस Streamable HTTP एंडपॉइंट (/mcp)
  • app/api/authorize/, app/callback/, app/api/token/, app/api/revoke/: OAuth फ़्लो एंडपॉइंट
  • app/.well-known/: OAuth डिस्कवरी मेटाडेटा एंडपॉइंट
  • mcp/: MCP सर्वर, टूल, हैंडलर, एनालिटिक्स और Sentry इंटीग्रेशन
  • lib/: Next.js-संगत हेल्पर (OAuth, कॉन्फ़िगरेशन, त्रुटि प्रबंधन)
  • mcp/utils/read-only.ts: केवल-पढ़ने का मोड और स्कोप प्रबंधन

गाइड

सुविधाएँ

समर्थित टूल

Neon MCP Server निम्नलिखित कार्रवाइयाँ उपलब्ध कराता है, जिन्हें MCP क्लाइंट के सामने "टूल" के रूप में प्रस्तुत किया जाता है। आप प्राकृतिक भाषा के निर्देशों का उपयोग करके अपने Neon प्रोजेक्ट और डेटाबेस के साथ इंटरैक्ट करने के लिए इन टूल का उपयोग कर सकते हैं।

टूल स्कोप मेटाडेटा

हर टूल परिभाषा में एक scope श्रेणी शामिल होती है, जिसका उपयोग ग्रांट-आधारित टूल फ़िल्टरिंग और सहमति UX के लिए किया जाता है। मौजूदा श्रेणियाँ हैं:

  • projects
  • branches
  • endpoints
  • snapshots
  • schema
  • querying
  • neon_auth
  • data_api
  • observability
  • docs
  • functions
  • storage
  • realtime
  • null (स्कोप श्रेणी के बिना टूल: search, fetch, send_feedback)

नोट:

  • Management API टूल @neon/tools से आते हैं। सिलेक्टर SDK पथ (projects.list) होते हैं; प्रकाशित MCP नाम क्रिया-प्रथम होते हैं (list_projects, delete_project, query_logs)। पुराने नाम वहीं बने रहते हैं जहाँ वे पहले से मौजूद थे (describe_project, create_branch, reset_from_parent, compare_database_schema, provision_neon_auth, provision_neon_data_api, list_branch_computes)।
  • ?category=branches में शाखा, भूमिका और डेटाबेस टूल शामिल हैं (list_postgres_roles, create_postgres_database, …)। branches के लिए पहले से जारी टोकन को वे राइट भी मिल जाते हैं। Compute सूचीकरण ?category=endpoints है। स्नैपशॉट पुनर्स्थापना ?category=snapshots है।
  • प्रोजेक्ट सदस्य और अनुमति संबंधी राइट प्रकाशित नहीं किए जाते। list_project_members और list_project_permissions रीड हैं।
  • स्कीमा टूल (?category=schema) में get_database_tables और describe_table_schema, साथ ही जनरेट किया गया compare_database_schema शामिल है।
  • केवल-पढ़ने का प्रवर्तन अब भी readOnlySafe और सर्वर-साइड केवल-पढ़ने वाले लॉजिक पर निर्भर करता है; scope श्रेणी मेटाडेटा है, अपने आप में रीड/राइट स्विच नहीं।
  • प्रोजेक्ट-स्कोप वाले मोड (?projectId=...) में, प्रोजेक्ट पथ के बिना वाले टूल (list_projects, count_projects, create_project, get_project_consumption, get_branch_consumption, list_organizations, list_regions, search, fetch, …) छिपे रहते हैं। delete_project भी छिपा रहता है।

प्रोजेक्ट प्रबंधन:

  • list_projects: Neon प्रोजेक्ट की सूची देता है। limit लौटाए जाने वाले आइटम की अधिकतम संख्या तय करता है।
  • count_projects: किसी संगठन में सक्रिय प्रोजेक्ट की संख्या लौटाता है। org_id वैकल्पिक है और इसे उसी तरह हल किया जाता है जैसे list_projects पर।
  • describe_project: ID ({ "project_id": "…" }) के आधार पर Neon प्रोजेक्ट प्राप्त करता है।
  • get_project_consumption, get_branch_consumption: प्रति प्रोजेक्ट या प्रति शाखा खपत मेट्रिक्स, जिन्हें बिलिंग अवधि के अनुसार समूहित किया जाता है। ये org_id, metrics, from, to और granularity लेते हैं, और इनके लिए Launch, Scale, Agent, Business या Enterprise प्लान आवश्यक है। get_branch_consumption के लिए project_ids भी आवश्यक है; यह extra_branches_month और snapshot_storage_bytes_month मेट्रिक्स को अस्वीकार करता है और Business प्लान पर उपलब्ध नहीं है। पुराने प्लान वाला एंडपॉइंट /consumption_history/projects प्रकाशित नहीं है।
  • create_project: Neon प्रोजेक्ट बनाता है और डिफ़ॉल्ट compute के तैयार होने तक प्रतीक्षा करता है। कनेक्शन स्ट्रिंग नहीं लौटाता। आर्ग्युमेंट { "name": "…", "org_id": "…", "region_id": "…" } हैं। सफल होने के बाद get_connection_string कॉल करें।
  • delete_project: मौजूदा Neon प्रोजेक्ट हटाता है। आर्ग्युमेंट { "project_id": "…" } हैं।
  • list_organizations: उन सभी संगठनों की सूची देता है जिन तक मौजूदा उपयोगकर्ता की पहुँच है। खोज पैरामीटर का उपयोग करके संगठन के नाम या ID के आधार पर वैकल्पिक रूप से फ़िल्टर करें।

शाखा प्रबंधन:

  • list_branches: किसी प्रोजेक्ट की शाखाओं की सूची देता है। शाखा के नाम को br-… ID में बदलने के लिए इसका उपयोग करें।
  • list_credentials, create_credential, revoke_credential, rotate_credential: Object Storage और AI Gateway के लिए शाखा-स्कोप वाले क्रेडेंशियल। reveal कोई टूल नहीं है; रोटेशन सीक्रेट को उसी जगह बदल देता है और यह idempotent नहीं है।
  • create_branch: रीड-राइट compute के साथ शाखा बनाता है और उसके तैयार होने तक प्रतीक्षा करता है। कनेक्शन स्ट्रिंग नहीं लौटाता। आर्ग्युमेंट { "project_id": "…", "name": "feature-x" } हैं। एंडपॉइंट छोड़ने के लिए no_compute: true दें। सफल होने के बाद get_connection_string कॉल करें।
  • reset_from_parent: किसी शाखा को उसकी पैरेंट के मौजूदा HEAD ({ "project_id": "…", "branch_id": "br-…" }) पर रीसेट करता है। शाखा के अलग होने के बाद किए गए राइट हटा देता है। यदि शाखा की चाइल्ड शाखाएँ हैं, तो preserve_under_name आवश्यक है; वे चाइल्ड नई शाखा पर चली जाती हैं। केवल पैरेंट HEAD; किसी समय-बिंदु पर पुनर्स्थापना के लिए restore_snapshot का उपयोग करें।
  • delete_branch: शाखा हटाता है ({ "project_id": "…", "branch_id": "br-…" })।
  • describe_branch: किसी शाखा पर डेटाबेस, स्कीमा, टेबल, व्यू और फ़ंक्शन का ट्री प्राप्त करता है।
  • जनरेट किए गए शाखा टूल branch_id को शाखा ID (br-...) के रूप में लेते हैं, नाम के रूप में नहीं।
  • restore_snapshot: स्नैपशॉट पुनर्स्थापित करता है। किसी मौजूदा शाखा पर पुनर्स्थापित करने के लिए target_branch_id दें; नई शाखा बनाने के लिए इसे छोड़ दें।

Compute एंडपॉइंट (?category=endpoints):

  • list_postgres_endpoints, list_branch_computes, get_postgres_endpoint, create_postgres_endpoint, update_postgres_endpoint, delete_postgres_endpoint, start_postgres_endpoint, suspend_postgres_endpoint, restart_postgres_endpoint

स्नैपशॉट (?category=snapshots):

  • list_snapshots, get_snapshot_schedule, set_snapshot_schedule, create_snapshot, update_snapshot, delete_snapshot, restore_snapshot

स्कीमा (?category=schema):

  • get_database_tables, describe_table_schema
  • compare_database_schema: एक डेटाबेस के SQL स्कीमा की दूसरे शाखा से तुलना करके अंतर दिखाता है। database_name आवश्यक है। base_branch_id छोड़ने पर पैरेंट से तुलना की जाती है। वैकल्पिक lsn, timestamp, base_lsn, base_timestamp केवल किसी समय-बिंदु के लिए हैं।

SQL क्वेरी निष्पादन:

  • get_connection_string: आपका डेटाबेस कनेक्शन स्ट्रिंग लौटाता है।
  • run_sql: किसी निर्दिष्ट Neon डेटाबेस पर एक SQL क्वेरी निष्पादित करता है। पढ़ने और लिखने, दोनों तरह के ऑपरेशन समर्थित हैं। वैकल्पिक role_name डेटाबेस के मालिक के बजाय उस Postgres भूमिका के रूप में लॉग इन करता है, और compute_id कंप्यूट चुनता है; क्रेडेंशियल सर्वर पर ही रहते हैं। ?roleName= वाले कनेक्शन पर, role_name को छोड़ना होगा या उसका मान इससे मेल खाना चाहिए। अधिकतम max_rows पंक्तियों वाला पंक्ति ऐरे लौटाता है (डिफ़ॉल्ट 100, अधिकतम 10,000); यदि पंक्तियाँ काटी गई हों, तो दूसरे कंटेंट ब्लॉक में { totalRowCount, truncated, note } होता है। विफल क्वेरी Postgres SQLSTATE, त्रुटि की स्थिति और उपलब्ध विवरण, संकेत या संदर्भ लौटाती है।
  • run_sql_transaction: Neon डेटाबेस पर एक ही ट्रांज़ैक्शन के भीतर SQL क्वेरी की शृंखला निष्पादित करता है। इसमें run_sql के समान वैकल्पिक role_name, compute_id और max_rows लिए जाते हैं। max_rows हर स्टेटमेंट पर लागू होता है; यदि कोई स्टेटमेंट काटा गया हो, तो दूसरे ब्लॉक में हर स्टेटमेंट का एक सारांश होता है।
  • get_database_tables: निर्दिष्ट Neon डेटाबेस की सभी टेबल सूचीबद्ध करता है।
  • describe_table_schema: किसी विशिष्ट टेबल की स्कीमा परिभाषा प्राप्त करता है, जिसमें कॉलम, डेटा प्रकार और बाधाएँ शामिल हैं।

डेटाबेस माइग्रेशन (स्कीमा में बदलाव):

  • prepare_database_migration: डेटाबेस माइग्रेशन प्रक्रिया शुरू करता है। महत्वपूर्ण रूप से, मुख्य ब्रांच को प्रभावित करने से पहले माइग्रेशन को सुरक्षित रूप से लागू करने और जाँचने के लिए एक अस्थायी ब्रांच बनाता है।
  • complete_database_migration: तैयार डेटाबेस माइग्रेशन को अंतिम रूप देकर मुख्य ब्रांच पर लागू करता है। यह अस्थायी माइग्रेशन ब्रांच के बदलावों को मर्ज करता है और अस्थायी संसाधनों को साफ़ करता है।

SQL क्वेरी और ऑप्टिमाइज़ेशन:

  • inspect_database: किसी ब्रांच पर पहले से तय 15 केवल-पढ़ने वाले Postgres डायग्नोस्टिक्स में से एक चलाता है — रिलेशन और इंडेक्स के आकार, इंडेक्स और सीक्वेंशियल स्कैन का उपयोग, सक्रिय क्वेरी और लॉक, सबसे भारी और सबसे अधिक बार चलने वाली क्वेरी, कैश हिट दर और वर्किंग-सेट आकार, ऑट वैक्यूम और ब्लोट के अनुमान, तथा रेप्लिकेशन की स्थिति। यह neon inspect db CLI कमांड जैसी ही जाँचें करता है। ब्रांच के हर डेटाबेस को शामिल करने के लिए database_name छोड़ दें; किसी एक डेटाबेस की जाँच के लिए उसका नाम दें। इनमें से चार के लिए pg_stat_statements या neon एक्सटेंशन आवश्यक है।
  • list_slow_queries: डेटाबेस में सबसे धीमी क्वेरी ढूँढ़कर प्रदर्शन की बाधाओं की पहचान करता है। इसके लिए pg_stat_statements एक्सटेंशन आवश्यक है।
  • explain_sql_statement: प्रदर्शन की बाधाओं की पहचान करने में मदद के लिए SQL क्वेरी की विस्तृत निष्पादन योजनाएँ देता है।
  • prepare_query_tuning: क्वेरी के प्रदर्शन का विश्लेषण करता है और इंडेक्स बनाने जैसे ऑप्टिमाइज़ेशन सुझाता है। इन ऑप्टिमाइज़ेशन को सुरक्षित रूप से जाँचने के लिए एक अस्थायी ब्रांच बनाता है।
  • complete_query_tuning: ऑप्टिमाइज़ेशन को मुख्य ब्रांच पर लागू करके या उन्हें छोड़कर क्वेरी ट्यूनिंग को अंतिम रूप देता है। अस्थायी ट्यूनिंग ब्रांच को साफ़ करता है।

Neon Auth (?category=neon_auth):

  • provision_neon_auth, get_auth, disable_auth, update_auth_config
  • get_neon_auth_config: सीक्रेट छिपाए जाते हैं। विश्वसनीय ऑरिजिन, लोकलहोस्ट एक्सेस, ईमेल और पासवर्ड, OAuth प्रोवाइडर, ईमेल प्रोवाइडर, संगठन, मैजिक लिंक और फ़ोन नंबर प्लगइन, वेबहुक और लॉग एक्सपोर्ट पढ़ता है।
  • update_auth_allow_localhost, update_auth_email_and_password, update_auth_email_provider, send_auth_test_email, update_auth_plugins_organization, update_auth_plugins_magic_link, update_auth_plugins_phone_number, update_auth_webhooks, update_auth_logs_export: इन सेटिंग्स में बदलाव करते हैं। update_auth_webhooks पूरे वेबहुक कॉन्फ़िगरेशन को बदल देता है। update_auth_logs_export Neon Auth इवेंट को Neon Platform लॉग में एक्सपोर्ट करना चालू या बंद करता है; लॉग एक्सपोर्ट के बिना कोई प्रोजेक्ट केवल enabled: false स्वीकार करता है।
  • list_auth_oauth_providers, add_auth_oauth_provider, update_auth_oauth_provider, delete_auth_oauth_provider
  • get_auth_oauth_server, update_auth_oauth_server: Neon Auth को OAuth 2.1 ऑथराइज़ेशन सर्वर के रूप में कॉन्फ़िगर करते हैं (MCP सर्वर के लिए भी)। यह ऊपर दिए गए सोशल लॉगिन प्रोवाइडर से अलग है।
  • list_auth_oauth_clients, get_auth_oauth_client, create_auth_oauth_client, update_auth_oauth_client, delete_auth_oauth_client, rotate_auth_oauth_client_secret: उस सर्वर के OAuth क्लाइंट प्रबंधित करते हैं। create_auth_oauth_client और rotate_auth_oauth_client_secret client_secret को एक बार लौटाते हैं।
  • list_auth_trusted_domains, add_auth_trusted_domain, delete_auth_trusted_domain
  • create_auth_user, delete_auth_user, update_auth_user_role

Neon Data API (?category=data_api):

  • provision_neon_data_api, get_data_api, update_data_api, delete_data_api: किसी ब्रांच डेटाबेस के लिए Data API प्रबंधित करते हैं।

खोज और डिस्कवरी:

  • search: क्वेरी से मेल खाने वाले संगठनों, प्रोजेक्ट और ब्रांच में खोज करता है। Neon Console के ID, शीर्षक और सीधे लिंक लौटाता है।
  • fetch: किसी ID का उपयोग करके किसी विशिष्ट संगठन, प्रोजेक्ट या ब्रांच की विस्तृत जानकारी प्राप्त करता है (आमतौर पर खोज टूल से मिली ID)।

फ़ीडबैक (बिना लॉगिन वाले ?category=docs एंडपॉइंट सहित, हमेशा उपलब्ध):

  • send_feedback: Neon टीम को गुमनाम फ़ीडबैक भेजता है। केवल फ़ीडबैक टेक्स्ट भेजा जाता है; खाते, प्रोजेक्ट या कनेक्शन का कोई विवरण नहीं भेजा जाता। संदेश अधिकतम 10,000 वर्णों के हो सकते हैं।

ऑब्ज़र्वेबिलिटी (?category=observability): इन टूल के लिए Neon Platform Beta आवश्यक है और ये अभी केवल aws-us-east-2 क्षेत्र के प्रोजेक्ट के लिए उपलब्ध हैं। लॉग एक्सेस के बिना ब्रांच HTTP 404 और telemetry_not_enabled कारण लौटाती है।

  • query_logs: किसी ब्रांच के OpenTelemetry लॉग क्वेरी करता है। Management API में POST; इस सर्वर द्वारा इसे केवल-पढ़ने वाला माना जाता है।
  • query_loki_logs: ब्रांच के Loki-संगत रीड API पर LogQL रेंज क्वेरी चलाता है और Loki का जवाब लौटाता है: स्ट्रीम लेबल के अनुसार समूहित लाइनें, जिनमें नैनोसेकंड टाइमस्टैम्प होते हैं।
  • list_log_fields: उन लॉग फ़ील्ड की सूची देता है जिनके मान ब्रांच पर सूचीबद्ध किए जा सकते हैं।
  • list_log_field_values: किसी ब्रांच और समयावधि में लॉग फ़ील्ड के अलग-अलग मान सूचीबद्ध करता है।

दस्तावेज़ और संसाधन (?category=docs):

  • search_docs: neon.com (दस्तावेज़, API संदर्भ, PostgreSQL ट्यूटोरियल, गाइड, FAQ, चेंजलॉग और ब्लॉग) में neon.com के खोज बॉक्स जैसी ही खोज करता है। इसमें query, वैकल्पिक categories (docs, api, postgresql, guides, faqs, blog, changelog), और वैकल्पिक limit (1-40, डिफ़ॉल्ट 10) लिए जाते हैं। रैंक किए गए पेज title, url, slug, category, breadcrumb, heading और excerpt के साथ लौटाता है; पेज पढ़ने के लिए slug को get_doc में दें।
  • get_doc: neon.com का एक पेज Markdown के रूप में प्राप्त करता है। इसमें search_docs खोज परिणाम से मिला slug लिया जाता है (उदाहरण के लिए docs/guides/prisma या postgresql/tutorial/inner-join)।

फ़ंक्शन (?category=functions):

  • list_functions, get_function, update_function, delete_function, deploy_function
  • list_functions_custom_domains, register_functions_custom_domain, delete_functions_custom_domain
  • list_triggers, get_trigger, create_trigger, update_trigger, delete_trigger: शेड्यूल किए गए फ़ंक्शन ट्रिगर (type: "schedule", पाँच-फ़ील्ड UTC cron)।

स्टोरेज (?category=storage):

  • list_storage_buckets, create_storage_bucket, delete_storage_bucket
  • list_storage_objects, delete_storage_object, delete_storage_objects_by_prefix
  • presign_storage_object, get_storage

रीयलटाइम (?category=realtime):

  • get_realtime, enable_realtime, disable_realtime: ब्रांच की रीयलटाइम स्थिति, सक्षम करना (वैकल्पिक allowed_origins) और अक्षम करना। सक्षम और अक्षम करने की कार्रवाइयाँ बदलाव लागू होने तक प्रतीक्षा करती हैं।
  • get_realtime_secret: वह साझा सीक्रेट जिससे एप्लिकेशन बैकएंड Realtime टोकन जारी करता है। केवल-पढ़ने वाले मोड में उपलब्ध नहीं है।
  • rotate_realtime_secret: साझा सीक्रेट बदलता है और बदलाव लागू होने तक प्रतीक्षा करता है। यह idempotent नहीं है। नया मान पाने के लिए इसके बाद get_realtime_secret कॉल करें।

माइग्रेशन

माइग्रेशन समय के साथ अपने डेटाबेस स्कीमा में बदलाव प्रबंधित करने का एक तरीका है। Neon MCP सर्वर के साथ, LLM अलग-अलग "Start" (prepare_database_migration) और "Commit" (complete_database_migration) कमांड का उपयोग करके सुरक्षित रूप से माइग्रेशन कर सकते हैं।

"Start" कमांड माइग्रेशन स्वीकार करता है और उसे एक नई अस्थायी ब्रांच में चलाता है। लौटने पर, यह कमांड LLM को संकेत देता है कि उसे इस ब्रांच पर माइग्रेशन की जाँच करनी चाहिए। इसके बाद LLM "Commit" कमांड चलाकर माइग्रेशन को मूल ब्रांच पर लागू कर सकता है।

विकास

यह प्रोजेक्ट पैकेज मैनेजर के रूप में pnpm का उपयोग करता है, जिसे Corepack के ज़रिए पिन किया गया है।

प्रोजेक्ट संरचना

MCP सर्वर का कोड रिपॉज़िटरी के रूट में है। यह Next.js एप्लिकेशन Vercel पर mcp.neon.tech में डिप्लॉय किया गया है।

corepack enable
pnpm install

टूल जोड़ने का तरीका जानने के लिए CONTRIBUTING.md देखें। टूल आर्ग्युमेंट snake_case हैं।

स्थानीय विकास

# Start the Next.js dev server (for the remote MCP server)
pnpm dev

लिंटिंग और टाइप जाँच

pnpm lint
pnpm typecheck

एनवायरनमेंट वेरिएबल

रिमोट सर्वर रनटाइम के लिए आवश्यक:

VariableDescription
SERVER_HOSTसर्वर URL (डिफ़ॉल्ट VERCEL_URL)
UPSTREAM_OAUTH_HOSTNeon OAuth प्रोवाइडर URL
CLIENT_IDOAuth क्लाइंट ID
CLIENT_SECRETOAuth क्लाइंट सीक्रेट
KV_URLUpstash Redis URL (ट्रांज़िशनल लॉक)
OAUTH_DATABASE_URLटोकन स्टोरेज के लिए Postgres URL

वैकल्पिक:

VariableDescription
LOG_LEVELWinston लॉग स्तर: error, warn, info (डिफ़ॉल्ट), debug, verbose, silly
NEON_MCP_DISABLE_ANALYTICSप्रोडक्ट एनालिटिक्स बंद करने के लिए 1 पर सेट करें

परीक्षण पिरामिड

सभी परीक्षण रिपॉज़िटरी के रूट से चलाए जाते हैं।

# Unit tests
pnpm test:unit

# Integration tests
pnpm test:integration

# MCP protocol end-to-end tests (real MCP client/server tool calls)
pnpm test:e2e:mcp

# Website end-to-end tests (Playwright; provisions/validates ephemeral DB first)
pnpm test:e2e:web

# Full end-to-end suite
pnpm test:e2e

# Full test pyramid (unit + integration + e2e; used in CI)
pnpm test

परीक्षण रणनीति:

  • ट्रांसपोर्ट/प्रोटोकॉल और उपयोगकर्ता को दिखने वाले व्यवहार के लिए E2E को प्राथमिकता दें।
  • नियतात्मक टूल कॉन्ट्रैक्ट और वर्कफ़्लो व्यवहार के लिए integration परीक्षणों का उपयोग करें।
  • शुद्ध लॉजिक और एज केस के लिए unit परीक्षणों का उपयोग करें।
  • मर्ज को रोकने वाले परीक्षणों में तृतीय-पक्ष सेवाओं के अपटाइम पर निर्भर न रहें; integration/unit स्तरों पर बाहरी निर्भरताओं को मॉक करें।

डिप्लॉयमेंट

Vercel रिपॉज़िटरी ब्रांच कॉन्फ़िगरेशन से रिमोट सर्वर को अपने-आप डिप्लॉय करता है। पुल रिक्वेस्ट के लिए प्रीव्यू एनवायरनमेंट उपलब्ध हैं।

टेलीमेट्री

Neon MCP सर्वर उपयोग को समझने और विश्वसनीयता बेहतर करने में हमारी मदद के लिए प्रोडक्ट एनालिटिक्स और त्रुटि रिपोर्ट एकत्र करता है:

  • प्रोडक्ट एनालिटिक्स (Segment): प्रमाणित खाते से कनेक्ट करने पर, सर्वर आपके Neon खाते की ID, नाम और ईमेल पते के साथ एक identify इवेंट भेजता है। यह सेशन शुरू होने (server_init), हर टूल कॉल (tool_call) और सर्वर की अप्रत्याशित त्रुटियों (server_error) को भी ट्रैक करता है। टूल-कॉल इवेंट में टूल का नाम, ऑथ विधि और क्लाइंट शामिल होते हैं, लेकिन टूल आर्ग्युमेंट या क्वेरी परिणाम नहीं। बिना खाते के किए गए केवल-दस्तावेज़ टूल कॉल गुमनाम रूप से ट्रैक किए जाते हैं। ऑथराइज़ेशन के बाद दिखाए गए पेज के दिखने की सूचना (auth_complete_viewed, परिणाम और क्लाइंट सहित) और उसके बटन तथा लिंक के उपयोग की सूचना (auth_complete_action) भेजी जाती है; ब्राउज़र केवल एक रैंडम पेज व्यू ID भेजता है, ऑथराइज़ेशन कोड या आपकी पहचान कभी नहीं। इवेंट track.neon.tech पर भेजे जाते हैं, जो Neon का अपना एनालिटिक्स एंडपॉइंट है।
  • त्रुटि रिपोर्टिंग, ट्रेस और लॉग (Sentry): सर्वर की अप्रत्याशित त्रुटियाँ स्टैक ट्रेस और अनुरोध के मेथड तथा पाथ के साथ रिपोर्ट की जाती हैं। अनुरोध हेडर, बॉडी, कुकी और क्वेरी स्ट्रिंग नहीं भेजे जाते। हर अनुरोध और टूल कॉल को टूल के नाम, क्लाइंट के नाम, खाते की ID और कॉल विफल हुई या नहीं, इन जानकारियों के साथ ट्रेस किया जाता है; साथ ही, 2025-युग के क्लाइंट को सर्वर द्वारा दी गई सेशन ID और _meta.threadId में क्लाइंट द्वारा भेजी गई बातचीत की ID भी शामिल होती है। ट्रेस में टूल आर्ग्युमेंट या परिणाम नहीं होते। सर्वर के लॉग भी Sentry पर भेजे जाते हैं। यह संग्रह Neon Privacy Policy के अंतर्गत आता है। सर्वर को स्वयं चलाते समय एनालिटिक्स बंद करने के लिए, NEON_MCP_DISABLE_ANALYTICS=1 सेट करें। यह फ़्लैग Sentry को बंद नहीं करता।