Boomerang

Assign one or more workspace roles to an existing user by user_id (internal keycloak UUID — never say this to the user). Existing roles are preserved — new roles are added incrementally. Valid roles: OWNER, ADMIN, SUPER_CONNECTOR, SUPER_CONNECTOR_ADMIN, REQUESTER, TECHNICAL_ADMIN. Does NOT set email, name, phone, LinkedIn, or Super Connector category. Do NOT use to onboard new Super Connectors — add_super_connector creates the user, assigns the Super Connector role, and places them in a category in one call. USER-FACING COPY after success: e.g. 'Requester role has been assigned to Manthan.' — never say 'add_role', 'tool call', or enum strings like REQUESTER in user messages; use 'Requester', 'Admin', 'Super Connector'.

Use when: Use ONLY after the person exists in the workspace (typically after create_workspace_member for non-SC members). Do NOT call on add-member form submit. Do NOT use for new Super Connector onboarding — use add_super_connector instead. Do NOT assign SUPER_CONNECTOR via add_role when adding a new Super Connector. After assigning, confirm in plain language only — do not explain internal steps or tool names to the user.

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] user_id (keycloak_user_id) must be known — typically from create_workspace_member response or search_workspace_members. Verify: For new members: call create_workspace_member first and use keycloak_user_id from the response. Do not call add_role with only a role and no user_id. Do not call add_role instead of create_workspace_member when the add-member form was submitted with email. [optional] Do not use add_role with SUPER_CONNECTOR to onboard a new Super Connector. Verify: If the user wants to add a Super Connector, use add_super_connector on form submit instead — it handles user creation, role assignment, and category placement.

Add an emoji reaction to a Slack message. Emoji name is given without colons, e.g. thumbsup.

Use when: Use to acknowledge a request or signal progress without posting another reply.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Add a Super Connector to the workspace in one step — creates the platform user if needed, assigns the Super Connector role, and places them in the selected category (provisions category ledgers). Do NOT call create_workspace_member or add_role for this flow. For new Super Connectors: (1) call get_workspace_categories to populate a required Category dropdown (filter relationship_type SUPER_CONNECTORS), (2) render an add–Super Connector form with required fields Email, First Name, Last Name, LinkedIn ID, and Category — do NOT label any field optional, (3) on Submit call THIS tool with email, first_name, last_name, linkedin_id, and category_ids. first_name and last_name are ALWAYS required, even when promoting from an existing LinkedIn connection record — that record's name is not auto-filled server-side, so if you don't already have the person's first and last name, ask the user for them before calling; do not call this tool speculatively with required fields missing or blank. USER-FACING COPY after success: e.g. 'Jane has been added as a Super Connector.' — never expose tool or API names.

Use when: Use whenever an admin adds a new Super Connector. This is the ONLY tool for Super Connector onboarding — do NOT use create_workspace_member or add_role. Call get_workspace_categories first to load the Category dropdown. On form submit, call add_super_connector with all form values in a single call.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] Super Connector category options must be loaded before rendering the form. Verify: Call get_workspace_categories and filter to relationship_type SUPER_CONNECTORS. User must select at least one category before submit.

Returns category_ledger_results[] with fields: category_id ledger_id ledger_created

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Group, count, and rank records across any Boomerang entity. group_by and metrics use typed enums — only supported groupings are expressed, backend maps each to the right DB column. Supports OR/AND filter composition via FilterGroups, having clauses for threshold filtering ('accounts with 3+ paths'), anti-joins for NOT EXISTS queries ('accounts with no intro request'), and cursor pagination for large result sets. COUNTING RULE: for 'number of paths' questions always use AGG_OP_COUNT_DISTINCT on REL_METRIC_RELATIONSHIP_ID — never AGG_OP_COUNT on REL_METRIC_STAR, which inflates counts when rows join-duplicate across categories or path types. GROUP-BY HYGIENE: always include the _ID group field alongside _NAME for accounts/users/contacts (e.g. both REL_GROUP_TARGET_ACCOUNT_ID and REL_GROUP_TARGET_ACCOUNT_NAME) — this surfaces name-casing duplicates ('IBM' vs 'ibm') as distinct IDs rather than silently merging or confusingly splitting them. QUALITY vs VOLUME: raw path counts include weak/unlikely connections that inflate rankings. When ranking without a strength filter, proactively note that results include low-confidence paths and offer to re-run filtered to CONFIRMED/STRONG strength for a quality-adjusted ranking.

Use when: Use for counting, ranking, grouping, breakdowns, and threshold questions. TRIGGER PHRASES: 'top N', 'most', 'how many', 'group by', 'breakdown by', 'which has the most', 'accounts with 3+', 'leaderboard', 'rank the connectors/accounts', 'best path to X', 'strongest connections to X', 'who can introduce me to X', 'who knows someone at X', 'which connector/account has the most/strongest paths to X'. KEY PATTERN — ranked-by-source filtered-to-one-target: a question like 'top 5 connectors who can reach Salesforce' reads like a lookup but is really group ENTITY_RELATIONSHIP by source user, filtered to target account — always use Aggregate for this, never page through raw relationship rows. Set limit for top-N. Use having for post-aggregation thresholds (e.g. 'accounts with 3+ paths'). For OR filters (e.g. 'ICP match OR CONFIRMED strength') pass multiple FilterGroups. Use page_token + next_page_token to paginate large result sets.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns rows[] with fields: fields

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Attach tags by name to one or more entities (accounts, contacts, workspace members). Tag names that do not exist yet are created automatically; matching is case-insensitive. Additive — tags already on an entity are kept. Single assignment = one entity id and one name.

Use when: Preferred way to tag entities. Use for both single and bulk tagging; no need to call CreateTag first.

workspace_id / user_id are injected from request headers.

Returns entities[] with fields:

entity_id tags Returns created_tags[] with fields: id name entity_type

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Render a Slack Block Kit table block array from column headers and body rows. Returns blocks_json to pass through as slack_blocks.

Use when: Use for tabular previews inside a Slack reply (50 rows by default). Use build_slack_table_from_json when you cannot pass nested lists.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Render a Slack Block Kit table from JSON-encoded headers and rows strings.

Use when: Use instead of build_slack_table when you can only pass flat strings rather than nested lists.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Set the category on one or more accounts. Valid categories: CUSTOMER, PROSPECT, OPEN_OPPORTUNITY, CLOSED_LOST, CHURNED, PARTNER, COMPETITOR, OTHER — exactly one per account, and setting a new one replaces the old. Accounts are identified by internal UUID, not name or CRM id. Returns updated_count plus skipped_account_ids: an account is skipped when the id does not exist in this workspace, so a non-empty skipped list means those ids were wrong, not that the write failed. To attach tags use the Tagging service instead.

Use when: Use when the user asks to classify, label or re-classify accounts — 'mark these as customers', 'move Acme to Prospect'. Resolve account UUIDs first via search_accounts_with_filters or get_accounts_by_ids; never guess them. This writes to the workspace and is visible to every user in it, so confirm the account list with the user before calling when the selection came from an ambiguous search.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Create one or more accounts in bulk. Each account carries its own optional category and category_source — a batch can mix a CSV upload row (LEDGER_IMPORT), a publicly-researched company (PUBLIC_RESEARCH), and a manually-entered one (MANUAL) in the same call. Accounts are deduplicated against existing ones by CRM reference id, LinkedIn company id, then LinkedIn handle — a match returns the existing account rather than creating a duplicate. Leaving category unset defaults the account to Prospect with source DEFAULT. Returns one entry per resulting account (created or matched), in no particular correspondence to input order — a batch of 10 inputs can return fewer than 10 rows when some dedup to the same existing account.

Use when: Use when the user wants to add accounts in bulk, e.g. from a CSV or a list of company names. Setting category requires setting category_source alongside it.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Returns accounts[] with fields: id name reference_id category

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Map a Boomerang canonical field to the connected CRM's own field/property name, for a given CRM object type.

Use when: Use after create_crm_specification, when a prepared statement's SELECT/properties needs to reference a CRM-native field name that differs from Boomerang's canonical name (e.g. Salesforce's "Type" vs HubSpot's own property key).

workspace_id / user_id are injected from request headers.

Define a named CRM query/mutation (statement_key) for a registered CRM specification, in the connection's native format (SOQL, REST_JSON, etc). The chosen statement_key enforces a hardcoded required variable server-side — see the StatementKey enum docs.

Use when: Use after create_crm_specification to define how to run a specific check (e.g. GET_CUSTOMER_ACCOUNTS_BY_IDS) against the connected CRM. Include every variable the chosen statement_key requires in variables; if the call fails with FAILED_PRECONDITION naming a missing variable, add it and retry.

workspace_id / user_id are injected from request headers.

Returns variables[] with fields: name: Variable name as referenced in statement_text (e.g. "domain"). data_type required default_value description

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Register a CRM connection (Salesforce/HubSpot) for a workspace. Returns a CrmSpecificationResponse whose id is required by create_crm_prepared_statement and create_crm_field_mapping.

Use when: Use once per CRM connection, before defining any prepared statements or field mappings for it. connected_user_id is the Boomerang user who owns the integration, not a CRM record id.

workspace_id / user_id are injected from request headers.

Create one or more self-declared relationship paths. A super connector manually asserts they know a target account or contact, which is stored as a SELF_DECLARED_ACCOUNT or SELF_DECLARED_CONTACT path and used to surface warm intro opportunities.

Use when: Use when a team member (super connector) wants to declare that they personally know a contact or have a relationship with an account, and this relationship was not automatically detected via calendar or LinkedIn signals.

workspace_id / user_id are injected from request headers.

Returns items[] with fields:

relationship_path validation_errors success Also returns pagination info (type, message, status).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Create a workspace tag for an entity type. Names are unique per entity type, case-insensitively.

Use when: Use when the user asks for a label that does not exist yet and you are not attaching it to anything. To create and attach in one step, prefer AssignTagsByName.

workspace_id / user_id are injected from request headers.

Also returns pagination info (id, name, entity_type).

