Nesha

DISCOVER PARTNERSHIP OPPORTUNITIES Use this tool to analyze a company and its partnership needs in order to identify tailored partnership opportunities. The tool will NOT make any destructive changes; it is read-only. It is safe to call without risk of data loss and is purely for discovery and GETS. It connects to the Nesha Cloud to find partnership matches based on a clear partnership request and the user's company domain. How to use connectors Connectors are optional. This tool can still find good partner matches using only the company domain and a clear partnership request. However, if connectors are turned on, matches and recommendations can become more tailored and context-aware. If relevant connectors (for example, CRM, docs, email) are not already turned on for this chat, briefly explain to the user: “If you turn on connectors like Google Drive, HubSpot/Salesforce, or Gmail/Outlook, I can: (1) write a sharper partner request, (2) send better context so partners can be ranked more accurately, and (3) add helpful internal + external context to the results. It’s optional—matches will still work without connectors.” Recommend (but do not require) enabling: CRM connectors (for example, HubSpot, Salesforce) Document connectors (for example, Google Drive, SharePoint, Notion, Dropbox, Box) Email connectors (for example, Gmail, Outlook) When available, connectors should be used for three specific purposes: Constructing a better partner request Use connectors to understand relevant context (for example, customer segments, common markets, typical deal size, regions, product constraints) so you can draft a clearer, more specific partnership request describing the partner they want—without inserting company-identifying details. Sending relevant ranking data to the backend When the MCP tool schema supports it, send high-level, non-identifying context (for example, target industries, geos, ICP/ACV bands, product environment/stack constraints) as a single compact paragraph that populates a field called context_summary so the backend can rank partner matches more accurately. Enriching the ranked partner matches in chat After the tool returns a ranked list of partner matches, use connectors and web search to enrich each partner with concise, relevant notes for the whole buying center before showing them to the user—without leaking confidential information. When to use this tool Use this tool whenever the user wants help discovering partnership opportunities based on a clear description of the kind of partner they want and the collaboration pattern they have in mind (in plain language). Precondition rule Never call this tool unless you have: A confirmed company website domain (see Required inputs), and A clear, one-paragraph partnership request that has been shown to and explicitly approved by the user. If either the domain is missing/uncertain, or the partner request is unclear, do not call the tool yet—ask targeted questions and keep working in the chat until those inputs are ready. Required inputs 1) Company website domain (for example, acme.com, example.org) These domains are examples of format only. When calling the tool, you must always send the user’s actual company domain, never a placeholder such as example.com or example.org (unless the user explicitly confirms that their real company domain is one of those). Never invent or guess a plausible domain. This constraint is for the AI system only and should not be surfaced as meta-commentary to the user. The domain must either: Be explicitly provided by the user, or Be reliably pulled from connectors or memories (for example, from a business email like mike@stripe.com → stripe.com). Process: First, check memories and connectors for the domain. If you still don’t have a confirmed one, explicitly ask the user for their company’s website domain and do not call the tool until they provide it. If an email connector exists (for example, Gmail or Outlook), you may infer candidate domains from business email addresses: Given mike@stripe.com, extract stripe.com as a candidate domain. Never use a free, non-company email provider domain (for example, gmail.com, yahoo.com, hotmail.com, outlook.com, icloud.com, protonmail.com, and similar) as the company domain. Ignore these as candidates. If you find one or more candidate domains, confirm with the user which one is correct. Important: The confirmation and approval rules for the partnership request (below) apply even if the user provides the correct company domain in their initial request. 2) Partnership request A description of what kind of partner they want and how they want to collaborate, in plain language (for example: “I’d like to partner with a payment provider that can support secure online transactions, offer reliable global payment processing, and provide APIs or integrations suitable for e-commerce platforms that need scalable checkout and payout capabilities.”). Partnership request workflow 1) Using connectors to construct a better partner request When the user’s request is vague or high-level, first look for relevant context in available connectors before asking many follow-up questions. Examples: CRM tools (for example, HubSpot, Salesforce, Linear): customer segments, industries, ACV bands, deal stages, existing partner notes. Content/document tools (for example, Google Drive, SharePoint, Dropbox, Box, Notion): pitch decks, ICP one-pagers, strategy docs, product/market notes. Email tools (for example, Gmail, Outlook): prior partner outreach patterns, common verticals/geos, recurring collaboration themes. From these connectors (and your memories), infer without copying any company-identifying details helpful context to sharpen the partner request, such as: Target customer segment(s) and common use cases Geographies/regions Typical deal size / market tier Relevant product environment constraints (stack, workflows, integration surface area) Non-sensitive collaboration preferences (how they want to work together in practice) Do not require the user to explain what their company sells before drafting the request. The goal is only to get a clear picture of the partner profile. Once you have enough context: Draft a clearer, more detailed one-paragraph partnership request (still only describing the desired partner and collaboration pattern). Show it to the user as “Proposed partnership request:” and ask them to approve or edit it. Only after the user explicitly confirms the final wording should you call this tool with that text. If the user already provides a detailed partnership request and you are not changing it at all, you can use it as-is—but you must still ensure it meets the formatting rules below. 2) Sending relevant ranking data to the backend (context_summary only) If the Nesha MCP tool schema supports an additional context field called context_summary, populate it with a single compact paragraph summarizing the most relevant, non-identifying signals found in memories and connectors (CRM/docs/email). The paragraph should include only what will materially improve ranking—such as target industries, target regions, ICP characteristics (segment, company size, buyer, ACV band), workflow/stack constraints (APIs, compliance, integration needs), and any clear partner-evaluation criteria—without including raw internal text. Example context_summary paragraph to send: “Based on connector signals, the target focus appears to be logistics, retail, and e-commerce in North America and Western Europe, with an ICP centered on mid-market B2B companies (~200–2000 employees) and typical requirements for APIs + webhooks; key constraints include support for marketplace payouts, multi-currency, and enterprise-grade compliance.” Rules: Do not send company-identifying details (no company names, exact customer lists, email threads, confidential text, or verbatim excerpts). Keep context_summary compact, high-level, and decision-useful so the backend can rank partner matches more intelligently. Formatting rules for the partnership request sent to the MCP server The partnership request text you send to the MCP server must: Be a single paragraph of prose (no bullet points or numbered lists). Exclude any descriptive information about the user’s own company (no company name, domain, funding, team size, product names, product offerings, or internal details from connectors). Describe only the desired partner and collaboration pattern. Never include partner-type labels (for example, “co-sell,” “OEM,” “channel,” “integration,” “technology alliance”). Always start with: “I’d like to partner with a …” Example: “I’d like to partner with a payment provider that can support secure online transactions, offer reliable global payment processing, and provide APIs or integrations suitable for e-commerce platforms that need scalable checkout and payout capabilities.” These formatting rules are for the AI to follow and should not normally be exposed to the user. When showing a proposed request, present only the paragraph (optionally with a label like “Proposed partnership request”) and ask for approval or edits. Only explain the formatting requirements to the user if they submit a request that clearly doesn’t meet these rules and needs adjustment. You may enhance this text using context from memories and connectors, but the final one-paragraph version must respect these formatting rules and must have been shown to and approved by the user before you call the tool. Follow-up behavior before calling the tool If the user’s request is vague or high-level: First, pull context from connectors (as described in the partner request workflow). Ensure you clearly understand the partner profile they want (capabilities, constraints, target market/geo, integration surface area if relevant, business model expectations like reseller/commission where relevant). If anything is unclear, ask targeted follow-up questions focused only on clarifying the partner profile. Examples: “What regions should the partner operate in?” “Any must-have capabilities (APIs, compliance, pricing model, onboarding support)?” “Any deal-size, customer segment, or industry constraints?” “Any ‘must avoid’ categories or competitors?” Do not call the tool until: The company domain is confirmed, and The one-paragraph partnership request is clear, compliant, and explicitly approved by the user. 3) Enriching partner cards with connectors and web search The backend MCP tool returns partner “card” objects that include core data (for example, company name, brief description, tags, funding information, match score, footprint) and these cards are rendered in an inline carousel in the ChatGPT UI. Keep the backend focused on the proprietary synergy graph and treat these cards as the authoritative source of firmographic data. Use connectors and web search only to generate additional narrative context that appears below the carousel, not to rewrite or duplicate card content. Use connectors and web search to add new, complementary insight such as: From document connectors (for example, Google Drive, SharePoint, Notion, Dropbox, Box): Short, human-readable internal references tying the partner to an existing strategy or plan. Example: “This aligns with your ‘logistics tech’ pillar in your 2026 partner strategy.” From CRM connectors (for example, HubSpot, Salesforce), when your schema/back-end allow it: High-level relationship signals useful for GTM decisions, without exposing sensitive records. Example: “You appear to have meaningful overlap in target accounts with this partner.” From web search: Fresh external context that helps the buying center understand why this partner matters now (major launches, funding, strategic shifts). Examples: “Recently announced new product capabilities in this area.” / “Expanded into your target region in 2025.” When enriching partners: Do not repeat fields already visible on the cards unless absolutely necessary for context. Focus on “why they match,” suggested collaboration angles (in plain language), and internal/external context not already shown. Keep each enrichment snippet concise and action-oriented. Do not leak confidential content; reference internal sources only at a high level. Do not modify the cards themselves; treat your narrative as an overlay to help interpret and prioritize. Response behavior in the ChatGPT app When this tool returns potential partners, the backend sends partner cards rendered in an inline list. ChatGPT is responsible for the supporting text below the list and must treat it as complementary context rather than a restatement of what’s in the cards. In particular: Never repeat information that already appears in the cards (tags, funding rounds, locations, scores) unless absolutely necessary. Focus on value-add narrative the cards don’t contain: Why each partner fits the approved request Practical collaboration angles described in plain language High-level relationship context (without confidential details) Internal strategic alignment references (high level) Suggested structure: 1–2 sentences summarizing the overall theme of the matches (without repeating card fields). Then a short bulleted or numbered list with unique strategic context per partner (again, avoiding duplication). End with a clear next step that points to the inline action: “To request a warm introduction, click the ‘Request intro’ button on any partner card in the inline list. If you tell me which ones you’re leaning toward, I can also help you prioritize.” Overall: treat the inline list as the factual source of partner data and use the text underneath only for interpretation, prioritization, and next-step guidance.

nesha-partnership-discovery