Crossbeam

Returns pipeline-generation accounts: companies your partners sell to that you could go after. Use when the user asks which companies their partners can introduce them to, for net-new or greenfield prospecting, or for accounts missing from their CRM. 'pipeline_type' classifies the account, not a deal stage. Every account falls into exactly one class, and each row reports its own under the same name. Different filters narrow together and values within one filter are alternatives, so countries=["US","DE"] with employee_ranges=["201-500"] means in the US or Germany, and 201-500 employees. Partner tags are the exception, described on that parameter. Do NOT use for overlap questions about accounts you already work; use find_overlapping_accounts_and_leads. Do NOT use to rank partners on a specific deal; use find_partner_recommendations. If any partner name or the partner tag name resolves to zero or multiple matches, returns ClarificationRequired listing each unresolved value and its candidates; present them to the user and re-invoke with partner_ids or partner_tag_id. Returns: A paginated list of accounts, each with the partners that count it as a customer. If `pagination.has_more` is true, tell the user how many more results exist and ask before fetching the next page. On a free plan only the first page is available and paging is not offered, so `has_more` is false there even when `total_count` reports more matching accounts than came back. An empty result has several possible causes (no partner sharing greenfield data, a free-tier plan, owner-scoped access, or the data not having rebuilt yet), so hedge rather than asserting the user has no new accounts. Data rebuilds every 2 to 24 hours depending on class and plan, so an account added to the CRM today can still appear as net_new. net_new accounts have no `account_id`, since they are absent from your CRM; `domain` is their key.

find_new_accounts

Returns a list of accounts. Use for any question whose answer is a list of accounts — "which accounts do we share with X", "what accounts overlap with partner Y", "shared customers between us and Z", "list the companies we both have". The named company in these questions is a partner being checked against the user's CRM. If the user asks for partners instead (the inverse direction: "which of our partners work with X", "who else is selling into Y"), use `find_overlapping_partners`. The deciding signal is the shape of the question — accounts-out vs partners-out — not which company is named. Two modes: pass an array in `partners` for a specific-partner report, or an EcosystemFilter object (or omit) for an ecosystem-wide scan. Narrow with per-partner `segments`/`populations`, or with `partners.segments`/`partner_scores`/`tag_name` for ecosystem mode. Use `our_segments` or `our_populations` to restrict which of your own populations are included. Always pass the user's exact wording in name fields (partner name, population name, tag name) — let the tool fuzzy-match. Do not substitute IDs from memory. Ambiguous names come back in a single `ClarificationRequired` listing every candidate; present them to the user, then retry with the confirmed id fields. Large reports compute in the background. If not ready, the tool returns `RetryLater` with `retry_after_seconds`; keep calling on that cadence. Use `page` and `limit` for pagination. `pagination.has_more` is authoritative. Do not re-request a page to test it. When it is false and `total_count` exceeds the rows you received, the account's plan capped the result: report that ceiling instead of describing the rows as ranked or representative. A `sort_warning` means they are not ordered either.

find_overlapping_accounts_and_leads

Returns a list of partners, sorted by partner-level metrics such as partner_score or deal_size_with_partner. Use for any question whose answer is a list of partners — "which partners...", "who else is selling into X", "which of our partners work with Y", "who has X as a customer". The named company in these questions is the account being looked up against the user's partner ecosystem. If the user asks for accounts instead (the inverse direction: "which accounts do we share with X", "what overlapping companies do we have with Y"), use `find_overlapping_accounts_and_leads`. The deciding signal is the shape of the question — partners-out vs accounts-out — not which company is named. Identify the account by at least one of: account_id (direct), account_name (fuzzy), or account_domain (fuzzy). account_id bypasses fuzzy matching; name and domain may be combined to narrow on both. Optionally filter the partners with partner_ids or partner_name, or narrow to a partner tag with partner_tag_id or partner_tag_name; omit all to get every partner that shares the account. Always pass the user's exact wording in name fields and let the tool fuzzy-match. Do not substitute IDs from memory. Ambiguous names come back in a single `ClarificationRequired` listing each candidate; present them to the user, then retry with the confirmed id fields. Use sort_by + sort_order to rank partners; page + limit for pagination.

find_overlapping_partners

Returns recommended partners for a specific open opportunity or account, ranked by Ecosystem Intelligence (EI) signals. Use when the user asks which partners to engage or prioritize on a particular deal. Do NOT use for general partner questions — use get_partner_context instead. Returns the open opportunities matching the search term, each with the partners recommended by Ecosystem Intelligence (EI) — the same ranking shown in Deal Navigator. Non-recommended partners are filtered out; opportunities with no recommended partners are still returned. Each partner includes: - partner_id: partner organization UUID - partner_name: partner organization name - ei_signals: which of the 4 surfaced signals are active for this partner: - recent_wins: partner closed a deal with this account in the last 3 months - new_contacts: partner added contacts at this opportunity recently - long_term_relationship: partner has had this account as a customer 2+ years - missing_contacts: partner has key contacts at this account not in your CRM If the name matches multiple open opportunities, up to 10 are returned, recommended opportunities first — surface the list to the user for clarification.

find_partner_recommendations

