Outreach

Fetch the complete filter schema for a specific entity type, including: 1. Available additional custom fields that can be used as filter attributes and output fields 2. Available additional output fields. 3. The allowed standard filter attributes and their operators, grouped by data type (string, number, date, id). Use this tool to discover: - What custom and standard fields exist for filtering and output selection. - What operators are valid for each standard filter attribute. - What validation types and allowed values apply to custom fields. ONLY Supported entity types: - prospect - account - opportunity - task - sequence_state - schedule - ruleset - call - template - custom_object Response contains three sections: - `fields`: Lists standard fields can be retrieved. - `custom_fields`: Lists custom_fields with id, label, validation_type, validation_definition. - `filters`: Groups standard filter attributes by data type with allowed operators and optional instruction for each group. HOW TO USE FILTERS Each filter object has three fields: - "attribute": field id from this response (e.g. "custom8", "engagedAt"). - "operator": comparison operator (must be valid for the attribute's data type). - "value": list of string values. Value rules: - For "is" operator: multiple values use OR logic (e.g. ["High", "Medium"]). - For "between" operator: exactly two values — [min, max] (e.g. ["1", "100"] or ["2025-01-01", "2025-06-30"]). - For all other value-taking operators: a single value in the list (e.g. ["1000000"]). - For no-value operators (isEmpty, isNotEmpty, and all relative-date operators like today, last7Days, etc.): provide an empty list []. Operator rules: - For "string": use "is" for exact matches, "contains" for partial matches, and "startswith" to match the beginning of a string. Determining allowed operators: - For STANDARD filter attributes: use the operators listed in the `filters` response for the attribute's type group. - For CUSTOM fields: use the validation_type from the `fields` response to determine allowed operators: - "string": is, isNot, startsWith, contains, notContains, isEmpty, isNotEmpty - "numerical" or "currency": is, isNot, between, gte, lte, isEmpty, isNotEmpty - "date" or "date_time": is, between, gte, lte, isEmpty, isNotEmpty, plus relative-date operators (today, last7Days, last30Days, etc.) - "boolean": is, isNot, isEmpty, isNotEmpty - "inclusion" or "multi_inclusion": is, isNot, isEmpty, isNotEmpty (values MUST exactly match entries from validation_definition, case-sensitive) If a filter group includes an "instruction" field, follow it for additional guidance on how to construct filter values for that type. HOW TO USE ADDITIONAL FIELDS Use field IDs from the `fields` or `custom_fields` response (e.g. "custom8", "engagedAt") as values in the `additional_fields` parameter on search/get tools. Only pick fields needed to answer the user's query. Rules: - Never guess field IDs. Always use this tool first to discover valid IDs. - Both custom_fields and standard_fields from the response can be used for filtering and additional output. HOW TO USE CUSTOM OBJECTS Custom objects are admin-defined data structures unique to the organization (e.g. Campaigns, Webinars), distinct from standard objects like Prospects and Accounts — and distinct from a standard object's custom fields, which are a different thing fetched with entity_type "account" / "prospect" / etc. With entity_type "custom_object" the response is a `custom_objects` list plus a `custom_objects_count`, instead of the three sections above, and a `custom_objects_instruction` you must follow.

filter_schema_fetch

Returns the list of task priority lookup values configured for the organization (typically Urgent / High / Normal / Low). Each entry has an `id` and a `name`. Use this tool when: - The user asks "what task priorities do we have?" or "list task priority options". - You need to resolve a task priority name (e.g. "Urgent") to its ID for filtering tasks with `task_search` — the `taskPriority` filter attribute expects priority IDs, not names. Response: - `count`: total number of task priorities configured for the organization. The tool returns the first 30 of them, which is every priority for any realistic org; if `count` is larger than the list, the remainder is not retrievable through this tool. - `taskPriorities`: list of records, each with `id` and `name`.

task_priority_fetch

Retrieve a team using its unique identifier and return the corresponding Team object including: id: int created_at: str | None name: str | None users: list[User] (only id and name are returned for each user) Note: This tool returns only summary information (id, name) for users. To get full details about a user, use the user_get_by_id tool with the user's id.

team_get_by_id

Retrieve an account using its unique identifier and return the corresponding Account object including: id: int name: str | None companyType: str | None owner: User | None (only id and name are returned) assignedUsers: list[User] (only id and name are returned for each user) touchedAt: str | None industry: str | None defaultConnection: DataConnection | None The default fields are basic identifying information only. They CANNOT answer questions about any attribute not listed above, nor open-ended requests to describe, summarize, profile, or give an overview of the account — these all require additional fields. For any such question, call `filter_schema_fetch` with entity_type="account" FIRST to discover the available field IDs, then make a single `account_get_by_id` call passing them in `additional_fields`. Never call `account_get_by_id` before `filter_schema_fetch`, and never guess field IDs.

account_get_by_id

Retrieve an opportunity by id and return the Opportunity object with the default fields below. IMPORTANT: the default fields are basic identifying info only. They CANNOT answer questions about any attribute not listed below (e.g. decision criteria, decision process, metrics, champion, or any request to score/rate/describe the opportunity). For ANY question that cannot be answered from the default fields, you MUST, in order: (1) call `filter_schema_fetch(entity_type="opportunity")` FIRST to discover field IDs; (2) pick the field ID(s) matching the question; (3) make ONE `opportunity_get_by_id` call passing them in `additional_fields`. ALWAYS call `filter_schema_fetch` first, before setting include_sales_methodology=True. Default fields: id: int name: str | None account: Account | None (only id and name are returned) amount: int | None closeDate: str | None createdAt: str | None healthScore: float | None nextStep: str | None touchedAt: str | None updatedAt: str | None assignedUsers: list[User] (only id and name are returned for each user) opportunityStage: OpportunityStage | None owner: User | None (only id and name are returned) primaryProspect: Prospect | None (only id and name are returned) defaultConnection: DataConnection | None salesMethodology: SalesMethodology | None (only present when include_sales_methodology=True) fields: list[SalesMethodologyField] SalesMethodologyField contains the definition of a sales methodology field and the opportunity's value for that field, and includes: order: int | None label: str | None name: str | None labelShort: str | None type: str | None definition: str | None value: str | None (the opportunity's value for this field) use type and definition if set to determine how to interpret the value field. For example, when type is "RELATIONSHIP", definition is "PROSPECT", and value is "1280273", it means the value is id of the prospect resource. To get more details about the resource, use the corresponding get_by_id tool with the id, or other appropriate tools. In this example, use prospect_get_by_id with id 1280273 to get more details about the prospect. Note: salesMethodology is only available from this tool, not from opportunity_search or other opportunity tools. This tool returns only summary information (id, name) for nested objects such as owner, assignedUsers, and primaryProspect. The account field contains the parent account's id and name — use account.id (not the opportunity id) for account-scoped lookups. To get full details about the owner or an assigned user, use the user_get_by_id tool with the user's id. To get full details about the primary prospect, use the prospect_get_by_id tool with the prospect's id.

