Outreach

Creates a new template in Outreach. Returns only the id of the created template. Rules for filling in the input: - name (required): MUST come from the user. If the user has not given a name, ask for it before calling this tool. Never make one up, even when you draft the subject and body. - subject, bodyHtml: by default, take them from the user and use their wording verbatim. Draft them yourself ONLY when the user explicitly asks you to write the content, e.g. "create a template named Intro and draft the subject and body for a first email to a new prospect". That permission covers subject and bodyHtml only. When drafting, do not add merge-field variables unless the user asks for specific ones. If the user wants a subject or body but has neither supplied it nor asked you to draft it, ask for it. - bodyHtml should be valid HTML, e.g. "<p>Hi there,</p><p>Thanks for reaching out.</p>". Plain text is also accepted: when the user supplies plain text, pass their wording unchanged. - All other fields (owner, toRecipients, ccRecipients, bccRecipients, shareType, tags, locale, trackLinks, trackOpens, clonedFromId, containsCustomHtml, statsTarget, contentCategoryMemberships) MUST be explicitly provided by the user or resolved from their request via a lookup tool. NEVER infer, guess, or fabricate these values or any IDs; omit a field the user did not ask for. The current user is automatically assigned as the owner if no owner is specified in the input; the call fails if no owner is given and the current user cannot be determined. The template is always created unarchived. Use `user_search` to resolve an owner's name to a user id, and `template_search` to resolve the ids of existing templates for statsTarget or clonedFromId. Behavior: - If no owner is given and the current user cannot be determined, the call fails. - The template is always created unarchived.

template_create

Deletes a prospect in Outreach by its ID. Returns a confirmation message with the deleted prospect's ID. IMPORTANT: Always ask the user for explicit confirmation before invoking this tool. Do not proceed with deletion without the user's approval.

prospect_delete

Deletes a sequence in Outreach by its ID. Returns a confirmation response with the deleted sequence's ID. IMPORTANT: Always ask the user for explicit confirmation before invoking this tool. Do not proceed with deletion without the user's approval.

sequence_delete

Deletes an account in Outreach by its ID. Returns a confirmation message with the deleted account's ID. IMPORTANT: Always ask the user for explicit confirmation before invoking this tool. Do not proceed with deletion without the user's approval.

account_delete

Deletes an opportunity in Outreach by its ID. Returns a confirmation response with the deleted opportunity's ID. IMPORTANT: Always ask the user for explicit confirmation before invoking this tool. Do not proceed with deletion without the user's approval.

opportunity_delete

Destroy (delete/remove) sequence states in bulk. Sequence states track a prospect's involvement in a specific outreach sequence. Destroying a sequence state removes the prospect from that sequence entirely. Use this tool when: - The user wants to remove prospects from a sequence - The user wants to bulk-delete sequence states by ID Accepts an input with sequence state IDs to destroy. Returns a Batch object representing the bulk operation. IMPORTANT: Always ask the user for explicit confirmation before invoking this tool. Do not proceed with destroy without the user's approval. After receiving the batch response, use the batch_get_by_id tool with the returned batch ID to check its progress and report the final state (total, failures, pending) to the user.

sequence_states_destroy

Fetch a page of Kaia scorecards configured for the organization. Returns a list of Scorecard objects, each including: id: str name: str | None enabled: bool | None autoScoringEnabled: bool | None metadata: creator/lastEditor/publisher (only id and name are returned for each user), createdAtUtc, modifiedAtUtc, publishedAtUtc questions: list of scorecard questions, each with a `type` discriminator (ScorecardFreeTextQuestion, ScorecardYesNoQuestion, ScorecardRangeQuestion, ScorecardSingleOptionQuestion, or ScorecardMultiOptionQuestion), plus id, order, question, isDefault, state, metadata (creator/lastEditor/publisher, createdAtUtc, modifiedAtUtc, publishedAtUtc), aiInstructions, and (for option questions) options/intents, and (for range questions) rangeMin/rangeMax Note: This tool returns only summary information (id, name) for creator/lastEditor/publisher. To get full details about a user, use the user_get_by_id tool with the user's id. Note: This endpoint does not report a total count. Use offset/limit to page through results; fewer scorecards than `limit` in the response indicates the last page.

kaia_scorecard_fetch

Fetch call and meeting recording information (summaries and/or transcripts) for specific meetings by instance ID. Use this when you already know the meeting instance IDs. BATCHING RULE: - ALWAYS pass all meeting instance IDs in a single call as a list. - CORRECT: instance_id=["id1","id2","id3"] (one call) - WRONG: three separate calls with instance_id=["id1"], instance_id=["id2"], instance_id=["id3"] Do NOT use for searching by topic or keyword — use kaia_meeting_search instead. RETRIEVAL STRATEGY: - For high-level overviews, action items, or follow-up emails: include_summary=true is usually sufficient. - For exact quotes or verbatim discussion: include_transcript=true. - If summaries do not contain the needed information, immediately call again with include_transcript=true. Do NOT ask the user — retrieve automatically in the same turn.