Create a workflow trigger for a recipient. Two kinds: (1) SCHEDULED — Temporal cron or one_time_fire_at in absolute UTC (default); (2) WEBHOOK — Composio inbound CRM event, no cron. Always set name, ≤100-char description (never copy the prompt), prompt, channels, scope (USER|WORKSPACE), and draft metadata.preview per channel. For WORKSPACE also set activation_mode: WORKSPACE_MANDATORY (runs for everyone in the audience; no per-user opt-in) or WORKSPACE_OPT_IN (shared template teammates enable individually). For WEBHOOK also set trigger_kind=WEBHOOK and metadata.supported_events (or pass template_id from an admin WEBHOOK trigger_template so the backend inherits kind + supported_events). For SCHEDULED provide exactly one of cron or one_time_fire_at. When creating from an admin template seed, copy template_id, trigger_kind, and metadata.supported_events verbatim from the seed JSON — never invent event slugs.

Use when: Use for a new reminder/schedule OR a new event-driven HubSpot/Salesforce notification, OR to opt-in/activate an existing WORKSPACE_OPT_IN catalog template for the requesting user (pass catalog_id from create/list — that creates a USER activation; do not use updateWorkflowTrigger for first-time opt-in). Ask scope=USER vs WORKSPACE before free-form creates. If WORKSPACE, ask whether it must run for everyone with no opt-in (activation_mode=WORKSPACE_MANDATORY, workspace admin) or be a template teammates enable (WORKSPACE_OPT_IN). If the conversation seed includes a workflow_trigger_template_context JSON block, this is a template create: pass template_id + trigger_kind + metadata from that block, put template instructions into prompt (customize with the user), omit cron for WEBHOOK, and do not invent supported_events. If there is no seed but the user wants an admin template, call listTriggerTemplates first and copy id → template_id. Call list_workflow_triggers first to avoid duplicates. Always draft metadata.preview for the channel(s) in use.

workspace_id / user_id are injected from request headers.

Add or update a non–Super Connector workspace member. Email is required — this tool upserts by email. Do NOT use for new Super Connectors — use add_super_connector instead (it creates the user, assigns the Super Connector role, and places them in a category in one step). For new members (Requester, Admin, etc.): present an interactive add-member form UI with required fields Email, First Name, Last Name, plus optional Phone and LinkedIn URL. Never block submit on the optional fields. The form has NO role field — roles are assigned separately via add_role after this call succeeds. On form Submit: call THIS tool with all submitted identity fields. NEVER call add_role on form submit. Do not ask for identity fields in plain chat when a form is shown. For updates: if email was not provided, ask the user to supply it. If they do not know the email, collect other identifiers, call search_workspace_members to find matches (or search_users if they may not yet be a workspace member), present the best match with name and email, and ask 'Is this the person you want to update?' — only call this tool after the target member is confirmed and email is known. Creates the platform User if needed, then creates or updates the workspace membership. Returns keycloak_user_id (internal — never say this to the user). Does NOT assign workspace roles. USER-FACING COPY after success: e.g. 'I've added Manthan to the workspace.' If a role was discussed earlier: 'Would you like me to assign the Requester role?' — never say 'create_workspace_member', 'membership created', 'no role assigned', or explain which tool ran.

Use when: Use to add or update workspace members who are NOT Super Connectors. If the user wants to add a Super Connector, use add_super_connector instead — do NOT call create_workspace_member or add_role for that flow. ADD flow (non-SC): (1) render add-member form → (2) user submits → (3) call create_workspace_member with all identity fields — NOT add_role. (4) If a role was discussed (e.g. Requester, Admin), call add_role after success using keycloak_user_id from the response. UPDATE flow without email: search via search_workspace_members, confirm identity, then call with resolved email.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] Email must be known and the target member confirmed before calling. Verify: If email was not provided, ask the user for it. If unavailable, collect name, LinkedIn URL, and/or phone, call search_workspace_members (or search_users if needed), show the top match(es) with name and email, and get explicit user confirmation ('Is this the person you want to update?') before proceeding. For new members, render the add-member form UI and wait for submit — do not call with guessed values.

Next steps (after this tool succeeds): [optional] [SUGGESTION] → call add_role: Tell the user they were added successfully (use their name). If a non–Super Connector role was discussed earlier, assign it via add_role (plain language confirmation only). Never mention tool names, API calls, membership records, or internal IDs.

Also returns pagination info (created_at, updated_at, created_by, updated_by, deleted_at, deleted_by).

Delete the single MEMORY document for a USER or WORKSPACE scope. Soft-deletes the row (audit history preserved). Idempotent — a missing row returns deleted=false.

Use when: Use when the user explicitly asks to clear their scoped memory. Prefer UpsertScopedMemory to update, not delete-then-recreate.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Return live enum values for every FilterableField, GroupByField, and MetricField per entity — generated from real workspace data, not hand-maintained lists. Use to discover which strength values, path_types, or categories exist before filtering on them.

Use when: Call when unsure which enum values are valid for a field in the current workspace (e.g. which relationship categories exist, which path_types are populated). Response is workspace-specific.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns entities[] with fields: entity filterable_fields: All FilterableField values valid for this entity, with enum values and supported ops. supported_group_by: All GroupByField values valid for this entity. supported_metrics: All MetricField values valid for this entity. supported_columns: All ResponseColumn values valid for this entity.

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

For a list of target accounts, find the current buying committee at each account that a super connector can warmly reach (they overlapped in tenure at that account), then create the contacts and WORK_OVERLAP relationship paths. Returns each contact with the connecting super connector, title, tenure overlap, and — when relevance ran — an assistant relevance verdict. This WRITES data: it creates contacts and relationship paths. Only accounts that carry a super-connector relationship and whose workspace has a buying_committee_regex produce results.

Use when: Use when a rep or admin wants to surface (and materialize) the warm buying committee for specific target accounts on demand, rather than waiting for the background automation. Pass the target account ids. Leave run_relevance false unless the caller explicitly wants the slower LLM relevance filter for very large companies.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Returns contacts[] with fields: account_id account_linkedin_id account_name super_connector_keycloak_user_id super_connector_linkedin_id contact_id contact_linkedin_id contact_first_name contact_last_name contact_title connecting_company_size overlap_months relevance_evaluated relevance_decision_yes relevance_score path_created

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Fetch main-timeline messages from a Slack channel or DM, optionally bounded by oldest/latest timestamps. Threaded replies are not included.

Use when: Use for channel-level context. Use fetch_slack_thread instead when you need replies inside a thread.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Fetch the parent message and replies for one Slack thread. Returns only that thread, never unrelated channel timeline messages.

Use when: Use when the injected thread history is truncated or missing and you need the full conversation.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Upload and manage files. Drop files here to send them to the server.

Find candidate companies by name, region(s), industry list, and/or employee-count band. Returns ranked CompanyCandidate entries (social_id, name, industry, company_size, employees_num, country_code, match_score) plus total_matched and truncated. Use the returned social_id as company_social_ids input to search_people_by_location_and_seniority.

Use when: Use BEFORE any company-anchored people search, including when the user named a company by name rather than by LinkedIn id — resolving a name here (rather than passing company_name straight to the people-search tool) avoids an ambiguous-match rejection. Also use directly for 'find companies like X' or 'companies in Ohio, industrials, 200-1000 employees' style requests that are themselves the goal (e.g. before an ICP sweep).

Behavior: read_only, idempotent