opportunity_get_by_id

Retrieve a prospect using its unique identifier and return the corresponding Prospect object including: id: int name: str | None owner: User | None (only id and name are returned) account: Account | None (only id, name, companyType, touchedAt, and industry are returned) assignedUsers: list[User] (only id and name are returned for each user) campaignName: str | None engagedScore: float | None engagedAt: str | None touchedAt: str | None stage: Stage | None defaultConnection: DataConnection | None The default fields are basic identifying information only. They CANNOT answer questions about any attribute not listed above, nor open-ended requests to describe, summarize, profile, or give an overview of the prospect — these all require additional fields. For any such question, call `filter_schema_fetch` with entity_type="prospect" FIRST to discover the available field IDs, then make a single `prospect_get_by_id` call passing them in `additional_fields`. Never call `prospect_get_by_id` before `filter_schema_fetch`, and never guess field IDs. Note: This tool returns only summary information for nested objects. To get full details about the owner or an assigned user, use the user_get_by_id tool with the user's id. To get full details about the account, use the account_get_by_id tool with the account's id. To get multiple prospects by their IDs, use the prospect_search tool with the ids parameter.

prospect_get_by_id

Returns the authenticated user's organization (single record): - `id`: the org's numeric ID. - `shortname`: short identifier of the org (string). - `opportunityAssociationDefault`: the org's default opportunity-association strategy — one of "manual", "noop", "recent_closed", "recent_closed_lost", "recent_closed_won", "recent_created", "recent_updated". Use this tool when: - The user asks "what's our default opportunity association?" or other org-configuration questions. - You need to know the server-side default for `opportunityAssociation` before calling `task_create` (the org default is applied when the parameter is omitted).

current_org

Retrieve an user using its unique identifier and return the corresponding User object including: id: int name: str | None firstName: str | None lastName: str | None email: str | None teams: list[Team] (only id and name are returned for each team) Note: This tool returns only summary information (id, name) for teams. To get full details about a team, use the team_get_by_id tool with the team's id. To get multiple users by their IDs, use the user_search tool with the ids parameter. Use the `additional_fields` param to include additional user fields in the response, such as the user's configured default ruleset/schedule for sequence creation.

user_get_by_id