kaia_meeting_fetch

Fetch the available input fields for a resource create/update action. Returns a ResourceInputSchema with three sections: - standard_fields: typed optional fields (e.g. companyType, industry, assignedTeams). - ref_types: definitions of non-scalar types referenced by standard_fields (e.g. TeamRelationship, UserRelationship — each with its 'id' field). - custom_fields: organization-specific custom fields with validation metadata. Supported resources: Account, Prospect, Opportunity Supported actions: Create, Update Every resource/action combination is supported (e.g. resource="Opportunity", action="Create"; resource="Prospect", action="Update"). Any other resource or action is rejected with an error. Response structure: resource (str): The resource type ('Account', 'Prospect', or 'Opportunity'). action (str): The action type ('Create' or 'Update'). standard_fields (list): Standard optional fields, each containing: - name: camelCase GQL field name (e.g. 'companyType', 'assignedTeams') - type: concise type string (e.g. 'string', 'int', 'float', 'TeamRelationship', 'list[UserRelationship]', 'list[string]') - required: whether the field is required for the action - description: description of the field ref_types (list): Non-scalar type definitions referenced by standard_fields. Each contains: - name: type name (e.g. 'TeamRelationship', 'UserRelationship') - description: description of the type - fields: list of fields in this type, each with name, type, required custom_fields (list): Custom fields with validation rules, each containing: - name: internal field identifier (e.g. 'custom1') - label: human-readable label (e.g. 'Region') - required: whether the field is required - description: description of the custom field - validation_type: validation kind ('numerical', 'inclusion', 'string', 'currency', 'date') - validation_definition: accepted values for 'inclusion' type, currency code for 'currency' type, etc. Example response: { "resource": "Account", "action": "Create", "standard_fields": [ {"name": "companyType", "type": "string", "required": false, "description": "Company type of the account"}, {"name": "assignedTeams", "type": "list[TeamRelationship]", "required": false, "description": "Teams assigned to the account"} ], "ref_types": [ {"name": "TeamRelationship", "description": "A relationship reference to a Team entity.", "fields": [{"name": "id", "type": "int", "required": true, "description": "ID of the related entity"}]}, {"name": "UserRelationship", "description": "A relationship reference to a User entity.", "fields": [{"name": "id", "type": "int", "required": true, "description": "ID of the related entity"}]} ], "custom_fields": [ {"name": "custom1", "label": "Region", "required": true, "description": "Region", "validation_type": "inclusion", "validation_definition": ["NA", "EMEA", "APAC"]} ] }

input_fields_fetch

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

Filter-based lookup that retrieves individual voice call log records. Use this tool when the user wants the actual call records — to list, inspect, or filter them by call log attributes (e.g. "my calls from last week", "calls with no answer for the EMEA team", "outbound calls longer than 5 minutes"). SCOPE — call log records only. Two kinds of question belong to OTHER tools: - CONVERSATION CONTENT → use `kaia_meeting_search`. This tool carries call log metadata only: no transcript, recording content, topics, or summaries, and no notion of what was actually said. Anything about what was discussed, said, asked, or objected to, about sentiment, or about coaching feedback on how a call was handled goes to Kaia. - STATISTICS AND PERFORMANCE → use the analytics tools, such as `analytics_fetch`. This tool does NOT aggregate, rank, rate, or trend anything; it returns records, not computed figures. Any question about rates, totals, averages, trends, leaderboards, or patterns across a rep, a team, or a time period belongs to analytics — "what is our answer rate", "average call duration", "how have calls trended", "top callers by rep", "analyze calls for my SDRs over the last 2 months and tell me what patterns you see across the team". Do not fetch a page of call records in order to compute such a figure yourself; the analytics tools answer over the full population, this tool returns at most `limit` rows. Sales-motion phrases — "cold call", "discovery call", "follow-up call" — describe the kind of conversation, not a call log attribute. There is no filter for them here, so do not approximate one. Only limit/offset pagination is supported. Filterable concepts include (non-exhaustive, conceptual only): - call disposition, call purpose, queue - owner / user, team, sequence, sequence step - related prospect, opportunity, account (scope filters) - tags (collection), prospect tags (collection) - platform (call_source), state, call method (user_call_type) - direction (outbound), recorded - created_at (unique date operator set), duration (numeric, seconds) 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="call" before constructing any filter — they 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="call" 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 not returned by default. `filter_schema_fetch` with entity_type="call" also lists these selectable field names. Calling with no filters returns all calls visible to the caller (use `limit` to cap result size). Returns a Call collection. Default fields always returned (do NOT request these via `additional_fields`): id, answeredAt, callDisposition, callPurpose, completedAt, createdAt, direction, dispositionDisplay, durationSeconds, endReason, from, note, opportunity, outbound,outcome, platform, prospect, prospectNumber, recordingUrl, sequence, sequenceState, sequenceStep, sequenceStepNumber, state, stateChangedAt, tags, task, to, updatedAt, user. Response shape: - count: the TOTAL number of matching calls (server-side, not limited by `limit`). - calls: the list of call records (up to `limit` items). When count > limit, state both the total and the number shown, e.g., "Showing 10 of 50 total calls." When count <= limit, state only the count, e.g., "Found 3 calls."