Returns candidates[] with fields: social_id name industry company_size employees_num country_code match_score icp_industry icp_industry_categories

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Resolve a Slack channel by name (#general) or id (C…) and return its id, name and membership state. Uses synced workspace channel mappings first, then conversations.info.

Use when: Use to turn a channel name from the user into a channel_id before sending or reading messages.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

List the account categories: the fixed vocabulary (Customer, Prospect, …) with display labels.

Use when: Use to populate a category picker before calling BulkSetAccountCategory.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns categories[] with fields: category label

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Retrieve the stored company profile (research document) for the workspace. Returns a structured object with sections: one_line_summary, value_proposition, pain_points, proof_points, competitors, customer_industry_category, customer_industry, departments, seniority, title_keywords, title_regex, buying_committee, buying_committee_regex, extended_buying_committee, extended_buying_committee_regex, company_size, named_customers, named_investors. IMPORTANT — rendering instructions: do NOT dump raw JSON, bullet lists of keys, or plain text paragraphs in chat. After fetching, render the full document as a self-contained editable UI (React or HTML artifact) — the user must review and edit each section inline.

Use when: Use when the user wants to view or edit the company profile / company research for the workspace. After the tool returns, IMMEDIATELY render the editable artifact UI in the same turn — do not summarize the JSON in prose. If the response contains no document or all sections are empty/null, tell the user 'No company profile has been generated yet' and prompt them to generate one from the app — do NOT render an empty artifact. GenerateCompanyResearch is not an exposed MCP tool so it cannot be called directly; direct the user to trigger generation from the Boomerang app, then call get_company_profile again once they confirm it is ready.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Next steps (after this tool succeeds): [REQUIRED] [ACTION] → call update_company_profile: MANDATORY same turn: render the returned data as an editable company profile artifact UI with labeled sections and a Save button wired to update_company_profile. Do NOT echo JSON or field values as chat text.

Also returns pagination info (researched_on, company_name, company_url, one_line_summary, value_proposition, pain_points, proof_points, competitors, customer_industry_category, departments, seniority, title_keywords, company_size, named_customers, named_investors, title_regex, buying_committee, buying_committee_regex, customer_industry, extended_buying_committee, extended_buying_committee_regex).

Fetch a previously-registered CRM specification by its own id.

Use when: Use when you already have a CrmSpecification id (from create_crm_specification's response) and need to confirm its connection_source or check is_deleted.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Get the logged-in user (requestor) for this MCP session.

Call this when you need to know who is authenticated — for example when the user asks "who am I?", when a workflow needs the current user's ID, or before calling tools that act on behalf of the requestor (intro requests, relationship actions, workspace membership checks, etc.).

The returned user_id is the Keycloak subject (sub claim). This is the same identifier injected as user_id on workspace-scoped tool calls via request context.

Returns: The requestor's user_id plus basic profile fields from the access token when available (email, name).

Get information about the workspace you are currently working in.

Call this when the user asks which workspace they are in, or wants details about their active workspace (name, type, description, contact stats, etc.).

Returns: Workspace details for the active session workspace, or an error if none is selected.

Fetch the latest AI-generated draft of a specific type for an intro request. After request_intro, this is an automatic mandatory follow-up — call without asking the user. Call once per draft type: GHOSTWRITTEN_EMAIL (email the requester sends directly), FORWARDABLE_EMAIL (email the referrer / SUPER_CONNECTOR workspace member forwards), and TEXT (plain-text message). Returns the draft content so the user can review and edit it before the intro request is submitted. IMPORTANT — rendering instructions: do NOT dump raw JSON or plain text. After fetching drafts, render each one in an editable UI matched to its type — the user must be able to change fields inline and save. For GHOSTWRITTEN_EMAIL and FORWARDABLE_EMAIL: render a self-contained editable email composer (React or HTML artifact) styled like an email client — editable inputs for From, To, CC, and Subject; an editable textarea or rich-text area for Body. Label each card with its draft type (e.g. 'Ghostwritten Email', 'Forwardable Email'). Include a Save button per draft that calls update_draft with is_manually_edited=true and the edited email_content. For TEXT: render an editable textarea pre-filled with the message and a Save button that calls update_draft with the edited text_content. Use tabs or cards when showing multiple drafts. Render as an artifact so the user can review, edit, and save outreach copy before submitting the intro request.

Use when: Call automatically in the same turn immediately after request_intro succeeds — do NOT ask 'Want me to pull those up?' Call three times — GHOSTWRITTEN_EMAIL, FORWARDABLE_EMAIL, TEXT — using intro_request_id from the request_intro response, then render all results in editable email/text UI with Save wired to update_draft. Only proceed to intro_request_send_state_change_event (INTRO_REQUESTED_EVENT) after the user has reviewed (and optionally saved edits to) the drafts.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Next steps (after this tool succeeds): [optional] [ACTION] → call update_draft: When the user edits a draft in the UI and clicks Save, call update_draft with is_manually_edited=true and the full edited email_content or text_content. [optional] [SUGGESTION] → call intro_request_send_state_change_event: After the user has reviewed and saved any draft edits, submit the intro request for admin review.

Also returns pagination info (request_context).

Poll an email extraction job. Returns status and progress counters. When status is COMPLETED, PARTIALLY_COMPLETED, or FAILED, also returns results[] with each contact's email (if found), email_status, resolved_vendor, and row status. Poll until terminal; do not invent emails.

Use when: Use after submitEmailExtractionJob (or any flow that returned a job_id) to check whether extraction finished. Read results from this response when the job is terminal — no separate results call is needed.

Behavior: read_only

Returns results[] with fields:

row_id first_name last_name company_name company_domain email email_status confidence resolved_vendor status boomerang_identity_id Also returns pagination info (seconds, nanos).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Fetch the tags attached to specific entities, keyed by entity id. Entities are addressed by internal UUID.

Use when: Use when you already have entity ids and need their tags — e.g. showing why an account was grouped a certain way.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns entities[] with fields: entity_id tags

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Return whether this workspace has an active Google Calendar integrations connection and whether domain-wide delegation can access the given user's calendar.

Use when: Use only for internal routing to decide managed vs Composio calendar tools.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Return whether this Boomerang workspace has an active managed Slack app connection (not Composio). Used for tool routing.

Use when: Use only for internal routing to decide whether managed Slack tools apply; not for sending messages.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Exact lookup of a single person by LinkedIn handle/vanity name (or full LinkedIn URL), returning their profile and full work-experience history. Use this instead of search_people when the user gives you a specific LinkedIn profile URL or handle.

Use when: User supplies a LinkedIn URL or bare handle and wants that specific person's profile and/or career history — not a filtered search.

Behavior: read_only, idempotent

Returns experiences[] with fields:

title company_name company_social_id start_date end_date is_current Also returns pagination info (full_name, current_title, current_company, location, country_code, linkedin_url, social_followers, person_social_id).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Find Power Users in this workspace who appear to have left the employer originally declared for them on import, detected in the last 30 days. Not scoped to any notion of account ownership — returns every matching Power User workspace-wide (optionally filtered to one account). Returns, per person, a LinkedIn profile URL, which account they're associated with (the account itself IS their new/current employer), their past/declared company and (best-effort) title, their current title/tenure as last resolved from profile data, and an approximate job-change-detected timestamp.

Use when: Use when you need to check whether any Power User in this workspace has moved to a new employer in roughly the last month. Only job changes detected within the trailing 30 days (as of the call) are returned — there's no way to widen or shift this window via the request. Omit account_id to search the whole workspace; pass account_id to scope to one specific account (a plain filter, not an ownership check). Workspace is taken from session context.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool):
  [optional] Do not treat left_provided_company as a confirmed job change — it is a signal derived from resolved company records, which can be stale or wrong.
    Verify: N/A — this is a standing caveat on every result this tool returns, not a precondition to check beforehand.

Next steps (after this tool succeeds):
  [REQUIRED] [ACTION]: Before acting on any result (e.g. drafting outreach, notifying a rep), independently verify the job change is genuine — e.g. a web search or LinkedIn lookup for the person's current role.
  [optional] [SUGGESTION]: If page_info.total_pages is greater than page_info.current_page_number + 1, call this tool again with page_number incremented by 1 to retrieve the remaining results.

Internal fields — available for follow-up tool calls but do NOT display to the user: `relationship_path_id`, `power_user_id`

Returns results[] with fields:

relationship_path_id account_id: CRM account UUID this Power User is associated with. account_name: Name of the CRM account this Power User is associated with. account_owner_email: [redacted] power_user_id user_linkedin_id power_user_linkedin_url: Full LinkedIn profile URL for this Power User — use this to look up their current role and verify the job change before acting on it. first_name last_name connector_email: [redacted] provided_company_name provided_company_domain provided_company_linkedin_id resolved_provided_company_linkedin_id past_title current_company_name current_company_linkedin_id current_title current_company_start_date current_company_end_date is_current left_provided_company job_change_detected_at import_extras Also returns pagination info (total_pages, current_page_number, page_size, total_count).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Fetch a single referrer request by its UUID for a specific referrer (workspace member with SUPER_CONNECTOR role). Returns full details including current state, decline reason, reason text, and timestamps.

Use when: Use when you have referrer_request_id and referrer_id (the workspace member with SUPER_CONNECTOR role) and need full details of that connector leg — status, decline reason, or timestamps before SendStateChangeEvent.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Internal fields — available for follow-up tool calls but do NOT display to the user: actor_id

Also returns pagination info (reason, declined_reason, acted_on_behalf_of_referrer).

Load the single MEMORY document for a USER or WORKSPACE scope (full markdown_body).

Use when: Use before maintaining memory: retrieve the existing scoped memory document to merge an observation into it.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (id, slug, family, scope, workspace_id, user_id, display_name, description, injection_strategy, priority, enabled, publish_status, tags, tool_binding_key, activation_conditions_json, visibility_conditions_json, metadata_json, published_version, created_at, updated_at, created_by, updated_by, latest_version, session_id, entity_type, entity_id).

Fetch how and why a super connector was provisioned (roles, qualifying company, investor / public-research / calendar evidence, and a human-readable notes summary) so closeness to the workspace can be judged.

Use when: When assessing how strong or close a specific super connector's relationship to the workspace is, given who provisioned them and why.

Behavior: read_only, idempotent

DEPRECATED.

workspace_id / user_id are injected from request headers.

Also returns pagination info (roles, reason, qualifying_company_name, qualifying_company_linkedin_id, producer, investor_evidence, public_research_evidence, calendar_evidence, notes, summary, relevance_score, relevance_band, relevance_scored_at).

Fetch how and why one or more super connectors were provisioned (roles, qualifying company, investor / public-research / calendar evidence) together with their relevance verdict — summary, relevance_score (1-100 against the workspace's own company), and relevance_band (HIGH/MEDIUM/LOW) — so closeness to the workspace can be judged. Accepts 1..N super connector ids in a single call — always prefer this over calling repeatedly per id.

Use when: When assessing how strong or close one or many super connectors' relationships to the workspace are, given who provisioned them and why. Prefer relevance_band / relevance_score and summary when present; fall back to notes for connectors that have not been scored yet. Use this for both single-id and multi-id lookups.

Behavior: read_only, idempotent

workspace_id / user_id are injected from request headers.

Returns entries[] with fields: super_connector_id provisioning_evidence

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Fetch available filter option values (seniority, location, category, strength, relationship path type, department, account owner, industry, country, employee size, ICP) for warm intro paths scoped to a reference entity (account, contact, or super connector). Returns value/label pairs with counts so the LLM can present valid filter choices to the user.

Use when: Use before or alongside SearchWarmIntroRelationships when you need to show the user which filter values exist for a given account, contact, or super connector scope. Pass any already-active filters to narrow the returned option lists dynamically. Do not use this to retrieve relationship paths — use SearchWarmIntroRelationships for that.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns seniority[] with fields:

value label count Returns location[] with fields: value label count Returns category[] with fields: value label count Returns strength[] with fields: value label count Returns relationship_path_type[] with fields: value label count Returns department[] with fields: value label count Returns account_owner[] with fields: value label count Returns account_industry[] with fields: value label count Returns account_country[] with fields: value label count Returns account_employee_size[] with fields: value label count Returns account_icp[] with fields: value label count Returns account_office_country[] with fields: value label count Returns account_office_state[] with fields: value label count Returns account_office_city[] with fields: value label count

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Look up a platform user by email address. Returns the user's Keycloak ID and profile fields (name, LinkedIn ID). Use get_user_by_email to check if someone already exists or to resolve identity before updating a workspace member.

Use when: Use when you know the email and need to look up a user before adding or updating workspace membership. If email is unknown during an update, prefer search_workspace_members to find existing members (or search_users for platform-wide lookup), confirm identity with the user, then call create_workspace_member with the resolved email.

Behavior: read_only

Also returns pagination info (created_at, updated_at, created_by, updated_by, deleted_at, deleted_by).

Retrieve the stored person profile (research document) for a user in the workspace. Returns a structured object with researched_on, person_name, person_url and a role classification (value/source/confidence). IMPORTANT — rendering instructions: do NOT dump raw JSON, bullet lists of keys, or plain text paragraphs in chat. After fetching, render the document as a self-contained editable UI (React or HTML artifact) — the user must review and edit the role inline.

Use when: Use when the user wants to view or edit the researched role for a person in the workspace. After the tool returns, IMMEDIATELY render the editable artifact UI in the same turn — do not summarize the JSON in prose. If no document exists yet, trigger GenerateUserResearch first, then call get_user_profile again when ready.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Next steps (after this tool succeeds): [REQUIRED] [ACTION] → call update_user_profile: MANDATORY same turn: render the returned data as an editable person profile artifact UI with the role field and a Save button wired to update_user_profile. Do NOT echo JSON or field values as chat text.

Also returns pagination info (researched_on, person_name, person_url, role, next_15_days_focus, next_90_days_focus).

List all categories configured in the current workspace. Each category has id, label, name, description, and relationship_type. For the add-member Super Connector Category dropdown, filter to entries where relationship_type is SUPER_CONNECTORS and is_deleted is false — use id as the option value and label (or name) as the display text.

Use when: Call before rendering the add–Super Connector form (add_super_connector flow) — populates the required Category dropdown. Do NOT use with create_workspace_member for Super Connectors. Also use when the user asks what Super Connector categories exist in the workspace. REQUIRED before applying FILTER_FIELD_CATEGORY in search_warm_intro_relationships: filter response to relationship_type SUPER_CONNECTORS and is_deleted false, match the user's intent to a category label (e.g. 'Investor Employees', 'Advisor'), then pass that category's id UUID as the filter value.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns categories[] with fields: id: Category UUID — pass as category_ids when calling add_super_connector. name: Internal category name/slug. value label: Human-readable label for dropdown display. description: Short description of what this category represents. definition is_tracked parent_id type logo relationship_type: Category scope. Use entries with SUPER_CONNECTORS for the Super Connector add-member dropdown. order is_deleted: When true, exclude from dropdown options. meta created_at category_features

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Create an event on a user's Google Calendar via domain-wide delegation, optionally inviting attendees.

Use when: Use once you have confirmed the title and an explicit start and end time. Attendees receive invitations, so confirm the details with the user first.

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Delete an event from a user's Google Calendar.

Use when: Requires an event_id from a prior list or find call. Confirm the exact event with the user before deleting, since attendees are notified and the change is not reversible.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Return events on a user's Google Calendar via workspace domain-wide delegation, optionally bounded by time_min/time_max and filtered by a free-text query.

Use when: Use to read a calendar over a date range. TIMEZONE WARNING: timestamps ending in 'Z' are interpreted as UTC; prefer offsets in the calendar's own timezone for local dates.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Find events on a user's Google Calendar using a text query over title, description and attendees, with an optional time range.

Use when: Use to locate an event before updating or deleting it. Validate matches by summary, start.dateTime and organizer before trusting the event id.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Update an existing Google Calendar event. Only the fields you supply are changed.

Use when: Requires an event_id, so call GOOGLECALENDAR_FIND_EVENT or GOOGLECALENDAR_EVENTS_LIST first. Note that supplying attendees replaces the whole attendee list.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Get current_state for an intro request. TWO lookup modes — use exactly one, never mix fields across modes: (1) PREFERRED when intro_request_id is known: pass intro_request_id ONLY — omit target_id and requester_id. (2) Fallback when intro_request_id is unknown: pass target_id AND requester_id together — omit intro_request_id. INVALID (returns requester_id is required): intro_request_id + target_id without requester_id, or target_id alone. When intro_request_id is available, prefer search_intro_request with INTRO_REQUEST_SEARCH_FILTER_INTRO_REQUEST_ID instead.

Use when: Use only when you need current_state only (not full details) and intro_request_id is unavailable (use target_id + requester_id), OR when intro_request_id is known pass intro_request_id alone. Do NOT call with intro_request_id and target_id together. If intro_request_id is known and you need full details or state, prefer search_intro_request over this tool.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] Lookup parameters must match one valid mode — mixed partial keys cause INVALID_ARGUMENT. Verify: Mode A: intro_request_id only. Mode B: target_id + requester_id (both required). Invalid: intro_request_id + target_id without requester_id. Invalid: target_id without requester_id. When intro_request_id is known, use search_intro_request instead.

Return the complete intro request state machine transition graph. Each row is a directed edge: source_state → target_state, plus the event that triggers the move, which actor may fire it (ADMIN, REQUESTER, SYSTEM, REFERRER), action metadata, and event_label (human-readable). No input — returns the full graph in one call. To find valid next moves for a specific request: call intro_request_get_current_state first, then filter transitions where source_state equals that current_state and allowed_actor matches the caller's role.

Use when: Use to understand the intro request lifecycle — which states exist and which events move from one state to another (e.g. DRAFT → INTRO_REQUESTED via INTRO_REQUESTED_EVENT, DRAFT → DISCARD_DRAFT via DISCARD_DRAFT_EVENT). Call before intro_request_send_state_change_event whenever you are unsure what transitions are legal from the request's current state. Pair with intro_request_get_current_state: current_state tells you where the request is; this tool tells you where it can go next.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Next steps (after this tool succeeds): [optional] [SUGGESTION] → call intro_request_send_state_change_event: After filtering edges from the request's current_state, fire the chosen event via intro_request_send_state_change_event.

Returns transitions[] with fields: source_state: From-state — the intro request must be in this state for the transition to be valid. Match against current_state from intro_request_get_current_state. target_state: To-state — where the intro request lands after the event succeeds. event: Event enum to pass to intro_request_send_state_change_event to trigger this edge. action: Internal action identifier for this transition (informational). allowed_actor: Role allowed to fire this event. Only suggest transitions the current user's role can trigger. event_label: Human-readable label for this transition — use when presenting next-step options to the user.

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Fire a state machine event to move an intro request from its current state to a new state. Returns previous_state, current_state, and whether a transition occurred. Lookup: pass intro_request_id ONLY (preferred), OR target_id + requester_id together — never intro_request_id + target_id without requester_id. Only events valid for the request's current state will succeed — use intro_request_get_state_machine_transitions to see the full from→to graph.

Use when: Use when the user wants to advance, submit, cancel, withdraw, or discard an intro request. Workflow when the valid next step is unclear: (1) intro_request_get_current_state → (2) intro_request_get_state_machine_transitions → filter edges where source_state equals current_state and allowed_actor matches the caller → (3) pick the matching event → (4) call this tool. Do not guess events — invalid events are rejected.

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] Know the intro request's current state before firing an event. Verify: When intro_request_id is known, use search_intro_request with INTRO_REQUEST_SEARCH_FILTER_INTRO_REQUEST_ID + EQUALS. If using intro_request_get_current_state: pass intro_request_id ALONE — do not also pass target_id. Alternative lookup: target_id + requester_id together with no intro_request_id. Never pass intro_request_id + target_id without requester_id — the API returns INVALID_ARGUMENT. [REQUIRED] Confirm the event is a valid edge from the current state. Verify: Call intro_request_get_state_machine_transitions and find a transition where source_state == current_state, allowed_actor matches the user's role, and target_state matches the intended outcome. Use event_label to explain options to the user.

List all uploaded files with metadata.

List stored LinkedIn engagement for a tracked person in a date range. Requires exactly one of keycloak_user_id OR linkedin_handle, plus start_date and end_date (yyyy-MM-dd). Returns a slim summary per activity: comment text (if any), post author's LinkedIn handle, when it happened, and interaction type. Read-only — does not scrape LinkedIn.

Use when: Use when a trigger or user asks what LinkedIn posts someone commented on or reacted to in a date range. Prefer linkedin_handle when known. Reads stored history only.

Behavior: read_only, idempotent

Internal fields — available for follow-up tool calls but do NOT display to the user: total_count, page, page_size, keycloak_user_id

Returns activities[] with fields: comment_text: Comment text when the activity is a comment; empty for reactions/likes. post_author_linkedin_handle: LinkedIn vanity handle of the person whose post was engaged with. activity_at: When the comment or reaction occurred. interaction_type: Type of engagement, e.g. comment or reaction.

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

List Slack conversations the managed bot can access (public channels, private channels, DMs, MPIMs) with id, name and type.

Use when: Use to discover available channels. Prefer find_slack_channel when you already know the channel name or id.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

List the customer-defined tags available in this workspace for a given entity type, optionally narrowed to a name substring.

Use when: Use before attaching or filtering by tags, to discover which tags exist and their ids.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns tags[] with fields: id name entity_type

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

List admin-managed trigger templates for the workspace (master + tenant). Returns id, name, description, instructions, enabled, trigger_kind (SCHEDULED|WEBHOOK), and metadata (including supported_events for WEBHOOK). Use a template's id as createWorkflowTrigger.template_id — never invent ids or event slugs. WEBHOOK templates are included only when the caller is OWNER, ADMIN, or SUPER_CONNECTOR_ADMIN in the workspace; other callers receive SCHEDULED templates only.

Use when: Use when the user wants to browse or pick an admin template to create from, or when there is no workflow_trigger_template_context seed in the conversation. Call before createWorkflowTrigger so you can copy template_id, trigger_kind, and metadata.supported_events / metadata.preview verbatim. Prefer this over inventing WEBHOOK event slugs. If WEBHOOK templates are missing from the response, the caller lacks OWNER/ADMIN/SUPER_CONNECTOR_ADMIN — do not invent them. Not a substitute for listWorkflowTriggers (that lists live activations / catalog rows).

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns templates[] with fields: id workspace_id name description instructions enabled created_at updated_at created_by_user_id trigger_kind: SCHEDULED or WEBHOOK. Passed through to createWorkflowTrigger when this template is used. metadata: Same shape as catalog metadata. Example: {"preview":{"slack":{"text":"..."},"email":{"subject":"...","html_body":"..."}},"supported_events":[{"integration_name":"hubspot","subscribed_events":["HUBSPOT_CONTACT_CREATED_TRIGGER"]}]}. WEBHOOK templates require supported_events.

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

List a recipient's workflow triggers (catalog-based and agent-created), optionally filtered by lifecycle status. Returns id, catalog_id, name, description, prompt, schedule, and status.

Use when: Use before creating a new trigger to avoid duplicates, or when the user refers to 'that reminder'/'my reminders' — match on name/description here, then update_workflow_trigger with trigger_id set to the row's id (config UUID). Empty id means an unactivated catalog template — activate via create_workflow_trigger with that catalog_id, not update.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns triggers[] with fields: name description enabled last_run_at last_run_status status prompt source id allowed_channels selected_channels cron recurring adhoc config_status plan channel_metadata agent_thread_id editable metadata test_mode test_cron test_lead_minutes test_recipients scope created_by created_by_user_name owner_user_id owner_user_name activation_mode principal_type catalog_id audience_type is_template audience_filter trigger_kind

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Merge two workspace members who are the same person (e.g. a Super Connector added twice): everything the retired member has — relationships, connections, categories, tags, roles — moves onto the keeper, and the retired member is removed. Irreversible from chat. ALWAYS call first with dry_run=true: show the user the side-by-side comparison (both people's name, email, LinkedIn, roles and data counts) and every warning in plain language, and ask them to confirm which person to keep. Only after the user explicitly agrees, call again with the same keeper_user_id and retired_user_id, dry_run=false and confirm=true. Never merge on your own initiative, never skip the dry run, and never set confirm=true without the user's explicit agreement. If the outcome is MERGE_OUTCOME_REFUSED, explain refusal_reason plainly and do not retry. USER-FACING COPY: talk about people by name, never mention user ids, tool names or enum strings.

Use when: Use only when an admin asks to merge, combine or de-duplicate two members of this workspace. Get both user ids from search_workspace_members first (by name, email or LinkedIn). The keeper is the member to keep (usually the one with more data or a login); the retired member must not have a login.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] Both keeper_user_id and retired_user_id are known and belong to members of this workspace. Verify: Call search_workspace_members and take user_id from the two matching rows. Never guess ids. [REQUIRED] A dry run was shown to the user and they explicitly agreed to the merge. Verify: Only call with dry_run=false after a dry_run=true call in this conversation and an explicit 'yes' from the user.

Also returns pagination info (user_id, member_id, name, email, linkedin_id, role, data_counts, has_login).

Preview how many companies and people match a SearchPeopleRequest at each funnel stage (companies -> current employees -> +seniority -> +title keywords -> +person location), without running the final search. Same anchor/filter fields as search_people_by_location_and_seniority. Use this to show the user what each filter is doing before committing to the final query, especially after adding or loosening a filter.

Use when: Use whenever the user is refining a search interactively — after every new filter (region, seniority, title keywords, company set) — to show the funnel counts and let them see which parameter is truncating the result set. Do not use as a substitute for the final search_people_by_location_and_seniority call.

Behavior: read_only, idempotent

Returns stages[] with fields: label company_count people_count by_seniority top_locations top_titles basis sampled_rows

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Query agent content by slug, natural language query, family (SKILL, MEMORY), tags, or scope. Use for on-demand skill retrieval or finding memories.

Use when: Use when the agent needs to load a specific skill by slug or search for content not already injected in the runtime bundle.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns results[] with fields: content score match_reason

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Read an uploaded file's contents by name.

Read text content from a Slack file shared in a Rudy thread (CSV/TSV/TXT/JSON and similar). Content may come back truncated when inbound file limits are enabled.

Use when: Use with a file_id from message_context.inbound_files or thread_history[].files when the user attached a file you need to read.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Get the current state of a referrer request by target_id with optional requester_id or referrer_id (workspace member with SUPER_CONNECTOR role) filters. Returns ReferrerRequestState and whether a matching request was found.

Use when: Use before SendStateChangeEvent when you need to check current state and do not have referrer_request_id. Prefer GetReferrerRequestForReferrerById when you have the referrer_request_id.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Return the full state machine transition table for referrer requests. Each entry shows source state, target state, allowed actor, triggering event, and a human-readable label.

Use when: Call to understand all valid transitions before firing SendStateChangeEvent on a referrer request. No input parameters required.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns transitions[] with fields: source_state target_state event action allowed_actor event_label

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Transition a referrer request to a new state by firing a state machine event. A referrer request is the per-connector leg of a warm intro request for one workspace member with SUPER_CONNECTOR role — e.g. queuing an intro ask, or recording acceptance or rejection.

Use when: Use when you need to advance a referrer request. Call GetCurrentState first to confirm current state, then GetStateMachineTransitions if unsure which event is valid.

workspace_id / user_id are injected from request headers.

Remove tags from one or more entities. Only the listed tag/entity pairs are detached; tags not listed are kept. Tags are addressed by id (see ListTags).

Use when: Use to undo or clean up tag assignments, including bulk removal across many entities.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Returns entities[] with fields:

entity_id tags Returns created_tags[] with fields: id name entity_type

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Set a member's complete workspace role list (full replacement). Any roles not included in the request are revoked. Use this to remove specific roles: fetch current roles via search_workspace_members, omit the role(s) to remove, and pass the remaining roles. Pass an empty role list to strip all roles while keeping the member in the workspace.

Use when: Use when an admin wants to remove one or more roles from a member, or replace the member's entire role set. ALWAYS call search_workspace_members first to get the member's current roles, then pass the new complete list without the removed role(s). To add roles without removing existing ones, use add_role instead.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Create a new warm intro request in DRAFT state. DO NOT call until every required input is collected — if anything is missing, stop and ask the user to provide it (render a labeled form UI when helpful); never call with null, empty, or guessed UUIDs. REQUIRED: target_id (contact to introduce) and requester_id (who is asking — usually the current user). STRONGLY RECOMMENDED before calling: intro_request_meta.context (why the intro is needed — business reason, goal, talking points) and target_account_id when the contact belongs to a known account. OPTIONAL intro_request_meta: is_time_sensitive, recommended_sc (preferred super connectors / referrers with keycloak_user_id + order + note), opportunity_details, form_instance_id. Creating the draft does NOT submit the request — it only starts the workflow. AFTER SUCCESS (mandatory, same turn): immediately call get_draft_by_type three times (GHOSTWRITTEN_EMAIL, FORWARDABLE_EMAIL, TEXT) with intro_request_id from the response, render editable email/text UI, and present drafts to the user — do NOT ask 'Want me to pull those up?' or wait for confirmation; fetching drafts is automatic. USER-FACING: confirm creation in plain language (person names, connector name) — never read intro_request_id UUIDs, tool names, or enum state names aloud.

Use when: Use when a user wants to request a warm introduction to a target contact AND you already have target_id and requester_id. Before calling, confirm the target contact (search_contacts or relationship tools if needed), confirm requester_id (from X-User-ID context or explicit user choice), and collect intro_request_meta.context from the user ('Why do you want this intro?'). After success: save intro_request_id internally, tell the user the intro was created, then IMMEDIATELY fetch all three drafts and show the editable UI in the same response — never stop to ask whether to fetch drafts.

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] target_id (contact UUID) must be confirmed before calling. Verify: If the user named a person but did not provide a UUID, search contacts or use relationship_intelligence tools to find the target, present the best match (name, title, company), and get explicit confirmation ('Is this the person you want an intro to?') before using their contact UUID as target_id. [REQUIRED] requester_id (workspace user UUID) must be known before calling. Verify: Prefer the authenticated user from request context (X-User-ID). If acting on behalf of someone else, resolve via search_workspace_members and confirm with the user before calling. [REQUIRED] intro_request_meta.context should be collected from the user before calling. Verify: Ask: 'Why do you want this introduction?' or 'What's the goal / context for this intro?' Capture a clear business reason in intro_request_meta.context. Do not invent context — if the user has not provided it, ask before calling request_intro.