Retrieve a list of calendar events (meetings) based on optional filter criteria. A calendar event represents a scheduled meeting or appointment on a user's calendar. Use this tool to fetch scheduled meetings which have not yet occurred or to review past meetings regardless of whether they had transcripts or were processed by Kaia's meeting intelligence features. Use the kaia_meeting_fetch tool to retrieve contents about meetings which have already occurred (transcripts, etc). Use this tool to explore meetings from calendar metadata (e.g. scheduled date, source, cancellation status, etc). Notes: - Multiple filters are combined with AND logic. - Use limit to control how many results are returned. - The tool automatically adjusts startTime filters using the user's timezone from context. You do NOT need to compute timezone offsets or convert dates to UTC yourself. Response: - Each event includes the title, time range, associated prospect/account/opportunity, and attendees. - The 'count' field indicates the total number of matching events, which may exceed the limit. When count > limit, state both the total and the number shown, e.g., "Showing 10 of 247 total events." When count <= limit, state only the count, e.g., "Found 3 calendar events."

calendar_events_fetch

Returns a list of opportunity stages with optional filtering. Opportunity stages represent the different phases in a sales process (e.g., 'Discovery', 'Negotiation', 'Closed Won'). Supported filter attributes: - id - name - isClosed Examples: - filter:[] → returns all opportunity stages - filter:[{"attribute": "isClosed", "operator": "is", "value": "true"}] → only stages that are subtypes of 'closed' - filter:[{"attribute": "id", "operator": "is", "value": ["1", "2"]}] → only stages with id 1 or 2 - filter:[{"attribute": "name", "operator": "is", "value": ["Discovery"]}] → only stages with name that exactly matches 'Discovery' Notes: - Partial string matching is not supported for 'name'. - Multiple filters are combined with AND logic (all must match). Response: - Each stage includes id, name, isActive, isWon, and isClosed fields. - The response 'count' field indicates the total number of matching stages, which may exceed the number of records returned when a limit is applied.

opportunity_stage_fetch

Returns the list of job roles configured for the organization. Job roles classify an user's role within their company's buying process (e.g. "SDR", "Sales Manager", "AE", "CSM", "Customer Success Manager"). Use this tool when: - The user asks "what job roles do we have?" or "list all job roles" - You need to resolve a job role name to its ID Response shape: - count: the TOTAL number of matching job roles (server-side, not limited by `limit`). - job_roles: the list of job role records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total job roles." When count <= limit, state only the count, e.g., "Found 3 job roles."

job_role_fetch

Returns the list of prospect lifecycle stages configured for the organization. Stages are org-level configuration labels that classify where a prospect sits in the outreach pipeline. They describe the prospect's overall disposition, NOT their enrollment in a specific sequence. Example stage names: - 'Not Started' - 'Not Started - Added to Sequence' - 'Attempting to Contact' - 'In Progress with Rep' - 'Closed - Unresponsive' - 'Closed - Not Interested - Unsubscribe' - 'Closed - Using Competitive Product' - 'Closed - Left Company' - 'Closed - Bad Timing' Use this tool when: - The user asks "what stages do we have?" or "list all prospect stages" - You need to resolve a stage name to its ID for filtering prospects by stage - The user wants to know the available disposition categories for prospects Do NOT use this tool to find which prospects are enrolled in a sequence or to check a prospect's progress through sequence steps — use sequence_state_search for that. Response: - Each stage includes id and name fields. - The response 'count' field indicates the total number of stages, which may exceed the number of records returned when a limit is applied.

stage_fetch

Returns the user id and email of the caller

current_user

