MCP और कनेक्टेड टूल्स

Nessie को MCP सर्वर से जोड़ें, और किसी बाहरी एजेंट को पेयर करें ताकि वह आपकी ओर से Nessie में काम कर सके।

MCP क्या है

Model Context Protocol एक छोटा, खुला नियम है, जो किसी language model को टूल्स का वर्णन करने और उन्हें बुलाने का तरीका बताता है। एक सर्वर बताता है कि वह क्या कर सकता है — नाम वाले टूल्स की एक सूची, जिनमें से हर एक के arguments के लिए JSON schema है — और एक क्लाइंट वह सूची खोजता है और मॉडल की ओर से उन्हें चलाता है। यह जानबूझकर सीधा-सादा है: फ़ायदा यह है कि एक बार लिखा गया integration हर उस मॉडल और हर उस product के साथ काम करता है जो इस भाषा को बोलता है।

Nessie इसके दोनों तरफ़ है

इसे सटीक रूप से समझना ज़रूरी है, क्योंकि दोनों हिस्से आसानी से उलझ जाते हैं, और वे जानबूझकर अलग-अलग रास्तों पर रहते हैं।

• Outbound। Nessie एक MCP क्लाइंट है। आप ऐसे सर्वर जोड़ते हैं जिन्हें कोई और चलाता है, और वे जो टूल्स उपलब्ध कराते हैं, वे आपके एजेंट इस्तेमाल कर सकते हैं। प्रबंधन की सतह /api/mcp/* पर है।
• Inbound। Nessie एक MCP सर्वर भी है। कहीं और चलने वाला एक एजेंट — किसी developer की मशीन पर Claude Code या Codex — आपके बोर्ड और दस्तावेज़ तक पहुँच सकता है। वह एंडपॉइंट POST /mcp है, जानबूझकर /api के बाहर, ताकि दो विपरीत अर्थ एक ही path segment की दूरी पर न रहें।

MCP सर्वर को Nessie से जोड़ना

Catalogue entries और इंस्टेंस

दो चीज़ें हैं, और उनका फ़र्क मायने रखता है:

• Catalogue entry एक सर्वर की परिभाषा है — उसका नाम, उसका transport, और वह कैसे प्रमाणित होता है। इसे एक बार लिखा जाता है, और इसे साझा किया जा सकता है।
• इंस्टेंस वही entry है, जो एक स्कोप पर उन क्रेडेंशियल के साथ इंस्टॉल की गई है जो उस तक पहुँचती हैं। एक ही entry को दो अलग टीम के लिए इंस्टॉल करने पर दो इंस्टेंस बनते हैं।

ज़्यादातर लोग इनमें से किसी को सीधे नहीं छूते। एडमिन में प्रवेश-द्वार /admin/apps पर app store है: वह वही catalogue ब्राउज़ करता है, कनेक्शन के विवरण छिपाकर, और किसी listing पर Connect दबाने से एक इंस्टेंस बनता है। जो operators कच्ची objects चाहते हैं, वे /api/mcp/catalog और /api/mcp/instances इस्तेमाल करते हैं।

अगर कोई सर्वर अभी catalogue में नहीं है, तो POST /api/mcp/discover एक URL लेता है और वह सर्वर अपने बारे में जो कहता है, वह वापस पढ़ता है, और POST /api/mcp/library/import सार्वजनिक server library से एक entry खींचता है। पहली बार का कनेक्शन सीधे एक URL से POST /api/apps/custom के ज़रिए भी बनाया जा सकता है।

Transports

Nessie दूर के सर्वर से HTTP पर जुड़ता है। दो transports काम करते हैं: streamable HTTP (मौजूदा MCP transport) और पुराना HTTP+SSE transport। जब तक सर्वर केवल sse न दे, http चुनें।

आपके लिखे कनेक्टर के लिए stdio transport मना है। stdio का मतलब है कि MCP सर्वर एक स्थानीय process है जिसे host शुरू करता है, और Nessie सर्वर के भीतर मनमाने programs चलाना ऐसी चीज़ नहीं है जिसकी कोई operator सार्थक समीक्षा कर सके। जो सर्वर केवल स्थानीय रूप से चलाने के लिए package के रूप में प्रकाशित हैं, वे library imports से उसी कारण हटा दिए जाते हैं। Protocol field में एक ws मान है, पर वह लागू नहीं है — उसका इस्तेमाल करने वाला कनेक्शन तब विफल होता है जब Nessie उसे खोलने की कोशिश करता है।

Nessie सर्वर से कैसे प्रमाणित होता है

एक catalogue entry पाँच में से एक method घोषित करती है: none, api_key, bearer, basic या oauth2।

api_key एक header injection है, और entry बताती है कि कौन-सा header और कौन-सा prefix — तो Authorization: Bearer …, X-API-Key: … और X-Auth-Token: Token … एक ही method के अलग-अलग कॉन्फ़िगरेशन हैं। Key को POST /api/mcp/instances/:instanceId/secret पर एक बार पेस्ट किया जाता है और फिर कभी पढ़ा नहीं जा सकता; instance routes का कोई भी response credential reference नहीं लौटाता।

oauth2 दो रूपों में आता है। जिस सर्वर के एंडपॉइंट तय हैं, उनके एंडपॉइंट उसकी catalogue entry में होते हैं। जो server standard metadata प्रकाशित करता है, उसके लिए कुछ भी कॉन्फ़िगर करने की ज़रूरत नहीं: Nessie protected-resource और authorization-server documents पढ़ता है, और dynamic client registration से, या उस client-ID metadata document से जो वह अपने well-known path पर प्रकाशित करता है, अपना क्लाइंट खुद बनाता है। दोनों तरह से handshake यह होता है: POST /api/mcp/instances/:instanceId/oauth/start, फिर प्रोवाइडर का redirect वापस GET /api/mcp/oauth/callback पर। State टोकन एक बार ही इस्तेमाल होता है, डेटाबेस में रहता है और दस मिनट तक वैध है, और PKCE हमेशा इस्तेमाल होता है।

एक नियम लोगों को हैरान करता है: किसी संगठन का owner भी किसी और व्यक्ति को personal या OAuth टोकन नहीं जोड़ सकता। साझा क्रेडेंशियल केवल उसी API-key entry के लिए संभव है जिसे वैसा मान्य किया गया हो; बाकी हर चीज़ मना है। जो क्रेडेंशियल किसी व्यक्ति का है, वह उसी व्यक्ति का क्रेडेंशियल बना रहता है।

क्रेडेंशियल कहाँ रहते हैं

कनेक्टर के secrets और OAuth token bundles आपकी अपनी Postgres डेटाबेस में रहते हैं, purpose-bound AES-256-GCM envelopes में, डिप्लॉयमेंट की स्वतंत्र रूप से versioned encryption key ring के तहत, और केवल अपारदर्शी secret_* references से पहुँचे जाते हैं। ये जानबूझकर उस बाहरी secret vault में नहीं हैं, जिसमें Nessie के बाकी secrets रहते हैं। जो production deployment encrypted store कॉन्फ़िगर नहीं करता, वह OAuth handshake पूरा करने से मना करके शुरू ही नहीं होता, बजाय इसके कि वह handshake पूरा करे और फिर उसे रास्ते में ही छोड़ दे।

कनेक्शन कहाँ तक पहुँचता है

एक इंस्टेंस छह स्कोप में से एक पर इंस्टॉल होता है: system, organization, project, team, channel या user। वह स्कोप इस बात की कड़ी सीमा है कि कौन-से runs उसे इस्तेमाल कर सकते हैं, और grants उसे केवल और सीमित कर सकते हैं, कभी चौड़ा नहीं — इसलिए आपके अपने खाते से इंस्टॉल किया गया कनेक्टर चुपचाप पूरे संगठन वाला कनेक्टर नहीं बन सकता।

कौन कहाँ इंस्टॉल कर सकता है, उसका आकार वही है: संगठन के ओनर और एडमिन किसी भी स्कोप पर इंस्टॉल संभालते हैं; बाकी हर कोई कनेक्टर अपने user स्कोप पर इंस्टॉल करता है, और जिन साझा इंस्टॉल तक उसके पहुँचने का अधिकार है, उन्हें देख सकता है।

किसी एजेंट को टूल देना

किसी सर्वर को जोड़ने से उसके टूल्स किसी को नहीं सौंपे जाते। जब इंस्टेंस इंस्टॉल होता है, Nessie उसे probe करता है और हर टूल, जिसका वह विज्ञापन करता है, tool registry में प्रक्षेपित (project) करता है — यही वह सूची है जो /admin/advanced/tools पर दिखती है: built-in tools, MCP tools, bundle tools और एक्ज़ीक्यूटर टूल्स एक ही सूची में, हर एक अपने स्रोत और स्थिति के साथ।

एक projected tool की तीन में से एक स्थिति होती है: active, pending_review या disabled। shared-scope install से आए टूल्स pending_review में आते हैं और किसी एजेंट को दिखने से पहले उस पेज पर मंज़ूर करने होते हैं; आपके अपने user-scope install के टूल्स तुरंत active हो जाते हैं, क्योंकि उनमें केवल आप शामिल हैं। समीक्षा एक बार की रस्म नहीं, बल्कि बार-बार होने वाली चीज़ है: अगर बाद की probe में पता चले कि किसी टूल का विवरण या schema बदल गया है, तो वह फिर pending_review में चला जाता है और तब तक पेश नहीं किया जाता जब तक कोई उस बदलाव को न देखे।

एक active tool को कौन-से एजेंट बुला सकते हैं, यह दो तरीकों में से एक से तय होता है:

• app store के ज़रिए बनाया गया कनेक्शन स्पष्ट grant माँगता है। किसी एजेंट को टूल तभी मिलता है जब कोई grant उसका नाम ले, और grant को टूल के मौजूदा fingerprint के खिलाफ़ जाँचा जाता है, इसलिए बदले हुए टूल को नए फ़ैसले की ज़रूरत होती है।
• वरना टूल उस स्कोप की पहुँच वाले एजेंटों के लिए डिफ़ॉल्ट रूप से चालू रहता है, और अलग-अलग एजेंट टूल के विवरण वाले पैनल पर बंद किए जा सकते हैं।

एक grant ठीक एक principal का नाम लेता है — एक role या एक एजेंट, दोनों नहीं — और इनकार, अनुमति पर भारी पड़ता है। user-scope connection के लिए सवाल उठता ही नहीं: वह व्यक्ति जिस किसी एजेंट से बात करता है, वह उसे इस्तेमाल कर सकता है, और केवल एक स्पष्ट बंद करने का स्विच ही उसे रोकता है।

एक चीज़ जिसे गलत जगह ढूँढना आसान है: एडमिन में /settings/accounts connected accounts है — Slack, mailboxes, model subscriptions, और Linear, Jira, GitHub व Trello के OAuth links, जो बाहरी बोर्ड के पीछे हैं। MCP कनेक्टर /admin/apps पर हैं, और उनसे बने टूल्स /admin/advanced/tools पर।

Tool calls पर मंज़ूरी के गेट

कुछ tool calls रुककर किसी व्यक्ति का इंतज़ार करते हैं। जब कोई ऐसा करता है, तो run विफल नहीं होता: invocation जम जाता है — टूल का नाम, उसके arguments का hash और फिर से शुरू करने लायक पर्याप्त state — और /api/approvals पर एक मंज़ूरी का अनुरोध दिखता है, जिसका जवाब कोई दे। Resume idempotent है, इसलिए दोहराई गई मंज़ूरी कोई call दो बार नहीं चलाती। फ़ैसला लेने वाले व्यक्ति को माँगी जा रही चीज़ का सीमित सार दिखता है; सटीक arguments और उन्हें उत्पन्न करने वाला run सर्वर-साइड ही रहते हैं।

दो अलग-अलग गेट हैं, और उन्हें अलग तरह से कॉन्फ़िगर किया जाता है।

• Structural gates कुछ built-in tools की एक विशेषता हैं और कॉन्फ़िगर नहीं होतीं। किसी एजेंट के अपने mailbox या जुड़े हुए mailbox से मेल भेजना, Gmail draft भेजना, mail account disconnect करना, calendar event बनाना, बदलना या रद्द करना, और ऐसी browser action जो किसी ऐसी site पर लिखे जिसमें ब्राउज़र साइन इन नहीं है — ये सब इसी तरह गेट होते हैं। इनके जवाब के लिए सामान्य 30 मिनट के बजाय 24 घंटे की खिड़की मिलती है।
• Policy gates tool/invoke जोड़ी पर policy rules से आते हैं। जो rule किसी invocation को अनुमति देता है, वह requiresApproval साथ रख सकता है, और सत्यापित मंज़ूरी के बिना evaluation चलने के बजाय APPROVAL_REQUIRED लौटाता है। Rules पहले इनकार की जाँच के साथ evaluate होते हैं और स्कोप के क्रम में चलते हैं।

कौन-सी एडमिन स्क्रीन किसी टूल के लिए requiresApproval policy rule लिखती है — data model और enforcement दोनों मौजूद हैं, पर हम वह स्क्रीन पक्की तौर पर पुष्ट नहीं कर पाए जो ऐसा rule लिखती है।

किसी बाहरी एजेंट को Nessie से जोड़ना

दूसरी दिशा। Nessie अपना MCP सर्वर POST /mcp पर चलाता है, streamable HTTP पर, और वह stateless है: हर call अपना क्रेडेंशियल साथ लाती है और अपना actor खुद तय करती है, इसलिए कोई सेशन नहीं है जिसे किसी एक क्लाइंट को एक replica से बाँधना पड़े। ChatGPT, Claude, Claude Code, Codex या किसी के laptop वाला एजेंट आपके बोर्ड, दस्तावेज़ और ग्राहकों पर उसी टूल के भीतर से काम कर सकता है जो वह व्यक्ति पहले से इस्तेमाल करता है। हर app के लिए क्रमवार निर्देश यहाँ हैं: ChatGPT, Claude और अन्य AI apps को कनेक्ट करना।

जुड़ा हुआ क्रेडेंशियल असल में क्या है

इसे सही समझना ज़रूरी है, क्योंकि जो स्वाभाविक मानसिक मॉडल लोगों के मन में होता है — अनुमतियाँ जुड़ी एक API key — वही गलत है।

जुड़ा हुआ क्रेडेंशियल कभी पहचान नहीं होता। वह एक व्यक्ति का नाम लेता है, और हर tool call उसी व्यक्ति के रूप में चलती है, उन्हीं service functions के खिलाफ़ जिन्हें HTTP routes बुलाते हैं। इसलिए एजेंट वहाँ नहीं पहुँच सकता जहाँ वह व्यक्ति, जिसने उसे उधार दिया, क्लिक करके नहीं पहुँच सकता था। स्कोप पहुँच को केवल सीमित करते हैं; कोई ऐसा स्कोप नहीं जो उसे चौड़ा करे।

Liveness हर call पर फिर से पढ़ी जाती है, टोकन से कभी भरोसे के साथ नहीं ली जाती: revocation, expiry, उपयोगकर्ता का token version, उसकी संगठन की सदस्यता और उसकी मौजूदा role। किसी का पद घटना, निष्क्रिय होना या “sign me out everywhere” करना, क्रेडेंशियल की expiry तक इंतज़ार नहीं करता, बल्कि एजेंट की अगली call पर लागू हो जाता है।

टोकन अपारदर्शी है, nag1_ से शुरू होता है, केवल SHA-256 hash के रूप में स्टोर होता है, और 90 दिन चलता है। MCP एंडपॉइंट के अलावा किसी भी route पर यह एक विशेष 403 के साथ अस्वीकार होता है — उसे कहीं और पेश करना कोई आंशिक सफलता नहीं है जिसे दोबारा कोशिश किया जाए, और यही बात सुनिश्चित करती है कि “मैंने एजेंट को अपने बोर्ड उधार दिए” का मतलब “मैंने उसे अपना खाता उधार दिया” न बन जाए।

जुड़ने के दो तरीके

जो app browser खोल सकता है — ChatGPT, Claude, Claude Code, Codex — वह MCP authorization profile इस्तेमाल करता है: PKCE (S256) के साथ OAuth 2.1, POST /mcp/oauth/register पर dynamic client registration, refresh tokens और resource indicators। App व्यक्ति को /settings/security पर भेजता है, वे चुनते हैं कि वह क्या कर सकता है और उनकी कौन-सी टीम तक पहुँचे, और ब्राउज़र एक code के साथ app पर वापस लौट जाता है। उसका access token एक घंटे तक चलता है और ताज़ा किया जाता है; कनेक्शन 90 दिन चलता है।

एक command-line एजेंट न कोई ब्राउज़र नियंत्रित करता है, न कोई callback URL रख सकता है, इसलिए वह इसके बजाय device authorization grant (RFC 8628) से जुड़ता है।

1. एजेंट clientName और जो scopes वह चाहता है, उनके साथ POST /mcp/auth/device को कॉल करता है। उसे एक device_code, एक छोटा user_code, एक verification_uri और एक verification_uri_complete मिलता है, जिसमें query में कोड पहले से होता है, साथ में poll के लिए interval और एक expires_in। वह URI प्रिंट करता है।
2. कोई व्यक्ति, साइन इन रहते हुए, वह URI खोलता है, /settings/security पर। वे देखते हैं कि कौन-सा एजेंट पूछ रहा है, वह किसके खाते के रूप में काम करेगा, कब तक, और ठीक-ठीक क्या कर पाएगा — और वे Allow या Don’t allow चुनते हैं।
3. एजेंट deviceCode के साथ POST /mcp/auth/token को poll करता है, और authorization_pending, slow_down, expired_token और access_denied का सम्मान करता है। सफल होने पर उसे { access_token, token_type, scope, expires_at } मिलता है।

दोनों तरीकों में एक इंसानी कदम ज़रूर है, क्योंकि क्रेडेंशियल किसी व्यक्ति के अधिकार विरासत में लेता है, इसलिए किसी व्यक्ति को उसे उधार देने का फ़ैसला करना होता है। यहाँ कुछ भी शून्य से पहुँच नहीं गढ़ता। पूरे संगठन के लिए connecting को /admin/security?tab=programs पर बंद भी किया जा सकता है, और वह जवाब तब जाँचा जाता है जब कोई कनेक्शन मंज़ूर करता है, न कि तब जब कोई एजेंट शुरू करता है।

Discovery

बिना प्रमाणीकरण वाला POST /mcp 401 लौटाता है, जिसमें एक WWW-Authenticate header होता है जो /.well-known/oauth-protected-resource की ओर इशारा करता है (RFC 9728), और वह इसी ओरिजिन को authorization server के रूप में बताता है; उसका metadata /.well-known/oauth-authorization-server पर (RFC 8414) registration, authorization, token और revocation endpoints के नाम देता है। एक क्लाइंट को पता मिल जाने के बाद उसे बस इतना ही चाहिए। किसी domain से पता खोजने के लिए एजेंट /.well-known/ai-catalog.json पढ़ता है, जो /mcp/server-card पर Server Card का नाम देता है (MCP Server Cards, SEP-2127)। Device grant के endpoints protected-resource document में x-nessie-device-authorization के अंतर्गत सूचीबद्ध हैं।

किसी डिप्लॉयमेंट पर एक दूसरा, छोटा पता भी हो सकता है: Nessie Cloud का https://nessie.works/mcp API तक प्रॉक्सी होता है, और उस रास्ते से आने वाले क्लाइंट को वही पता resource के रूप में लौटाया जाता है, जबकि साइन इन API पर ही रहता है। Redirect से काम नहीं चलेगा, क्योंकि कोई क्लाइंट उस पते के अलावा किसी और पते वाला metadata स्वीकार नहीं करता जो उसे दिया गया था। Operator ये ओरिजिन NESSIE_MCP_ALIAS_ORIGINS में सूचीबद्ध करता है।

स्कोप और टूल्स

स्कोप जानबूझकर मोटे रखे गए हैं — जो स्कोप कोई समझा न सके, उसे कोई सही सेट नहीं करता। जो कनेक्शन एक से ज़्यादा टीम तक पहुँचता है, वह उन्हें nessie_team_list से सूचीबद्ध करता है, और हर दूसरा टूल फिर अपने teamId का नाम लेता है।

जिस call में उसे चाहिए स्कोप नहीं होता, वह transport error के बजाय एक tool result के रूप में लौटता है, जो बताता है कि कौन-सा स्कोप माँगना है, ताकि मॉडल बार-बार एक दीवार से टकराने के बजाय कुछ उपयोगी बता सके।

बाहरी trackers के लिए टूल्स का अलग परिवार नहीं है। बोर्ड एक बोर्ड ही है, चाहे उसके tasks Nessie में बने हों या Linear, Jira, GitHub या Trello से mirror हुए हों, इसलिए एक ही tool set दोनों को कवर करता है, और हर task बताता है कि वह कहाँ से आया। अंतर लिखने में है: जो बोर्ड केवल-पढ़ने वाले स्रोत से mirror हुआ है, वह लिखने से मना कर देता है और एजेंट को साफ़ शब्दों में बताता है कि ticket पर दूसरी प्रणाली का अधिकार है, और दोबारा कोशिश करने से कुछ नहीं बदलेगा।

दस्तावेज़ प्रकाशित करना एक मंज़ूरी है, स्कोप नहीं

एजेंट ड्राफ़्ट लिखते हैं; व्यक्ति प्रकाशित करता है। यह नियम Nessie के अपने एजेंटों के लिए एक एजेंट actor को सीधे अस्वीकार करके लागू होता है — पर paired credential एक व्यक्ति के रूप में resolve होता है, इसलिए वह मना करना उसे नहीं पकड़ सकता। गेट कहीं और होना चाहिए।

तो nessie_doc_publish प्रकाशित नहीं करता। वह एक knowledge.page.publish मंज़ूरी खोलता है — वही जो एक Nessie एजेंट खोलता है — और { status: "awaiting_approval", approvalId } लौटाता है। Polling वही अनुरोध लौटाती है, दूसरा नहीं खोलती। प्रकाशन का हर फ़ैसला Nessie में उसी तरह होता है: एक व्यक्ति करता है, उस दस्तावेज़ के बारे में, उसी क्षण जब वह मौजूद होता है।

जानबूझकर कोई publish scope नहीं है। एक था — pairing के समय एक tick, जो कहता था कि यह एजेंट publish कर सकता है — और उसे हटा दिया गया। उसने एक ऐसा सवाल, जो Nessie हर जगह हर दस्तावेज़ के लिए अलग से पूछता है, एक बार और नब्बे दिन के लिए तय कर दिया, और वह उस दस्तावेज़ के बनने से पहले तय हुआ, इसलिए tick लगाने वाला व्यक्ति नहीं जान सकता था कि वह क्या प्रकाशित होने की सहमति दे रहा है। nessie_doc_publish को documents_write चाहिए, क्योंकि पूछना निःशुल्क नहीं है — वह पेज पढ़ता है और किसी के सामने फ़ैसला रखता है — पर वह स्कोप प्रकाशन के बारे में कुछ भी नहीं देता।

Request पर दो पहचानें दर्ज होती हैं, और यह अंतर निर्णायक है। requester वह क्रेडेंशियल है, कभी वह इंसान नहीं जिसके रूप में वह काम करता है। ज़रूरी approver वही इंसान है, और केवल वही जवाब दे सकता है। अगर request में उस व्यक्ति को requester नाम दिया जाए, तो वह नियम जो किसी को अपने ही अनुरोध को मंज़ूर करने से रोकता है, उसी एक व्यक्ति को अयोग्य ठहरा देगा जिसे फ़ैसला लेने का हक़ है।

Paired चीज़ें देखना और रद्द करना

किसी व्यक्ति के अपने paired agents /settings/security पर सूचीबद्ध होते हैं, हर एक के साथ एक label और रद्द करने का control। Owner या संगठन का एडमिन /admin/security?tab=programs पर संगठन का हर क्रेडेंशियल देखता है — उसका नाम, वह क्या कर सकता है, वह अभी सक्रिय है या नहीं, और वह किसका खाता उधार लेता है — और वह उनमें से किसी को भी रद्द कर सकता है। व्यक्तिगत सूची केवल खुद तक सीमित रहती है: सक्रिय क्रेडेंशियल की सूची पैर जमाने के ठिकानों की सूची होती है, सामान्य पढ़ने की चीज़ नहीं।

किसी क्रेडेंशियल के ज़रिए किए गए बदलाव उस व्यक्ति के नाम दर्ज होते हैं जो उसे उधार देता है, और audit metadata में क्रेडेंशियल का id रहता है, ताकि log बता सके कि किसी व्यक्ति ने खुद संपादन किया या उसके एजेंट ने उसके लिए।

जो अभी उपलब्ध नहीं है

साफ़ कहना ज़रूरी है, क्योंकि प्रोटोकॉल की क्षमताओं और किसी एक सर्वर की क्षमताओं के बीच का फ़ासला ही वह जगह है जहाँ documentation आम तौर पर चूकती है:

• चैट, channels, runs और agent management MCP पर उपलब्ध नहीं हैं।
• एक बाहरी प्रोग्राम newsletter तैयार करता है और एक व्यक्ति उसे भेजता है: कुछ भी campaign को न भेजता है, न शेड्यूल करता है, न मिटाता है, और email खुद designer में लिखा जाता है।
• Contacts को जोड़ना और merge करना, CRM schema में बदलाव, imports और channel setup browser में एक व्यक्ति के पास रहते हैं।
• Connecting का स्विच एक संगठन-स्तर की सेटिंग है। Team-level और personal overrides अभी कोई टीम या व्यक्ति सेट नहीं कर सकता।