call_search

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) mailbox: Mailbox | None (the user's default mailbox; only id and email are returned) 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 Kaia scorecard using its unique identifier and return the corresponding Scorecard object including: id: str name: str | None enabled: bool | None autoScoringEnabled: bool | None metadata: creator/lastEditor/publisher (only id and name are returned for each user), createdAtUtc, modifiedAtUtc, publishedAtUtc questions: list of scorecard questions, each with a `type` discriminator (ScorecardFreeTextQuestion, ScorecardYesNoQuestion, ScorecardRangeQuestion, ScorecardSingleOptionQuestion, or ScorecardMultiOptionQuestion), plus id, order, question, isDefault, state, metadata (creator/lastEditor/publisher, createdAtUtc, modifiedAtUtc, publishedAtUtc), aiInstructions, and (for option questions) options/intents, and (for range questions) rangeMin/rangeMax Note: This tool returns only summary information (id, name) for creator/lastEditor/publisher. To get full details about a user, use the user_get_by_id tool with the user's id.

kaia_scorecard_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 call dispositions (call outcome options, e.g. "Connected", "No Answer", "Voicemail") configured for the organization. Use this tool when: - The user asks "what call dispositions do we have?" or "list all call dispositions" - You need to resolve a call disposition name to its ID - The user wants to know the available outcome categories for calls Response: - Each call disposition includes id, name, order, outcome, defaultForOutboundVoicemail, createdAt, and updatedAt fields. - The response 'count' field indicates the total number of call dispositions, which may exceed the number of records returned when a limit is applied.

call_disposition_fetch

Returns the list of call purposes (the intent/reason categories for a call, e.g. "Discovery", "Demo", "Follow-up") configured for the organization. Use this tool when: - The user asks "what call purposes do we have?" or "list all call purposes" - You need to resolve a call purpose name to its ID Response: - Each call purpose includes id, name, order, createdAt, and updatedAt fields. - The response 'count' field indicates the total number of call purposes, which may exceed the number of records returned when a limit is applied.

call_purpose_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'). Same syntax as 'search'; quote each term of an OR: value: ["\"budget\" OR \"planning\""] 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 Kaia scorecard scores — the filled-in coach cards recorded against a meeting, whether scored by a person or by AI. Use this to answer how a rep was rated on a call, what a reviewer answered question by question, or what AI feedback a call received. Provide at least one of instance_id/instance_ids, scorecard_id, target_user_id, scorer_id or score_id; combined criteria are ANDed. Returns a list of ScorecardScore objects, each including: id: str instanceId: str — the meeting instance the scorecard was applied to targetUser: the user being scored (id and name only) card: the scorecard template (id and name only) responses: one entry per question, each with question: the question, with a `type` discriminator (ScorecardFreeTextQuestion, ScorecardYesNoQuestion, ScorecardRangeQuestion, ScorecardSingleOptionQuestion, or ScorecardMultiOptionQuestion), plus id, order, question, and rangeMin/rangeMax (range questions) or options (option questions) originalQuestion: the question text as it read when the score was recorded note: free-text note left with the answer response: the answer, with a `type` discriminator — ScorecardSimpleResponse (answer), ScorecardQuestionYesNoResponse (response), ScorecardRangeResponse (score, floatScore), ScorecardSingleOptionResponse (selected), or ScorecardMultiOptionResponse (selectedOptions) suggestionMoments, aiFeedback: populated only when include_ai_suggestions is true scoredBy: who or what produced the score, with a `type` discriminator — AIService (id, name) for an AI-generated score, or User (id, name) for a human reviewer visibility: level (PUBLIC, PRIVATE_TO_RECEPIENT, PRIVATE_TO_ME, CUSTOM) and, for CUSTOM, the customAllowList of users createdAtUtc, modifiedAtUtc: str suggestedOverallRating: int | None — calculated overall rating for the scorecard Note: `card` returns only summary information (id, name). To get the full scorecard template with all its questions, use the kaia_scorecard_get_by_id tool with card.id. Likewise use user_get_by_id for full details of targetUser or a human scorer. Note: This endpoint does not report a total count. Use offset/limit to page through results; fewer scores than `limit` in the response indicates the last page.

kaia_scorecard_score_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 creator: User | None (user who created the enrollment) 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