Search across recorded calls and meetings captured by Kaia. Returns matching recordings with transcripts, topics, summaries, and associated account/opportunity info. WHEN TO USE: - When the user asks about what was discussed, said, mentioned, or reported in meetings or calls. - When the user asks for sentiment, objectives, concerns, or data points shared during recordings. - When the user explicitly references "Kaia calls", "meetings", or "recordings" as a data source. - When searching for what a specific person (prospect, contact, or external participant) said in meetings. - When an entity lookup (user_search, prospect_search) returns empty but current account_id or opportunity_id is available — search meeting content scoped to the account to find mentions of the person. Use this tool to find recordings by keyword, topic, account, opportunity, participant, host, date range, or title. Kaia captures two kinds of recordings: - Voice calls (phone/telephony calls): sourceType = "voice" - Meetings (video/screen-share conferences, e.g. Zoom, Teams): sourceType ≠ "voice" DEFAULT: do NOT filter by sourceType — search both voice and video recordings. Only scope to one source type when the user is EXPLICITLY and unambiguously referring to it: - voice (sourceType = "voice", operator "is") only for clear telephony references such as "phone calls", "dials", or "voice calls". - non-voice (sourceType = "voice", operator "isNot") only for clear video-conference references such as "video meetings" or "Zoom/Teams meetings". Generic colloquial terms — "calls", "customer calls", "sales calls", "meetings", "conversations", "recordings" — mean meetings in general and do NOT scope to a source type; leave sourceType unfiltered. When unsure, do not filter by sourceType. RELEVANCE AND SCOPE: - Match on the topic the user asked about. A 'search' hit on an account, company, or participant name does NOT mean the recording discusses a same-spelled feature or product. When the intent is a topic/feature, prefer 'transcript.text' or 'topic.type' over a broad 'search', and verify the returned transcript segments are actually about that topic before treating a recording as a match. - Do NOT add a 'meeting.startTime' date filter unless the user specifies a timeframe. The word "recent" alone is not a date filter — omit the date window (results are returned newest-first) so older but relevant recordings are not excluded. - Do NOT add a 'meeting.sourcetype' filter unless the user explicitly scopes to calls or meetings. - If a filtered search returns no matches, broaden it (remove the date/source filter, widen the window, or relax the keywords) before concluding that no relevant recording exists. FILTER FORMAT: Pass a JSON list of filter objects. Each filter has the shape: {attribute, value, operator}. - attribute: the field to filter on (see supported attributes below) - value: list of string values to match - operator: (optional) defaults to "is". Supported: "is", "isNot" (plus date-specific operators for 'meeting.startTime', see below) All filters are combined with AND logic. SUPPORTED FILTER ATTRIBUTES: - 'search' — full-text keyword search across transcripts, notes, action items, meeting title, participant/account/opportunity names. Syntax: Single word: value: ["budget"] Implicit AND: value: ["budget planning"] Explicit OR: value: ["\"budget\" OR \"planning\""] Exact phrase: value: ["\"budget planning\""] - 'transcript.text' — search only within transcript text (more precise than 'search'). Example: [{attribute: "transcript.text", value: ["budget"], operator: "is"}] - 'topic.type' — detected topic name. General topics: 'budgetpricing', 'competitor', 'demotrial', 'discovery', 'eventmarketing', 'legal', 'logistics', 'nextstep', 'organization', 'product', 'purchase', 'salespitch', 'stakeholder', 'support'. MEDDPICC topics (prefix 'salesMethodology:'): 'salesMethodology:champion', 'salesMethodology:competitor', 'salesMethodology:metrics', 'salesMethodology:economicbuyer', 'salesMethodology:decisionprocess', 'salesMethodology:decisioncriteria', 'salesMethodology:paperprocess', 'salesMethodology:implicatepain'. Auto-enrichment: non-built-in names (e.g. "Salesforce") are automatically mapped to custom topic IDs if a match is found. Built-in types 'competitor' and 'product' automatically include all active custom topics of that type. Example: value: ["competitor", "Salesforce"] finds meetings tagged with any built-in competitor topic, all custom competitor topics, and the custom topic named 'Salesforce'. IMPORTANT: always pair a topic.type filter with include: [{attribute: "topic", includeType: "matching"}] to receive the matching topic segments in the results. Do NOT include transcript. - 'meeting.accountid' — account id - 'meeting.opportunityid' — opportunity id - 'meeting.participant.userid' — participant id (not just host). If the participant is an Outreach user, this is their user id. If the participant is a prospect, this is their prospect id prepended with `p_` (e.g. `p_1234`). - 'meeting.host.userid' — host user id - 'meeting.sourcetype' — value: ["voice"], operator: "is" for calls; value: ["voice"], operator: "isNot" for meetings. - 'meeting.startTime' — date/range filter. Use ONLY these operators (no others are valid): "is" — exact date match: value: ["2026-03-10"], operator: "is" "between" — date range: value: ["2026-03-01", "2026-03-05"], operator: "between" Relative operators (value must be ["0"], operator is one of the following exact strings): "last7Days" — past 7 days (use for "this week" or "last 7 days") "last30Days" — past 30 days "last90Days" — past 90 days "lastMonth" — the previous calendar month "thisMonth" — the current calendar month "today" — today only "untilToday" — from the beginning of time until today "ytd" — year to date - 'meeting.title' — filter by keyword in meeting title - 'meeting.duration' - filter by meeting duration in minutes. Supported operators include: "gte" - greater than or equal to "lte" - less than or equal to "between" - duration between value[0] and value[1] All attributes accept multiple comma-separated values. FILTER EXAMPLES: filter: [{attribute: "search", value: ["Amplify OR budget"]}] filter: [{attribute: "topic.type", value: ["competitor", "Salesforce"], operator: "is"}, {attribute: "meeting.accountid", value: ["123"]}] filter: [{attribute: "topic.type", value: ["salespitch"], operator: "isNot"}] filter: [{attribute: "meeting.sourcetype", value: ["voice"], operator: "is"}] filter: [{attribute: "meeting.sourcetype", value: ["voice"], operator: "isNot"}] INCLUDE FORMAT: Controls which artifact types are returned alongside each matching meeting. Only include artifact types relevant to the query to avoid unnecessary data. attribute values: - 'transcript' — transcript segments - 'topic' — detected topics includeType values: - 'matching' — return only artifacts that match the current filter/search INCLUDE EXAMPLES: Required for keyword search only: [{attribute: "transcript", includeType: "matching"}] Required for topic search only: [{attribute: "topic", includeType: "matching"}] Only when searching both simultaneously: [{attribute: "transcript", includeType: "matching"}, {attribute: "topic", includeType: "matching"}] Do NOT include transcript when topic.type is used as a filter — it returns unrelated segments and inflates the response. PAGINATION: Use 'first' (default 10, max 30) to control page size. Use 'after' with the end_cursor from a previous response to fetch the next page.