Next steps (after this tool succeeds): [REQUIRED] [ACTION] → call get_draft_by_type: IMMEDIATELY after request_intro returns — same turn, no permission prompt — call get_draft_by_type for GHOSTWRITTEN_EMAIL, FORWARDABLE_EMAIL, and TEXT using intro_request_id from the response, then render editable email/text UI. Do not ask 'Want me to pull those up?' [optional] [ACTION] → call update_draft: If the user edits any draft in the UI and clicks Save, call update_draft with is_manually_edited=true and the full edited content. [REQUIRED] [ACTION] → call intro_request_send_state_change_event: After the user has reviewed (and optionally saved edits to) all drafts, submit the intro request for admin review by firing INTRO_REQUESTED_EVENT.

Also returns pagination info (context, opportunity_details, is_time_sensitive, form_instance_id, recommended_sc, meeting_status, meeting_attribution, email_enrichment_job_id).

Resolve Boomerang notification metadata (intro_request_id, referrer_request_id, event_type, owner_email) from a Slack thread parent message identified by channel_id + thread_ts.

Use when: Use when the user replies in an intro/notification thread and you need the Boomerang record the thread is about.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Resolve a Slack user for a Boomerang workspace and return slack_user_id plus profile details. Checks workspace Slack mappings first, then users.info / users.lookupByEmail.