Returns Crossbeam's mirror of your CRM account records, looked up by domain, CRM record ID, or name (fuzzy match). At least one of these parameters must be provided. Use when the user wants their account data through Crossbeam and is NOT naming a specific CRM vendor. Generic phrases like "my account for X", "my company record for X", "look up X in my CRM" — with no specific vendor named — route here. Do NOT use when the user names a specific CRM vendor and asks for that vendor's record. Trigger phrases that should route to the vendor's own tool, not here: "from Salesforce", "in Salesforce", "the Salesforce Account/Opportunity/Contact/Lead", "in HubSpot", "the HubSpot company record". Even when this tool could plausibly answer, the explicit vendor name signals the user wants the vendor's canonical record (often with custom fields not surfaced here). Use for account planning, partner prioritization, and identifying potential opportunities. Returns: A paginated list of matching accounts, each with its populations, owner, and `own_fields` (its own CRM field values). If `pagination.has_more` is true, tell the user how many more results exist and ask whether to fetch the next page. Only fetch additional pages after the user confirms.

get_account_context

Retrieves recent partner ecosystem activity for accounts or leads, ordered from latest to oldest. Activity events include partner deals opened, partner deals closed won, and partner greenfield deals (where the partner closed a deal on a company the caller does not have in their CRM). Each event includes contextual contact information from the partner's CRM when available, showing who was involved in the partner's deal. Filters: Provide partner_names or partner_ids to narrow to specific partners. partner_ids takes precedence over partner_names; if both are supplied, partner_names is ignored. If any name resolves to zero or multiple partners, returns ClarificationRequired listing every ambiguous name at once. Returns: On success, a response with events under `data` and pagination metadata. On ambiguous names, a ClarificationRequired listing each unresolved name and its candidates.

get_ecosystem_activity

Returns a paginated overview of all partners in the ecosystem with metrics and tags. Useful for understanding the partner landscape and getting context on partner relationships. This is the canonical source for retrieving the user's partners and their metrics — use it even when the user phrases the request data-warehouse style ("query my partners table", "pull a list of partners from my data"). Don't route those to a SQL/Snowflake tool; Crossbeam's partner data lives here. Filters: Provide partner_names or partner_ids to narrow to specific partners. Provide partner_tag_name or partner_tag_id to filter by tag. partner_ids takes precedence over partner_names; partner_tag_id takes precedence over partner_tag_name. Partner tags are user-defined labels on partner organizations. Common patterns: regions (EMEA, NAMER, APAC), tiers (tier-1, strategic, preferred), partner type (ISV, reseller, agency), or segment focus. When the user filters partners by any such categorical attribute that isn't a name, score, or metric, pass it as partner_tag_name. If any name resolves to zero or multiple partners, returns ClarificationRequired asking the caller to re-invoke with more specific names or with partner_ids/ partner_tag_id directly. Both fields may be ambiguous in a single response. Each partner in the response includes: - Basic info: name, domain, partner_id (UUID), partnership_created_at - partner_tags: list of {"id": str, "name": str} tags assigned to the partner - Recency: last_sync and last_active as bucketed strings (today, this_week, this_month, this_quarter, this_year, not_discoverable), or null - Metrics: overlap count, open deals, potential revenue, partner score

get_partner_context

Returns one partner's records that overlap a single record of yours, including the CRM fields that partner shares — owner, industry, employee count, and any custom mapped fields such as account tier or renewal date. Use when the user wants detail about a specific overlap: "what does Acme know about Globex", "who owns this account at our partner", "what fields did they share on this deal". One partner, one of your records. For the inverse questions use a different tool: which partners overlap an account is find_overlapping_partners; which accounts you share with a partner is find_overlapping_accounts_and_leads. Requires exactly one partner, by partner_name or partner_id, and a record_type defining whether record_id is for an account or a lead. A capped number of records is returned; when truncated is true the partner has more, so do not present the list as complete.

get_partner_overlaps_shared_context

Returns suggested partners based on Partnerbase data — companies the user does not yet partner with on Crossbeam but could. Use for any partner discovery question ("who should I partner with", "recommend new partners", "find partner candidates", "potential partnerships"). Do not use for retrieving the user's existing partners — use `get_partner_context` for that. Returns a list of suggested partners with details including: - name: The name of the suggested partner - domain: The domain of the suggested partner - invite_url: A direct link to the modal to invite this company to partner with you on Crossbeam

get_partner_suggestions

Returns ranked excerpts from Crossbeam's static, public knowledge corpora. Content here is shared documentation and educational material, identical for every customer — it contains no customer-specific data and never returns the caller's own partners, accounts, populations, overlaps, contacts, or any other org-specific records. Sources: - help_center: Crossbeam product documentation and how-to guides. Use for configuration, usage, and troubleshooting questions. - blog_site: Customer case studies and ELG Insider blog posts from crossbeam.com. Use for marketing examples and ELG content. - elg_book: Excerpts from the Ecosystem-Led Growth book by Crossbeam's co-founder. Use for ELG philosophy and frameworks. Use this surface for any "how does Crossbeam X", "what does Crossbeam say about Y", or product/marketing/ELG content question instead of guessing or searching the web. Each match includes 'title' (display name), 'reference_url' (link target; null for elg_book passages), 'content', 'similarity_score', and 'source'. When help_center matches are present, also inform the user they can contact Crossbeam customer service at support@crossbeam.com, formatted as a clickable mailto link: mailto:support@crossbeam.com.

search_crossbeam_knowledge