kaia_meeting_search

Search for accounts using id of the associated object in external systems, such as Saleforce or Dynamics. The search will return a list of Accounts. The Account contains the same information returned by account_get_by_id tool.

account_search_by_external_id

Search for accounts by filtering on standard or custom field values. Use this tool whenever the user asks to look up, list, or filter accounts — including simple lookups. Filterable concepts include (non-exhaustive, conceptual only): - account name (partial or full match) - account identifiers - owner / team - created / updated / last contacted / account plan updated timestamps - industry, company type, buyer intent score - any custom field defined on the account entity IMPORTANT: The bullets above describe SEARCHABLE CONCEPTS, not literal attribute names. Do NOT pass any of those labels (e.g. "account name", "owner", "industry") directly as a filter attribute. The actual attribute identifier and the operators it accepts MUST be obtained from `filter_schema_fetch` before constructing any filter — they vary by tenant and cannot be inferred from this description. All filters — both standard and custom fields — are passed via `additional_field_filters`. There are no dedicated named filter parameters. Required workflow (MUST follow in order): 1. MUST call `filter_schema_fetch` with entity_type="account" FIRST to discover the exact attribute identifiers and the allowed operators for each attribute. Never guess, abbreviate, or transform attribute names (no camelCase/snake_case guessing, no reusing labels from this description). 2. Build each filter using ONLY an attribute identifier and an operator returned by `filter_schema_fetch`, then pass them in `additional_field_filters` (AND logic). 3. Optionally pass attribute identifiers (also from `filter_schema_fetch`) in `additional_fields` to include extra output fields. Calling with no filters returns all accounts in the system (use `limit` to cap result size). Returns an Account collection. Each account contains the same information as `account_get_by_id`. Default fields always returned (do NOT request these via `additional_fields`): id, name, companyType, owner, touchedAt, industry, defaultConnection. Response shape: - count: the TOTAL number of matching accounts (server-side, not limited by `limit`). - accounts: the list of account records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total accounts." When count <= limit, state only the count, e.g., "Found 3 accounts."

account_search

Fetches outbound emails for a specific account, opportunity, or prospect. IMPORTANT: This tool ONLY returns emails sent BY reps, not emails received from prospects. If the user asks about received/inbound emails, use state='replied' to find emails that got replies, then use email_fetch_thread to retrieve the reply content. If a user query does not reference an account, opportunity, or prospect: 1. DO NOT call this tool with null values for account_id, opportunity_id, or prospect_id 2. Ask the user: "Which account, opportunity, or prospect would you like to search for emails in?" 3. Wait for the user to provide the information before proceeding 4. A tool call will likely be made to map the name from a user to the corresponding ID Only call this tool after the user has provided at least one of these identifiers. When multiple scope filters are provided, they combine with AND logic (e.g. account_id + prospect_id returns only emails to that prospect within that account). Additionally, use user_id to filter emails sent or received by a specific user. If a user asks about "my emails" or "emails I've sent/received", use the current user id as user_id.

emails_search

Search for opportunities using id of the associated object in external systems, such as Saleforce or Dynamics. The search will return a list of Opportunities. The Opportunity contains the same information returned by opportunity_get_by_id tool, except sales_methodology which is only available via opportunity_get_by_id.

opportunity_search_by_external_id