Use when: Use before sending an ephemeral message or when you only have an email and need the Slack user id. Prefer email over name.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Search and filter accounts using one or more field filters: account name (substring), LinkedIn URL, website, relationship strength, industry, country, employee size, ICP match status, CRM record ID (REFERENCE_ID_FILTER_FIELD), and external ID (EXTERNAL_ID_FILTER_FIELD). Returns full account details including domain, location, reference_id, crm_url, type, segment, and icp (Ideal Customer Profile match status). IMPORTANT — rendering: do NOT dump raw JSON or prose lists in chat. Render results in a tabular UI artifact (React/HTML table) with one row per account and columns for name, domain, website, linkedin_url, city, state, country, reference_id, crm_url (as link), type, segment, icp. Include pagination controls when page_info indicates more pages.

Use when: Use when you need to find accounts by name, CRM ID, or other attributes via filters. Use REFERENCE_ID_FILTER_FIELD when the user provides a Salesforce or HubSpot account ID (exact match on reference_id — same value returned as reference_id in results). Use EXTERNAL_ID_FILTER_FIELD for other external system IDs. Use NAME_FILTER_FIELD for name substring search. Prefer this over SearchAccounts when filters are needed. Use GetAccountsByIds only when you already have internal account UUIDs. Scoped to accounts tracked in this workspace's CRM — if the company has no account record, use search_people_in_companies instead; it needs no account to exist.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns accounts[] with fields:

