सामग्री पर जाएँ

MCP

वही API, किसी परिदृश्य के बजाय सहायक को संबोधित। MCP क्लाइंट चलते समय टूल विवरणों से तय करता है कि क्या बुलाना है — इसलिए वह ठीक वहीं पहुँचता है जहाँ उसके क्रेडेंशियल पहुँचते हैं, और हर टूल के नीचे सार्वजनिक API की एक कॉल है।

एक ही एंडपॉइंट

सब कुछ POST /v1/mcp पर जाता है। न कोई सत्र खोलना है, न कोई स्ट्रीम पकड़नी: GET और DELETE 405 देते हैं, और हर संदेश अपनी अलग रिक्वेस्ट है।

POST https://api.mosaqo.app/v1/mcp
Authorization: Bearer $MOSAQO_KEY
MCP-Protocol-Version: 2026-07-28

2025-03-26 से 2026-07-28 तक की सभी प्रोटोकॉल रिवीज़न सेवित हैं। initialize से शुरू करने वाले क्लाइंट को अपेक्षित हैंडशेक मिलता है; जो हर रिक्वेस्ट में अपना संस्करण बताता है, उसे वैसे सेवा मिलती है।

API कुंजी से जोड़ना

सबसे तेज़ रास्ता, और उस टूल के लिए सही जिसे आप खुद चलाते हैं। कोई भी कुंजी bearer टोकन की तरह काम करती है, और पेश किए गए टूल उसी कुंजी के स्कोप तक कट जाते हैं।

ज़्यादातर क्लाइंट ऐसा ब्लॉक लेते हैं:

{
  "mcpServers": {
    "mosaqo": {
      "type": "http",
      "url": "https://api.mosaqo.app/v1/mcp",
      "headers": { "Authorization": "Bearer $MOSAQO_KEY" }
    }
  }
}
curl -X POST https://api.mosaqo.app/v1/mcp \
  -H "Authorization: Bearer $MOSAQO_KEY" \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/list" \
  -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }'

OAuth से जोड़ना

किसी और की डायरेक्टरी में मौजूद कनेक्टर के लिए, जहाँ व्यक्ति कुंजी को कभी छूता ही नहीं। खोज RFC 9728 और RFC 8414 के अनुसार, क्लाइंट RFC 7591 से खुद पंजीकरण करते हैं, और हर प्राधिकरण S256 के साथ PKCE उपयोग करता है।

curl https://api.mosaqo.app/.well-known/oauth-protected-resource
curl https://api.mosaqo.app/.well-known/oauth-authorization-server

अनधिकृत कॉल खुद बताती है कि कहाँ जाना है और क्या माँगना है:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="Mosaqo MCP",
  resource_metadata="https://api.mosaqo.app/.well-known/oauth-protected-resource",
  scope="qr:read analytics:read reviews:read exports:read"

जो स्वीकृति देता है वह Mosaqo में साइन इन है, चुनता है कि यह किस वर्कस्पेस पर लागू है, और ऐसा केवल वहीं कर सकता है जहाँ वह स्वामी या व्यवस्थापक है — वही सीमा जो तय करती है कि API कुंजी कौन जारी कर सकता है। बाद में Bulk & API में इसे हटाया जा सकता है।

सहायक क्या कर सकता है

वही स्कोप जो आप जानते हैं, अपरिवर्तित। जिस टूल की क्रेडेंशियल अनुमति नहीं देते वह tools/list में नहीं आता और नाम लेकर भी नहीं बुलाया जा सकता — इसलिए हर कनेक्शन का जीवित उत्तर स्वयं tools/list है।

स्कोपक्या अनुमति देता है
qr:readQR कोड, फ़ोल्डर और टेम्पलेट सूचीबद्ध करना और पढ़ना
qr:writeबनाना, अपडेट करना, दोबारा लक्षित करना, प्रकाशित करना, आर्काइव और डिलीट करना
exports:readरेंडर किए गए कार्ड डाउनलोड करना
analytics:readएग्रीगेट एनालिटिक्स और अलग-अलग स्कैन
bulk:writeबल्क जॉब बनाना और पढ़ना
webhooks:writewebhook सब्सक्रिप्शन प्रबंधित करना
reviews:readस्थान, सर्वे और वे कैसे चल रहे हैं — उत्तर स्वयं कभी नहीं

वह कभी क्या नहीं पाएगा

जो लोगों ने सर्वे में लिखा। reviews:read आपके स्थान, सर्वे और वे कैसे चल रहे हैं खोलता है: गिनती, अंक, हर प्रश्न का वितरण। किसी आगंतुक ने जो वाक्य टाइप किए, वे यहाँ उतने ही नहीं लौटाए जाते जितने कहीं और जहाँ क्रेडेंशियल पहुँचते हैं — उसी कारण से जिससे feedback.* घटनाएँ अंक ले जाती हैं और शब्द कभी नहीं।

कोड मिटाना। REST रूट टाइप की गई पुष्टि माँगता है क्योंकि छपे हुए कोड के पीछे का रीडायरेक्ट नष्ट करना पलटा नहीं जा सकता, और यह ऐसी पुष्टि नहीं जो सहायक किसी की ओर से दे। इसके बदले संग्रह करना दिया जाता है, और वह पलटा जा सकता है।

लिखना, लिखने के रूप में चिह्नित है। जो टूल कुछ बदलता है वह readOnlyHint: false रखता है, और संग्रह destructiveHint: true — यही क्लाइंट को रोककर चलने से पहले किसी व्यक्ति से पूछने पर मजबूर करता है।