Search for opportunities by filtering on standard or custom field values. Use this tool whenever the user asks to look up, list, or filter opportunities — including simple lookups. Filterable concepts include (non-exhaustive, conceptual only): - opportunity name (partial or full match) - opportunity identifiers - related account, owner / assigned user - open/closed status, opportunity stage - created / close / last contacted / updated timestamps - amount, health score - any custom field defined on the opportunity entity IMPORTANT: The bullets above describe SEARCHABLE CONCEPTS, not literal attribute names. Do NOT pass any of those labels (e.g. "opportunity name", "owner", "stage") directly as a filter attribute. The actual attribute identifier and the operators it accepts MUST be obtained from `filter_schema_fetch` before constructing any filter — they vary by tenant and cannot be inferred from this description. All filters — both standard and custom fields — are passed via `additional_field_filters`. There are no dedicated named filter parameters. Required workflow (MUST follow in order): 1. MUST call `filter_schema_fetch` with entity_type="opportunity" FIRST to discover the exact attribute identifiers and the allowed operators for each attribute. Never guess, abbreviate, or transform attribute names (no camelCase/snake_case guessing, no reusing labels from this description). 2. Build each filter using ONLY an attribute identifier and an operator returned by `filter_schema_fetch`, then pass them in `additional_field_filters` (AND logic). 3. Optionally pass attribute identifiers (also from `filter_schema_fetch`) in `additional_fields` to include extra output fields. Calling with no filters returns all opportunities in the system (use `limit` to cap result size). The Opportunity contains the same information returned by opportunity_get_by_id tool, except sales_methodology which is only available via opportunity_get_by_id. Each opportunity result includes the parent account (account.id, account.name). Default fields always returned (do NOT request these via `additional_fields`): id, account, amount, close_date, created_at, health_score, name, next_step, last_contacted_at, updated_at, assigned_users, opportunity_stage, owner, primary_prospect, default_connection. Response shape: - count: the TOTAL number of matching opportunities (server-side, not limited by `limit`). - opportunities: the list of opportunity records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 247 total opportunities." When count <= limit, state only the count, e.g., "Found 3 opportunities." When the user asks about health score without specifying exact numbers, use the healthScoreValue filter attribute: - any mention of health score without a specific range → filter healthScoreValue with gte=0, lte=100 to only return opportunities that have a valid health score When filtering by health score range, sort by healthScoreValue ascending to show the most critical opportunities first (sort=["healthScoreValue"]). A null/missing health_score means the score is unknown/unavailable — NOT that the score is 0 or low. When presenting results filtered by health score, note any records with missing health score values.

opportunity_search

Search for prospects using id of the associated object in external systems, such as Saleforce or Dynamics. The search will return a list of Prospects. The Prospect contains the same information returned by prospect_get_by_id tool.

prospect_search_by_external_id

Search for prospects by filtering on standard or custom field values. Use this tool whenever the user asks to look up, list, or filter prospects — including simple lookups. Filterable concepts include (non-exhaustive, conceptual only): - prospect name (partial or full match) - prospect identifiers - owner / assigned user - related account or opportunity - stage, engagement score, engagement timestamp - any custom field defined on the prospect entity IMPORTANT: The bullets above describe SEARCHABLE CONCEPTS, not literal attribute names. Do NOT pass any of those labels (e.g. "prospect name", "owner", "stage") directly as a filter attribute. The actual attribute identifier and the operators it accepts MUST be obtained from `filter_schema_fetch` before constructing any filter — they vary by tenant and cannot be inferred from this description. All filters — both standard and custom fields — are passed via `additional_field_filters`. There are no dedicated named filter parameters. Required workflow (MUST follow in order): 1. MUST call `filter_schema_fetch` with entity_type="prospect" FIRST to discover the exact attribute identifiers and the allowed operators for each attribute. Never guess, abbreviate, or transform attribute names (no camelCase/snake_case guessing, no reusing labels from this description). 2. Build each filter using ONLY an attribute identifier and an operator returned by `filter_schema_fetch`, then pass them in `additional_field_filters` (AND logic). 3. Optionally pass attribute identifiers (also from `filter_schema_fetch`) in `additional_fields` to include extra output fields. Calling with no filters returns all prospects in the system (use `limit` to cap result size). Returns a Prospect collection. Each prospect contains the same information as `prospect_get_by_id`. Default fields always returned (do NOT request these via `additional_fields`): id, name, owner, account, assignedUsers, campaignName, engagedScore, engagedAt, stage, defaultConnection. Response shape: - count: the TOTAL number of matching prospects (server-side, not limited by `limit`). - prospects: the list of prospect records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total prospects." When count <= limit, state only the count, e.g., "Found 3 prospects."

prospect_search

