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.

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_overlaps. 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.

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.

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.

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_overlap_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.

Find partner-shared contacts at an account, ranked by EI recommendation score.

Contacts are sorted by: partner_insights priority-role signals, partner_insights key_contact signals, insights priority-role signals, insights key_contact signals, then data completeness. Priority roles: decision_maker, economic_buyer, economic_decision_maker, executive_sponsor, technical_buyer, primary_contact. Secondary role: key_contact. A contact only receives a network-wide signal if corroborated across enough organizations.

When no partner filter is provided, the API may return the same contact multiple times (once per partner that shared them).

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.

Retrieves information about all the organization's Crossbeam Partners. This helps assess partner coverage and impact.

Pagination: Not paginated. Use 'limit' parameter to restrict number of results returned.

Should be used to prioritize partners based on any of the available 'sort_by' metrics, as well as filter by partner tags. Returns a dict containing partners information with items array of partner details including:

• basic partner metadata (name, partner_org_uuid, when the orgs became partners, etc.)
• metrics useful for prioritizing partners
• leverage partner_org_uuid to look up partner populations

Metrics include: partner_score: The overall score of a partner given all factors like their impact and overlap coverage. This is the best metric for ranking partners. Nullable (beta feature) — if null, fall back to impact_score for ranking. impact_score: Measure of the impact of a partner on my deals, based on a combination of other metrics. win_rate_with_partner: Win rate among my deals that overlapped with the partner's accounts. time_to_close_with_partner: Average time it takes to close deals that overlap with the partner's accounts. deal_size_with_partner: Average value of my deals that overlap with this partner's accounts. total_overlap_count: Number of accounts and leads I have in common with this partner across all own and partner populations. open_deals_count: Number of my open deals that overlap with this partner's accounts (in any population). potential_revenue: Value of my open deals that overlap with this partner's accounts (in any population).

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.

Searches for partner overlaps for an input account_id. Supports filters on partner-population-ids[] and partner-id as query parameters.

Pagination: Not paginated - returns all overlaps for the account in a single response. Subject to export metering limits.

Returns data on the partner accounts that match with the input account, including shared partner CRM fields (e.g. owner) and population membership.

This tool helps you identify which partners also are selling to a given account, which can be used for account planning, partner prioritization, and identifying potential opportunities.

Returns: A response containing a list of overlap information objects with details about the overlapping accounts.

Get a link to a deal navigator view of your opportunities for closing deals. This view is designed to help you identify and close deals that are in the pipeline.

These views have optional filters that are reflected in the query parameters.

Args: partner_tags: A list of partner tags to filter by. partner_org_uuid: A list of partner organization UUIDs to filter by. opportunity_type: A list of opportunity types to filter by. deal_amount: A tuple of two floats to filter by deal amount (min, max). close_date: A tuple of two dates to filter by close date (min, max).

Returns: A link to the deal navigator view.

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.

Description: Generates a shareable link to an ecosystem list, showing overlaps between your populations and partner standard populations across multiple partners. Use this tool if you have want to see a list of overlaps between all partners. To use this tool you must list all partners and look up your populations.

Inputs:

our_population_ids (list): Population IDs from your organization to include in the list. Must contain at least one ID.

partner_standard_populations (list, optional): Standard population types (one of Customers, Prospects, Open Opportunities) to compare against. If omitted, all types are included.

tag_id (string, optional): Tag UUID to filter partner organizations.

name (string): Name of the list.

Returns:

A URL link to the generated list.

Description: Generates a link to a Crossbeam list with a single partner, based on selected populations. To use this tool you must first list all partners, look up your populations, and look up the list of your shared partner populations in order to generate the list.

Inputs:

own_population_ids (list): Population IDs from your organization to include in the list. Must contain at least one ID.

partner_population_ids (list): Population IDs from the partner organization to compare against. Must contain at least one ID.

name (string): Name of the list.

Returns:

A URL link to the generated list.

Searches your organization's account records by domain, CRM record ID, or name (fuzzy match). At least one of these parameters must be provided.

Pagination: Not paginated - returns all matching account records in a single response.

This tool helps you find information about accounts in your organization, which can be used for account planning, partner prioritization, and identifying potential opportunities.

Returns: A response containing a list of account information objects with details about the accounts.