id: Unique internal UUID of the account. Use this as the identifier when referencing this account in other API calls. name: Account (company) name as stored in the platform. domain: Primary email domain of the account (e.g. 'acme.com'). Derived from the company website. linkedin_url: LinkedIn company page URL for this account (e.g. 'https://www.linkedin.com/company/acme'). Empty if not available. website: Company website URL (e.g. 'https://www.acme.com'). Empty if not available. state: State or province where the account's primary office is located. Empty if not available. city: City where the account's primary office is located. Empty if not available. country: Country where the account's primary office is located. Empty if not available. zipcode: Postal / ZIP code of the account's primary office address. Empty if not available. reference_id: CRM record ID from the connected system (e.g. Salesforce 18-char Account ID, HubSpot company ID). Queryable via REFERENCE_ID_FILTER_FIELD. Same value shown in crm_url. crm_url: Direct URL to this account's record in an external system. Empty if not available. type: Account type (e.g. 'Prospect', 'Customer', 'Partner'). Empty if not set. segment: Market segment or tier assigned to this account (e.g. 'Enterprise', 'Mid-Market', 'SMB'). Empty if not set. icp: ICP (Ideal Customer Profile) match status for this account — how well the account fits the workspace's target customer criteria. Values: 'MATCH' (Matches ICP — meets ICP criteria; prioritize for outreach), 'PRE_MATCH' (From your list — imported by CSV upload or contact/account report and taken as ICP without evaluation), 'NO_MATCH' (Outside ICP — does not meet ICP criteria), 'NO_DATA' (Not enough data — insufficient company data to evaluate against ICP; typically missing LinkedIn ID or unresolvable company), 'NO_ICP_DEFINED' (Not evaluated — workspace has not configured ICP criteria yet). Empty if not yet evaluated. Use this column to help users quickly identify best-fit accounts. category: The account's category from the platform's strict vocabulary: Customer, Prospect, Open Opportunity, Closed Lost, Churned, Partner, Investor Portfolio, Competitor, Other. Exactly one per account, set by a user, an account-list upload, or public research. Distinct from 'type', which is free text synced from the CRM. Unspecified when the account has not been categorised. tags: Customer-defined free-form tags on this account (e.g. 'Enterprise', 'EMEA'). Independent of the account's category. Returns filter_values[] with fields: key value label count Also returns pagination info (current_page_number, page_size, total_pages, total_elements).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Search and filter target prospect contacts using field filters: name, email, title, LinkedIn URL, company, account ID, seniority, department, persona grade, CRM record ID (REFERENCE_ID_FILTER_FIELD), external ID (EXTERNAL_ID_FILTER_FIELD), and title persona (TITLE_PERSONA_FILTER_FIELD). Returns full contact details including reference_id, profile picture, active title, and persona grade. IMPORTANT — rendering: do NOT dump raw JSON or prose lists in chat. Render results in a tabular UI artifact (React/HTML table) with one row per contact and columns for first_name, last_name, email, title, active_title, account_name, linkedin_url, persona_grade, reference_id (CRM ID). Include pagination when page_info has more pages.

Use when: Use when you need to find contacts by name, CRM ID, or other attributes. Use REFERENCE_ID_FILTER_FIELD when the user provides a Salesforce or HubSpot contact ID (exact match on reference_id). Use EXTERNAL_ID_FILTER_FIELD for other external system IDs. Use NAME_FILTER_FIELD for name search. Use ACCOUNT_ID_FILTER_FIELD for all contacts at an account (internal UUID). Use LINKEDIN_URL_FILTER_FIELD for LinkedIn profile lookup. Use TITLE_PERSONA_FILTER_FIELD with values BUYING_COMMITTEE, EXTENDED_BUYING_COMMITTEE, or LEADERSHIP to find contacts whose title matches the workspace's configured buyer personas. Scoped to tracked contacts only — if no match, fall back to search_people_in_companies before reporting no results.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns contacts[] with fields:

id: Unique internal UUID of the contact. Use when referencing this contact in warm intro or intro request flows. first_name: Contact's first name. last_name: Contact's last name. email: [redacted] title: Contact's job title as stored in the platform. active_title: Most recently resolved job title for this contact, enriched by the Boomerang engine. account_name: Name of the company this contact works at. internal_account_id: Internal UUID of the account (company) this contact belongs to. linkedin_url: LinkedIn profile URL of the contact. profile_pic: URL of the contact's profile picture. Empty if not available. persona_grade: ICP fit grade assigned by the Boomerang engine: A (strongest fit), B, C, D (weakest fit). Empty if not yet graded. reference_id: CRM record ID from the connected system (e.g. Salesforce Contact/Lead ID, HubSpot contact ID). Queryable via REFERENCE_ID_FILTER_FIELD — exact match. Returns filter_facets[] with fields: key: The ContactFilterField enum name this facet belongs to (e.g. 'SENIORITY_FILTER_FIELD'). value: The filter value to send back in a ContactFilterInput to apply this facet (e.g. 'VP'). label: Human-readable display label for the facet value (e.g. 'Vice President'). count: Number of contacts in the current result set that match this facet value. Also returns pagination info (current_page_number, page_size, total_pages, total_elements).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Search and filter intro requests in the workspace. Input shape: workspace_id (auto-injected), filter_groups (optional), sort (optional), page (0-based, default 0), page_size (default 20, max 100). Each filter group has logic (AND/OR) and criteria [{field, operator, values}]. field and operator are enums — always pass exact enum strings. Returns intro_requests (current_state, meta, target_id, requester_id, timestamps) and page_info. Replaces get_intro_request — use INTRO_REQUEST_SEARCH_FILTER_INTRO_REQUEST_ID + EQUALS for single-ID lookup. USER-FACING: summarize results with person/account names — never read UUIDs or tool names aloud.

Use when: Use for ANY intro request lookup or list. Decision guide — (1) By intro_request_id: INTRO_REQUEST_SEARCH_FILTER_INTRO_REQUEST_ID + EQUALS. (2) Person at account: INTRO_REQUEST_SEARCH_FILTER_TARGET_ACCOUNT_ID + EQUALS AND INTRO_REQUEST_SEARCH_FILTER_TARGET_CONTACT_NAME + CONTAINS (single token e.g. ['sherif']) OR TARGET_CONTACT_ID + EQUALS when contact UUID known from search_contacts. (3) All intros for account: TARGET_ACCOUNT_ID only. (4) All intros to a contact: TARGET_CONTACT_ID + EQUALS. (5) By lifecycle state: INTRO_REQUEST_SEARCH_FILTER_STATE + IN e.g. ['DRAFT','IN_PROGRESS']. (6) By requester: REQUESTER_ID + EQUALS. (7) By super connector: REFERRER_ID + EQUALS or IN. (8) Time-sensitive only: IS_TIME_SENSITIVE + EQUALS ['true']. (9) Created after date: CREATED_AT + GTE ['2024-01-01']. Omit filter_groups to list all (paginated). Multiple filter_groups are AND-combined. Prefer TARGET_CONTACT_ID over name when UUID is known.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns intro_requests[] with fields:

target_id: UUID of the target contact this intro request is for. requester_id: UUID of the workspace user who requested the introduction. intro_request_id: UUID of this intro request — store internally for search_intro_request, intro_request_send_state_change_event, and get_draft_by_type. Do not read aloud to the user. current_state: Current state of the intro request in the state machine. created_at: ISO 8601 timestamp when the intro request was created. meta: Metadata: context, time-sensitivity, opportunity details, recommended super connectors, meeting status. Also returns pagination info (current_page_number, page_size, total_pages, total_elements, has_next, has_previous).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Find a specific person by exact first+last name, or find people at a company (by name or by LinkedIn company id) — optionally refined by geographic location and seniority band. Returns name, current title, current company, location, and LinkedIn URL. Global directory search — NOT scoped to the caller's workspace/contacts. Requires first_name+last_name, company_name, OR company_social_id; region/seniority alone are not enough. company_name is resolved server-side to a LinkedIn id — an ambiguous or unmatched name is rejected asking you to resolve it yourself (e.g. via web search) and retry with company_social_id. Results are capped and ranked by follower count; use page for more.

Use when: Use when the user wants to find a specific known person by name (e.g. 'find Satya Nadella'), or people at a named company, optionally narrowed by where they live (US state or metro) and how senior they are (C-suite, VP, director-and-above). For a fixed SET of companies known by social id/slug rather than a name, prefer SearchPeopleInCompanies instead.

Behavior: read_only, idempotent

Returns people[] with fields: full_name current_title current_company location country_code linkedin_url social_followers person_social_id: Stable person social id (profile-data graph identifier). Not for display — carry through to any export/CSV for de-duplication and re-lookup.

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Deprecated — prefer search_people_by_location_and_seniority with company_social_ids set. Find senior people at a specific SET of companies (anchored by company social ids / slugs), optionally filtered by location and by title keywords. COMPANY-anchored: the input is a fixed list of companies to look inside. Returns name, title, company, seniority, and location for up to per_company_limit people per company.

Use when: Deprecated. Use for people at named companies, e.g. 'VPs at Acme and Globex' — or as the fallback when search_contacts finds no match for a named person/company. Also use for company-wide sweeps (e.g. ICP match) across ALL employees, not just tracked contacts — pass the workspace's ICP title_keywords for that. Narrow further with title_keywords. Prefer SearchPeopleByLocationAndSeniority for location/seniority-only queries not anchored to specific companies.

Behavior: read_only, idempotent

DEPRECATED.

Returns people[] with fields: person_social_id first_name last_name title company_social_id company_name seniority country_code location social_followers_count

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Search Slack messages across the workspace using Slack search syntax.

Use when: Often unavailable with bot-only tokens (not_allowed_token_type / missing search:read). Fall back to fetch_slack_thread or fetch_channel_history when this fails.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Search platform users workspace-wide by free-text string matched against names and emails. Returns keycloak_user_id and profile fields. This is platform-wide — it includes users who may not yet be workspace members. To find or list members of the current workspace (with roles), prefer search_workspace_members instead.

Use when: Use for platform-wide user lookup when search_workspace_members does not find the person — e.g. checking if someone exists on the platform before adding them. For finding an existing workspace member to update, prefer search_workspace_members (supports name CONTAINS/EQUALS and role filters). If email is known, use get_user_by_email. Always confirm identity with the user before calling create_workspace_member.

Behavior: read_only

Returns users[] with fields:

keycloak_user_id: Keycloak user ID (UUID) — the primary identity provider ID. Use this when referencing the user in other API calls. linkedin_id: LinkedIn profile ID or URL for the user. Empty if not set. first_name: User's first name. last_name: User's last name. email: [redacted] phone: User's phone number. Empty if not set. is_deleted: True if this user account has been soft-deleted from the platform. user_profile: User platform profile settings including Super Connector opt-in status and WhatsApp consent. audit_info: Audit timestamps: created_at, updated_at, and optional deleted_at (all Unix milliseconds). Also returns pagination info (current_page_number, page_size, total_pages, total_elements).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Search warm intro relationship paths across the workspace using rich filters on accounts, contacts, super connectors, and relationship quality. Returns fully resolved results with contact, super connector, account, relationship evidence, and intro request context per path. IMPORTANT — rendering: do NOT dump raw JSON or long prose in chat. Render results in a tabular UI artifact (React/HTML table) — one row per relationship path. Include as many columns as the data provides: Contact (full_name, title, seniority, company_name, email), Super Connector (full_name, title, email), Account (account_name, domain, industry, owner_full_name, employee_size), Relationship (strength, category, confidence, intro_value, score, summary, relationship_path_types, number_of_meetings, last_contacted_at), Intro Request (current_state, requester_full_name, is_recommended_connector, connector_request_status when has_intro_request). Hide internal UUIDs unless the user asks. Include pagination when page_info indicates more pages.

Use when: Use for workspace-wide warm intro discovery when you need to combine multiple filters — e.g. VP contacts at accounts owned by a rep, CONFIRMED paths via a specific connector, or contacts at a specific domain. After results return, render the table UI in the same turn — do not summarize paths as paragraphs. CATEGORY TRIGGER WORDS — if the user's request contains any of: investor(s), customer(s), board member(s), advisor(s), champion(s), alumni, leadership, partner(s) — treat this as a FILTER_FIELD_CATEGORY request, NOT a seniority or strength filter. These words describe who the connector is in relation to the company, not how senior the contact is or how strong the tie is. NEVER substitute FILTER_FIELD_SENIORITY or FILTER_FIELD_STRENGTH as a proxy for a category-based request. Required flow for any category-based request: (1) call get_workspace_categories FIRST, (2) filter response to relationship_type SUPER_CONNECTORS and is_deleted false, (3) match the user's term to the closest category label(s) — include all plausible matches as OR'd values (e.g. both 'Investor' and 'Investors' if both exist), (4) pass those category id UUIDs as FILTER_FIELD_CATEGORY values. Never pass label strings directly as FILTER_FIELD_CATEGORY values. Mixed requests (e.g. 'senior leaders who investors know'): apply FILTER_FIELD_CATEGORY AND FILTER_FIELD_SENIORITY together in the same call. When filtering by super connector, prefer FILTER_FIELD_CONNECTOR_ID (exact UUID match) over FILTER_FIELD_SUPER_CONNECTOR_NAME whenever the connector user_id is known — name prefix matching requires a single first or last name token and silently returns zero results for full names like "Steven Hagler". When the user supplies Salesforce/HubSpot account IDs, pass them straight to FILTER_FIELD_ACCOUNT_REFERENCE_ID — do not call search_accounts_with_filters to map them to UUIDs first.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns results[] with fields:

source: Originating party of the path. source.user is set for User→Contact and User→Account paths; source.company is set for Account→Account paths; source.contact is set for Contact→Account (COMPANY_ALUMNI) paths. target: Intended intro recipient. target.contact is set for User→Contact paths; target.account is set for User→Account and Account→Account paths; both are set for COMPANY_ALUMNI paths. relationship: Relationship quality and evidence — strength, category, confidence, intro_value, score, summary, number_of_meetings, last_contacted_at, is_approved, connected_on_date. relationship_path_types is a list of {type, description} objects — use type values to determine which source/target sub-fields are populated. intro_request: Intro request context — show when has_intro_request is true: current_state, requester_full_name, created_at, is_time_sensitive, is_recommended_connector, connector_request_status. Show '—' when absent. Also returns pagination info (total_pages, current_page_number, page_size, total_count).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Search and filter members in a workspace. Input shape: workspace_id (required root param, auto-injected), filter_groups (optional), sort (optional), page (0-based, default 0), page_size (default 20, max 100). When filter_groups is omitted, returns all members. field and operator are enums — always pass exact enum strings. Primary filters: WORKSPACE_MEMBER_FILTER_FIELD_NAME→CONTAINS or EQUALS; WORKSPACE_MEMBER_FILTER_FIELD_ROLE→IN; WORKSPACE_MEMBER_FILTER_FIELD_EMAIL→CONTAINS or EQUALS. Also supports USER_ID, LINKEDIN_ID, CREATED_AT, Super Connector consent fields, CATEGORY→IN, and TITLE→REGEX (current job title(s), regex match). Sortable: CREATED_AT, NAME, EMAIL, ROLE. Response includes a categories array (id, label, value) per member.

Use when: Use for ANY workspace member lookup. Decision guide — (1) List all members: omit filter_groups (workspace_id only). (2) Find by name substring: WORKSPACE_MEMBER_FILTER_FIELD_NAME + WORKSPACE_MEMBER_FILTER_OPERATOR_CONTAINS e.g. ['smith']. (3) Find by exact name: WORKSPACE_MEMBER_FILTER_FIELD_NAME + WORKSPACE_MEMBER_FILTER_OPERATOR_EQUALS e.g. ['John Smith']. (4) Find by role: WORKSPACE_MEMBER_FILTER_FIELD_ROLE + WORKSPACE_MEMBER_FILTER_OPERATOR_IN e.g. ['SUPER_CONNECTOR'] or ['ADMIN']. (5) Find by email substring/domain: WORKSPACE_MEMBER_FILTER_FIELD_EMAIL + WORKSPACE_MEMBER_FILTER_OPERATOR_CONTAINS e.g. ['@acme.com']. (6) Find by exact email: WORKSPACE_MEMBER_FILTER_FIELD_EMAIL + WORKSPACE_MEMBER_FILTER_OPERATOR_EQUALS e.g. ['jane@acme.com']. (7) Find by category: WORKSPACE_MEMBER_FILTER_FIELD_CATEGORY + WORKSPACE_MEMBER_FILTER_OPERATOR_IN — pass one or more WorkspaceMemberCategoryName display values e.g. ['Leadership'] or ['Board','Investors']. Valid values: 'Leadership', 'Board', 'Advisors', 'Customers', 'Employees', 'Alumni', 'Investors', 'Others', 'Power User', 'Partners'. Matching is exact and case-sensitive on these display strings — a value outside this list matches nothing and returns an empty result rather than an error, so never invent or pluralise one ('Power User' is singular). (8) Find by one or more user IDs: WORKSPACE_MEMBER_FILTER_FIELD_USER_ID + WORKSPACE_MEMBER_FILTER_OPERATOR_EQUALS only — this field does NOT support IN; for multiple IDs use a WORKSPACE_MEMBER_FILTER_LOGIC_OR group with one EQUALS criterion per ID. (9) Find by current job title: WORKSPACE_MEMBER_FILTER_FIELD_TITLE + WORKSPACE_MEMBER_FILTER_OPERATOR_REGEX e.g. ['(?i)^VP.*Sales'] — case-insensitive Postgres regex against the member's current title(s); only current employment is searched, not past roles. workspace_id is always required at root and auto-injected — never ask the user.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns members[] with fields:

user_id: Unique internal UUID of the user. Use this as the identifier when referencing this member in other API calls. workspace_id: Id of the workspace this membership belongs to. role: List of roles assigned to this member in the workspace. Each entry has a machine name (e.g. 'ADMIN') and a human-readable label (e.g. 'Admin'). A member can hold multiple roles simultaneously. user_first_name: Member's first name. user_last_name: Member's last name. user_email: [redacted] created_at: Timestamp when this member was added to the workspace. is_management_user: True if this user holds a platform-level management role (assigned outside of workspace roles, via ManagementUserService). Management users typically have elevated cross-workspace privileges. linkedin_id: Member's LinkedIn profile ID or URL. Used to identify the member's LinkedIn presence for Super Connector network analysis and warm intro path finding. whatsapp_consent: Whether the member has consented to receiving WhatsApp communications. connection_ledger_id: ID of the member's uploaded LinkedIn connection file (connection ledger). Non-empty means the member has uploaded their LinkedIn connections export, which enables Super Connector network analysis. Empty means no connection file has been uploaded yet. network_description: Free-text description of the member's professional network, provided by the member or admin. Gives context on the member's relationship capital and areas of influence. Null if not set. super_connector_opt_in: Whether the member has opted into the Super Connector program, which allows the platform to leverage their LinkedIn network for warm introductions. connection_consent: Member's consent to share their LinkedIn network connections with the workspace for intro facilitation. Distinct from super_connector_opt_in — this specifically governs the sharing of raw connection data. sc_onboarding_status: Current stage of the member's Super Connector onboarding flow. categories: Category tags assigned to this member (e.g. Finance, Technology). Each entry has an id, a human-readable label, and a value. Used to group or segment members within the workspace. notes: Optional admin notes about this Super Connector member. Free-text field set via UpdateSuperConnectorNotes. Null if no notes have been added. Also returns pagination info (current_page, page_size, total_elements, total_pages, has_next, has_previous).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Search and filter workspaces for a user. Input shape: member_user_id (required root param, auto-injected), filter_groups (optional), sort (optional), page (0-based, default 0), page_size (default 20, max 100). When filter_groups is omitted, returns all workspaces the user belongs to. field and operator are enums — always pass exact enum strings. Valid field→operator pairs: WORKSPACE_FILTER_FIELD_NAME→CONTAINS, EQUALS, or REGEX; WORKSPACE_FILTER_FIELD_WORKSPACE_ID→EQUALS or IN; WORKSPACE_FILTER_FIELD_DOMAIN→CONTAINS, EQUALS, or REGEX; WORKSPACE_FILTER_FIELD_WORKSPACE_TYPE→IN; WORKSPACE_FILTER_FIELD_CREATED_AT→GTE or LTE (ISO-8601); WORKSPACE_FILTER_FIELD_DESCRIPTION→CONTAINS. Returns workspace id, name, description, type, contact stats, config, logo, member count, and the user's roles.