Search for rulesets in Outreach by filtering on standard field values. IMPORTANT: The total number of rulesets in an org is usually small. Prefer calling this tool with NO filter to retrieve all available rulesets (raise `limit` if needed) and do any narrowing yourself from the results. Only pass a `filter` when it is absolutely necessary — e.g. the user names a specific owner, or the result set is large enough that unfiltered retrieval is impractical. Do not filter by default "just in case." Filterable concepts include (non-exhaustive, conceptual only): - ruleset owner - ruleset name (exact match) - created / last-updated timestamps IMPORTANT: The bullets above describe SEARCHABLE CONCEPTS, not literal attribute names. Do NOT pass any of those labels (e.g. "owner", "ruleset name") directly as a filter attribute. The actual attribute identifier and the operators it accepts MUST be obtained from `filter_schema_fetch` before constructing any filter — they cannot be inferred from this description. Required workflow when a filter IS actually needed (MUST follow in order): 1. MUST call `filter_schema_fetch` with entity_type="ruleset" FIRST to discover the exact attribute identifiers and the allowed operators for each attribute. Never guess, abbreviate, or transform attribute names. 2. Build each filter using ONLY an attribute identifier and an operator returned by `filter_schema_fetch`, then pass them in `filter` (AND logic). Calling with no filters returns all rulesets in the system (use `limit` to cap result size). Returns a list of Rulesets. Each ruleset contains: - id, name, createdAt, updatedAt, owner (id, name) The response includes: - count: the TOTAL number of matching rulesets (server-side, not limited by the limit parameter). - rulesets: the list of ruleset records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total rulesets." When count <= limit, state only the count, e.g., "Found 3 rulesets."

ruleset_search

Search for schedules in Outreach by filtering on standard field values. Use this tool whenever the user asks to look up, list, or filter schedules — including simple lookups. Filterable concepts include (non-exhaustive, conceptual only): - schedule owner - schedule name (exact match) - created / last-updated timestamps IMPORTANT: The bullets above describe SEARCHABLE CONCEPTS, not literal attribute names. Do NOT pass any of those labels (e.g. "owner", "schedule name") directly as a filter attribute. The actual attribute identifier and the operators it accepts MUST be obtained from `filter_schema_fetch` before constructing any filter — they cannot be inferred from this description. Required workflow when a filter IS actually needed (MUST follow in order): 1. MUST call `filter_schema_fetch` with entity_type="schedule" FIRST to discover the exact attribute identifiers and the allowed operators for each attribute. Never guess, abbreviate, or transform attribute names. 2. Build each filter using ONLY an attribute identifier and an operator returned by `filter_schema_fetch`, then pass them in `filter` (AND logic). Calling with no filters returns all schedules in the system (use `limit` to cap result size). Returns a list of Schedules. Each schedule contains: - id, name, createdAt, updatedAt, owner (id, name) The response includes: - count: the TOTAL number of matching schedules (server-side, not limited by the limit parameter). - schedules: the list of schedule records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total schedules." When count <= limit, state only the count, e.g., "Found 3 schedules."

schedule_search

Search for sequence states — records that track an individual prospect's involvement and progress through the steps of a specific outreach sequence. Each sequence state ties one prospect to one sequence and captures their current execution state within that sequence (e.g., 'active', 'bounced', 'paused', 'finished'). A sequence state is NOT the same as a prospect stage. Prospect stages (e.g., 'Attempting to Contact', 'Closed - Unresponsive') describe the prospect's overall disposition in the pipeline. Sequence states describe whether a prospect is currently progressing through a specific sequence's steps. Use this tool when: - The user asks about prospects involved in a specific sequence - The user asks who has been contacted, bounced, replied, or is active in a sequence - The user wants to check a prospect's progress through sequence steps - The user asks about outreach activity tied to a sequence Do NOT use this tool to list the org-level prospect disposition stages — use stage_fetch for that. Filterable concepts include (non-exhaustive, conceptual only): - sequence state (active, bounced, replied, finished, etc.) - associated accounts, prospects, opportunities, sequences, teams, users - sequence status, creator type, step number - created / updated / due / paused / failed timestamps IMPORTANT: The bullets above describe SEARCHABLE CONCEPTS, not literal attribute names. Do NOT pass any of those labels directly as a filter attribute. The actual attribute identifier and the operators it accepts MUST be obtained from `filter_schema_fetch` before constructing any filter. Required workflow (MUST follow in order): 1. MUST call `filter_schema_fetch` with entity_type="sequence_state" FIRST to discover the exact attribute identifiers and the allowed operators for each attribute. Never guess, abbreviate, or transform attribute names. 2. Build each filter using ONLY an attribute identifier and an operator returned by `filter_schema_fetch`, then pass them in `additional_filters` (AND logic). Calling with no filters returns all sequence states in the system (use `limit` to cap result size). Returns matching sequence states and total count. Each SequenceState includes: id: int prospect: Prospect | None sequence: Sequence | None sequenceStep: SequenceStep | None state: str | None user: User | None updatedAt: str | None Supports pagination via limit and offset parameters.

sequence_state_search

Search for sequences using additional_filters for field-level filtering with AND logic. Returns a list of Sequences. Each sequence contains: - id, name, owner, engagementScore, sequenceSteps, enabled The response includes: - count: the TOTAL number of matching sequences (server-side, not limited by the limit parameter). - sequences: the list of sequence records (up to `limit` items). Use `offset` to page through results when count exceeds `limit`. When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total sequences." When count <= limit, state only the count, e.g., "Found 3 sequences."