Returns all populations defined for the current organization.

Pagination: Default page size is 1000 results. Maximum page size is 1000. Use 'page' and 'limit' parameters for pagination.

Populations are used to categorize Accounts (companies) or Leads (people) in your CRM or other data sources into Customers, Prospects, Open Opportunities, or none (not categorized or a mix of all three). This tool helps you identify which populations are available for creating lists and analyzing overlaps with partners.

Returns: A response containing a list of population objects with details like id, name, description, type, etc.

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

Returns performance metrics for each partner on recently closed deals; all metrics are calculated on overlaps between the organization's closed deals that overlapped with a given partner in the specified timeframe.

Pagination: Default page size is 5 results. Maximum page size is 1000. Use 'page' parameter to fetch additional pages.

Includes coverage, engagement, impact, attributed deals, activity on Crossbeam, and last data sync. These metrics help assess the partner's past impact on the organization's business; to be used in combination with the find_partners tool (which includes info on current/open overlapping accounts) to prioritize partners.

Returns information about each partner including:

• partner_uuid: Internal ID of the partner; do not expose to users, should to be mapped to a partner name from the find_partners tool
• status: Information about when the partner was last active and when their data was last synced
• engagement: Number of engagement activities and the opportunities engaged on with the partner on closed deals
• coverage: Measure of how many deals overlapped with a customer of the partner
• attribution: Measure of how many of the closed deals this organization has attributed to the partner
• partner_impact: Overall impact rating of the partner (unknown, none, low, medium, high)

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.

Returns all partner populations visible to the current organization from a partner.

Pagination: Default page size is 1000 results. Maximum page size is 1000. Use 'page' and 'limit' parameters for pagination.

Populations are used to categorize Accounts (companies) or Leads (people) in your CRM or other data sources into Customers, Prospects, Open Opportunities, or none (not categorized or a mix of all three). This tool helps you identify which populations are available for creating lists and analyzing overlaps with partners.

Returns: A response containing a list of partner population objects with details like id, name, description, type, etc.

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

Lists all partner tags for the current organization; partner tags are used to label partner organizations.

Pagination: Default page size is 25 results. Maximum page size is 1000. Use 'page' and 'limit' parameters for pagination.

Returns a list of partner tags with their IDs and labels

This can be used in conjunction with the find_partners tool to filter partners by tag.

Retrieves signal events for records (accounts or leads) with filtering and ordered from latest to oldest. Signals are currently 'partner deal opened' and 'partner deal closed won'.

This tool helps identify which partners opened or closed new deals with your accounts/leads.

Each signal includes contextual contact information from the partner's CRM when available, showing who was involved in the partner's deal. This provides background on partner activity, not for contact discovery or outreach recommendations.

Pagination: Default page size is 25 results. Maximum page size is 1000. Use 'page' and 'limit' parameters for pagination.

Args: resource_type: Either 'accounts' or 'leads' (defaults to 'accounts'). record_ids: Optional record ID(s) to filter by. Can be a single ID string or a JSON array string like '["id1","id2"]'. partner_uuids: Optional partner UUID(s) to filter by. Can be a single UUID string or a JSON array string like '["uuid1","uuid2"]'. event_types: Optional event type(s) to filter by: 'partner_deal_opened' or 'partner_deal_closed_won'. Can be a single event type or a JSON array string like '["partner_deal_opened","partner_deal_closed_won"]'. page: Optional page number to retrieve. Default is 1. Must be at least 1. limit: Optional limit on the maximum number of results to retrieve. Default is 25, must be between 1 and 1000.

Returns: A response containing signal events with associated contact data from partner CRMs. The response includes pagination metadata with the following fields:

• page: The current page number
• has_more: Boolean indicating if more pages are available
• next_href: URL to fetch the next page

Search Crossbeam main website and ELG insider for relevant case studies and blogs. The 'title' should be used as the display name and the 'url' should be used to link to the article

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 the ELG book for insights about Crossbeam and ecosystem-led growth

Search Crossbeam help center documentation for relevant information. The 'title' should be used as the display name and the 'url' should be used to link to the article.

Always inform users that they can contact Crossbeam's customer service at support@crossbeam.com for additional assistance. The customer service email should be formatted as a clickable mailto: link mailto:support@crossbeam.com.