Use when: Use for ANY workspace lookup for the current user. Decision guide — (1) List all workspaces: omit filter_groups (member_user_id only). (2) Find by name substring: WORKSPACE_FILTER_FIELD_NAME + WORKSPACE_FILTER_OPERATOR_CONTAINS e.g. ['acme']. (3) Find by name regex: WORKSPACE_FILTER_FIELD_NAME + WORKSPACE_FILTER_OPERATOR_REGEX e.g. ['^Acme.*']. (4) Lookup by workspace UUID: WORKSPACE_FILTER_FIELD_WORKSPACE_ID + WORKSPACE_FILTER_OPERATOR_EQUALS e.g. ['<uuid>']. (5) Bulk lookup by IDs: WORKSPACE_FILTER_FIELD_WORKSPACE_ID + WORKSPACE_FILTER_OPERATOR_IN e.g. ['uuid1','uuid2']. (6) Find by domain: WORKSPACE_FILTER_FIELD_DOMAIN + WORKSPACE_FILTER_OPERATOR_EQUALS e.g. ['acme.com'] or CONTAINS/REGEX for partial/pattern. (7) Filter by type: WORKSPACE_FILTER_FIELD_WORKSPACE_TYPE + WORKSPACE_FILTER_OPERATOR_IN e.g. ['CUSTOMER']. (8) Filter by creation date: WORKSPACE_FILTER_FIELD_CREATED_AT + GTE/LTE with ISO-8601 e.g. ['2024-01-01T00:00:00Z']. member_user_id is always required and scopes to that user's memberships.

Behavior: read_only

workspace_id / user_id are injected from request headers.

Returns workspaces[] with fields:

id: Unique UUID of the workspace. Use this as the workspace_id when calling other workspace-scoped APIs. name: Display name of the workspace. description: Free-text description of the workspace's purpose or customer context. May be empty. workspace_type: Tier or classification of the workspace. meta: Contact counts for the workspace: total, processable, unique, and discovered contacts. workspace_config: Workspace-level configuration values (category 'workspace'). Structured as a JSON object. May be empty if no custom configuration has been set. created_at: Timestamp when the workspace was first created. updated_at: Timestamp of the most recent update to the workspace record. is_disabled: True if the workspace has been disabled (soft-deleted or suspended). Disabled workspaces are not fully active; their data is retained but the workspace is not operational. logo_url: Public URL of the workspace's logo image. Empty string if no logo has been uploaded. active_member_count: Number of active (non-removed) members currently in the workspace. requesting_member_roles: Roles held by the requesting user in this workspace. A user can hold multiple roles simultaneously e.g. ['OWNER', 'SUPER_CONNECTOR_ADMIN']. Always non-empty since only workspaces where the user is an active member are returned. workspace_scope: Whether the workspace belongs to a company or to one person. package_type: The shape of the workspace's current plan. Unspecified when it has no subscription. Also returns pagination info (current_page, page_size, total_elements, total_pages, has_next, has_previous).

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Send an HTML email to recipients via SES. Always CCs a random boomerang+*@mail.getboomerang.ai tracking alias and records email_conversations with the SES message id.

Use when: Use when Rudy or an internal agent must deliver an email brief or notification to a user.

workspace_id / user_id are injected from request headers.

Send a Slack message via the managed bot token. Supply to_email for a DM and/or channel_id for a channel post, thread_ts to reply in-thread, or ephemeral=true for a message only one user sees.

Use when: Default Slack send tool. Email recipients are gated: they must be a workspace member, on an allowed workspace email domain, or have a Slack mapping.

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Send a Slack Block Kit message to a user by email via the Boomerang-managed bot. Pass channel_id + thread_ts to reply in-thread instead of DMing.

Use when: Use when you must reach a specific person by email. Prefer send_slack_message when you already have a channel_id or need ephemeral delivery.

workspace_id / user_id are injected from request headers.

Stage one CSV export for a Rudy Slack reply and return its file_ref plus download path/url.

Use when: Use when the answer is better delivered as a file. Include every returned file_ref in the callback slack_file_refs array. Use stage_slack_csv_exports for more than one file.

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Stage multiple CSV exports for one Rudy Slack reply and return the file_refs array.

Use when: Use when a single reply needs several attachments. Pass exports as a list of {filename, csv_content}, or exports_json with the same shape as a JSON string.

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Provision one or more Super Connectors and immediately run the requested automation actions against them, bypassing the normal onboarding-complete gate. Returns a run_id; progress arrives as SC_ACTIVATION_RUN realtime events.

Use when: Use when you need to fast-path activate Super Connectors and trigger automations (e.g. CREATE_LEADERSHIP_BRIDGE_PATHS) without waiting for full onboarding. Prefer add_super_connector for standard onboarding flows.

workspace_id / user_id are injected from request headers.

Start an async professional-email extraction job for one or more contacts. Returns job_id. Prefer linkedin_url when available; otherwise provide first_name + last_name + company_name or company_domain. Optionally pass boomerang_identity_id when the Boomerang contact id is known. After calling, poll getEmailExtractionJobStatus until the job is terminal — results (including emails) are returned on that same status response.

Use when: Use when you need to find a contact's work email and do not already have it. For a single person, pass one contact. Do not invent emails — wait for the job to complete.

workspace_id / user_id are injected from request headers.

Next steps (after this tool succeeds): [REQUIRED] [ACTION] → call getEmailExtractionJobStatus: Poll getEmailExtractionJobStatus with the returned job_id until status is COMPLETED, PARTIALLY_COMPLETED, or FAILED, then read results[].email.

Switch the active Boomerang workspace for the current MCP session.

Call this when the user asks to work in a different workspace. The new workspace will be used for all subsequent tool calls.

Save user edits to the company profile document. Merges only the sections you provide — pass just the fields being changed in data, and optionally an explicit sections list. When sections is empty, only populated data fields are merged. Pass sections=["ALL"] to replace the entire document.

Use when: Use when the user saves edits from the get_company_profile artifact UI. Pass only changed sections in data (e.g. value_proposition and pain_points), not the full document. Confirm success in plain language; optionally re-render the UI with saved values.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Next steps (after this tool succeeds): [optional] [SUGGESTION] → call get_company_profile: Confirm save to the user in plain language. Optionally re-render the company profile artifact with the returned data.

Also returns pagination info (researched_on, company_name, company_url, one_line_summary, value_proposition, pain_points, proof_points, competitors, customer_industry_category, departments, seniority, title_keywords, company_size, named_customers, named_investors, title_regex, buying_committee, buying_committee_regex, customer_industry, extended_buying_committee, extended_buying_committee_regex).

Save user edits to the latest draft of a specific type (GHOSTWRITTEN_EMAIL, FORWARDABLE_EMAIL, or TEXT) for an intro request. Call this when the user clicks Save in the editable email or text UI rendered from get_draft_by_type. Pass the full edited email_content or text_content (all fields, not just changed ones) and set is_manually_edited=true.

Use when: Use when the user edits a draft in the editable UI from get_draft_by_type and clicks Save — e.g. changes subject, body, To/CC, or the text message. Always set is_manually_edited=true. After saving: update the artifact in place with the saved content (do not re-fetch via get_draft_by_type unless the response content differs from what was submitted) and confirm success in plain language — e.g. 'Your edits to the Ghostwritten Email have been saved.' Do not explain tool names or internal state.

workspace_id / user_id are injected from request headers.

Next steps (after this tool succeeds): [optional] [SUGGESTION] → call intro_request_send_state_change_event: After editing, call intro_request_send_state_change_event with INTRO_REQUESTED_EVENT to submit the intro request for admin review.

Also returns pagination info (request_context).

Replace the text and/or blocks of a Slack message previously posted by the managed bot (chat.update).

Use when: Use to edit a bot message in place instead of posting a follow-up reply. Requires channel_id and the original message_ts.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Also returns pagination info (fields).

Save user edits to the person profile document. Merges only the sections you provide — pass just the fields being changed in data (e.g. role, next_15_days_focus, next_90_days_focus), and optionally an explicit sections list. When sections is empty, only populated data fields are merged. Pass sections=["ALL"] to replace the entire document.

Use when: Use when the user saves edits from the get_user_profile artifact UI. Pass only changed sections in data (e.g. role), not the full document. Confirm success in plain language; optionally re-render the UI with saved values.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Next steps (after this tool succeeds): [optional] [SUGGESTION] → call get_user_profile: Confirm save to the user in plain language. Optionally re-render the person profile artifact with the returned data.

Also returns pagination info (researched_on, person_name, person_url, role, next_15_days_focus, next_90_days_focus).

Update an existing workflow trigger activation: edit name/description/prompt/plan/schedule/channels, or change lifecycle status (ACTIVE/PAUSED/CANCELLED). trigger_id is required and must be the activation config UUID from list_workflow_triggers.id or create_workflow_trigger.trigger_id — never catalog_id. Only set fields that changed. SCHEDULED: any new cron / one_time_fire_at must be absolute UTC. WEBHOOK triggers have no cron — do not add cron when list shows trigger_kind=WEBHOOK; change prompt/channels/status only (supported_events are fixed on the catalog from create/template). Prefer list_workflow_triggers first to load id (as trigger_id) and trigger_kind.

Use when: Use to edit an existing live activation, or pause/resume/cancel it. trigger_id = list_workflow_triggers.id (the config UUID). Do NOT pass catalog_id as trigger_id. First-time opt-in of a WORKSPACE_OPT_IN template uses create_workflow_trigger with catalog_id instead. Call list_workflow_triggers first if you don't have the config id. For WEBHOOK rows, never invent a schedule.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Also returns pagination info (name, description, enabled, last_run_at, last_run_status, status, prompt, source, id, allowed_channels, selected_channels, cron, recurring, adhoc, config_status, plan, channel_metadata, agent_thread_id, editable, metadata, test_mode, test_cron, test_lead_minutes, test_recipients, scope, created_by, created_by_user_name, owner_user_id, owner_user_name, activation_mode, principal_type, catalog_id, audience_type, is_template, audience_filter, trigger_kind).

Update an existing workspace member's profile settings. member_profile ONLY accepts super_connector_settings (onboarding status, connection consent, opportunity stage, contact seniority, minimum deal size) — email, first_name, and last_name are rejected because identity belongs on the User entity. Does not change workspace roles — use add_role or remove_role for role changes.

Use when: Use when an admin needs to update Super Connector profile settings for an existing workspace member. The member record must already exist. For role changes use add_role or remove_role.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Also returns pagination info (created_at, updated_at, created_by, updated_by, deleted_at, deleted_by).

Atomically create or replace the single MEMORY document for a USER or WORKSPACE scope. Pass full structured markdown_body plus a compact description projection.

Use when: Use after merging an observation into the scoped memory document. Never create additional MEMORY rows.

workspace_id / user_id are injected from request headers.

Also returns pagination info (id, content_id, version_number, markdown_body, json_payload, change_summary, token_budget_hint, draft_of_version_id, rollback_to_version_id, published_at, published_by, created_at, created_by).