sequence_search

Returns task themes configured for the organization — categorization tags that users assign when creating tasks. Each entry has an `id`, `action`, and `name`. Use this tool when: - The user asks "what task themes do we have?" or "list available task themes". - You need to resolve a task theme to its ID for filtering tasks with `task_search`, or for supplying the `taskTheme` relationship to `task_create`. Filtering: Only the following (attribute, operator) pairs are supported in `filter`; any other attribute or operator is rejected with an error. - attribute: "action", operator: "is", value: ["<action>", ...] - attribute: "id", operator: "is", value: ["<id>", ...] Multiple values within a single filter use OR logic. Multiple filter entries combine with AND. Sorting: `sort` accepts ONLY these values (prefix with `-` for descending order): - "id", "-id" - "action", "-action" Response: - `count`: total number of matching task themes (server-side, not limited by `limit`). - `taskThemes`: list of records, each with `id`, `action`, and `name`.

task_theme_search

Search for tasks (calls, emails, action items, in-person, LinkedIn, SMS) by filtering on task attributes. Use this tool whenever the user asks to look up, list, or filter their tasks or any other user's tasks (e.g. "my open calls", "overdue tasks for the EMEA team", "tasks scheduled for tomorrow"). Filterable concepts include (non-exhaustive, conceptual only): - task state (incomplete, complete, skipped) and isTrashed flag - owner / assigned user - related account, opportunity, prospect, sequence, stage, sequence step, sequence state - type (action_item, call, email, in_person, linkedin, sms) - origin (manual, sequence, reminder, emailOpen, emailClick, trigger) - task priority, theme, teams - dueAt, completedAt, createdAt, updatedAt, engagedAt, scheduledAt dates - tags (collection), note (text), localTime (numeric) - callDisposition (existence-only) IMPORTANT: The bullets above describe SEARCHABLE CONCEPTS, not literal attribute names. Do NOT pass any of those labels directly as a filter attribute. The actual attribute identifier and the operators it accepts MUST be obtained from `filter_schema_fetch` with entity_type="task" before constructing any filter — they vary by tenant and cannot be inferred from this description. All filters are passed via `filters`. There are no dedicated named filter parameters. Required workflow (MUST follow in order): 1. MUST call `filter_schema_fetch` with entity_type="task" FIRST to discover the exact attribute identifiers and the allowed operators for each attribute. Never guess, abbreviate, or transform attribute names. 2. Build each filter using ONLY an attribute identifier and an operator returned by `filter_schema_fetch`, then pass them in `filters` (AND logic). 3. Optionally pass field names in `additional_fields` to include extra output fields. Only "subject" and "title" are supported; any other name — including custom fields, which are filterable but not selectable here — is an error, so do not pass one. Calling with no filters returns all tasks visible to the caller (use `limit` to cap result size). Returns a Task collection. Default fields always returned (do NOT request these via `additional_fields`): id, account, attributableSequenceId, attributableSequenceName, completed, completer, createdAt, dueAt, note, opportunity, owner, prospect, prospectStage, sequence, sequenceStep, state, stateChangedAt, taskCategory, taskType, taskTheme, defaultConnection. Response shape: - count: the TOTAL number of matching tasks (server-side, not limited by `limit`). - tasks: the list of task records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total tasks." When count <= limit, state only the count, e.g., "Found 3 tasks."

task_search

Search for teams in Outreach. Returns a list of teams matching the given criteria. Supports filtering by favorited by users, content categories, creation date, team IDs, and name. IMPORTANT: To fetch multiple teams by ID, pass all IDs in the `ids` parameter as a single call instead of making separate requests for each team. For example, use ids: [1, 2, 3] to retrieve three teams in one request. Returns a list of Teams. The response includes: - count: the TOTAL number of matching teams (server-side, not limited by the limit parameter). - teams: the list of teams records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total teams." When count <= limit, state only the count, e.g., "Found 3 teams."

team_search

Search for users using: - the supported filters: name (partial or full name) and ids (list of user IDs). - `additional_filters` to filter by field values with AND logic. By default, locked and guest users are excluded (locked=false, guest=false). To include locked or guest users, pass the corresponding filter with value ["true"] in additional_filters. PREFERRED over calling team_get_by_id repeatedly: when you need users from multiple teams, use a single user_search call with a team filter (e.g. {"attribute": "team", "operator": "is", "value": ["1", "2", "3"]}) instead of calling team_get_by_id for each team. Returns a list of Users. Each user contains the same information returned by user_get_by_id tool. The response includes: - count: the TOTAL number of matching users (server-side, not limited by the limit parameter). - users: the list of user records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total users." When count <= limit, state only the count, e.g., "Found 3 users."

user_search