How to connect Apollo MCP with Claude Code

Use the Create an Account endpoint to add a new account to your team's Apollo account. Use this when adding a single account; to add several at once, use the Bulk Create Accounts tool (apollo_accounts_bulk_create). In Apollo terminology, an account is a company that your team has explicitly added to your database. Apollo does not apply deduplication processes when you create a new account via the API. If your entry has the same name, domain, or other details as an existing account, Apollo will create a new account instead of updating the existing account. Creating an account cannot be undone. To update an existing account, use the Update an Account endpoint instead. To set custom fields, first call the List Custom Fields tool (apollo_fields_index) and use the field whose modality is 'account', then pass typed_custom_fields keyed by the returned field IDs. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Update an Account endpoint to update existing accounts in your team's Apollo account. The values you send overwrite the account's current values, and that cannot be undone. In Apollo terminology, an account is a company that your team has explicitly added to your database. To create a new account, use the Create an Account endpoint instead. To set custom fields, first call the List Custom Fields tool (apollo_fields_index) and use the field whose modality is 'account', then pass typed_custom_fields keyed by the returned field IDs. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create many accounts (companies) in one call. Pass an array of account objects under accounts. No deduplication is applied by default: each object becomes a new account even if it matches one you already have. Set run_dedupe to true to skip entries that already exist; those come back under existing_accounts, unchanged. Pass run_dedupe at the top level, next to accounts — never inside an account object. Maximum 100 accounts per call. Entries are not compared against each other, so collapse repeated domains before sending. Creating an account cannot be undone. Use Update an Account to change one that already exists. To set custom fields, first call the List Custom Fields tool (apollo_fields_index) and use the field whose modality is 'account', then pass typed_custom_fields keyed by the returned field IDs on each account object. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Query Apollo's sales analytics data with flexible filtering, grouping, and aggregation. Supports metrics across emails, calls, meetings, tasks, opportunities, and conversation intelligence. Break down by 55+ dimensions including time, user, contact stage, account details, and more. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create a new contact in Apollo. Use this when adding a single contact; to add several at once, use the Bulk Create Contacts tool (apollo_contacts_bulk_create). Apollo automatically prevents duplicates: if an entry matches an existing contact by email or other details, that existing contact is updated instead of creating a new one. This action is destructive: when it matches an existing contact, the values you send overwrite that contact's current field values, and that overwrite cannot be undone. To set custom fields, first call the List Custom Fields tool (apollo_fields_index) and use the field whose modality is 'contact', then pass typed_custom_fields keyed by the returned field IDs. After a successful create, inspect the returned contact. When person_id or organization_id is null, tell the user the contact was saved from the details they provided but has not been matched to Apollo's canonical person and company data. This is not a failure, and it does not affect any saved Account. Offer to enrich the contact as the next step, unless the user asked not to enrich. Do not enrich automatically: if the user agrees, follow the confirmation rules of apollo_people_match before calling it, and never claim enrichment will create or attach an Account. When both person_id and organization_id are present, do not show this recommendation. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Update an existing contact in your team's Apollo account. In Apollo terminology, a contact is a person that your team has explicitly added to your database. A contact will have their data enriched in some way, such as accessing an email address or a phone number. This action is destructive: the values you send overwrite the contact's current field values, and that overwrite cannot be undone. Passing label_names replaces (does not append to) the contact's existing lists. To create a new contact, use the Create a Contact endpoint instead. To set custom fields, first call the List Custom Fields tool (apollo_fields_index) and use the field whose modality is 'contact', then pass typed_custom_fields keyed by the returned field IDs. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Search for Contacts endpoint to search for the contacts that have been added to your team's Apollo account. In Apollo terminology, a contact is a person that your team has explicitly added to your database. A contact will have their data enriched in some way, such as accessing an email address or a phone number. This endpoint only returns contacts in the search results. To search for people in the Apollo database, call the People API Search endpoint. To protect Apollo's performance for all users, this endpoint has a display limit of 50,000 records (100 records per page, up to 500 pages). Add more filters to narrow your search results as much as possible. This limitation does not restrict your access to Apollo's database; you just need to access the data in batches. Website-visitor filters reflect person-level visits from United States visitors only; non-US visits are not identified at the person level. Each contact in the response may include a website_visitor summary (last visit, total visits, and intent over the last 90 days) when your team tracks website visitors for that contact. This reflects US-located visitors only, since person-level website visitor tracking is US-only. It costs no additional credits and is omitted entirely when the team/user isn't entitled to website visitor data or no visit history exists. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create many contacts in a single call. Pass an array of contact objects under contacts. Apollo automatically prevents duplicates: any object that matches an existing contact by email or other details updates that existing contact instead of creating a new record. This action is destructive: for any object that matches an existing contact, the values you send overwrite that contact's current field values, and that overwrite cannot be undone. Send at most 100 contacts per call (Maximum 100, enforced by maxItems on contacts); split larger jobs into multiple calls. Contact creation is also subject to a per-team daily limit configured by your Apollo admin. Use the single Create Contact endpoint when adding only one contact; use Update Contact to modify an existing contact. Once created, contacts are not removed by subsequent calls — review the array before sending. To set custom fields, first call the List Custom Fields tool (apollo_fields_index) and use the field whose modality is 'contact', then pass typed_custom_fields keyed by the returned field IDs on each contact object. After a successful bulk create, inspect the returned contacts. For any contact whose person_id or organization_id is null, tell the user those records were saved from the details provided but were not matched to Apollo's canonical person and company data; summarize the affected count instead of asking once per contact. This is not a failure, and it does not affect any saved Account. Offer enrichment as the next step, unless the user asked not to enrich. Do not enrich automatically and do not start a per-contact match loop: if the user agrees, confirm the total scope and applicable credit disclosure using the exact confirmation rules of apollo_people_bulk_match; do not state a fixed total for waterfall enrichment, and never claim enrichment will create or attach an Account. When a contact already has both person_id and organization_id, do not flag it. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Fetch the team's full Context Center — the Ideal Customer Profile (ICP) and all product profiles Apollo uses to personalize AI-generated messaging. Returns the team's current Context Center, including drafts that have not yet been approved. ALWAYS call this first before editing the profile or a product, so you read the current values and send only what changes. Returns 404 if the team has no Context Center yet (in that case use apollo_context_center_create_profile to set one up). If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create the team's Context Center Ideal Customer Profile (ICP). The ICP is the single team-wide profile Apollo uses to personalize AI-generated outreach: who the team sells to, the company's value proposition, the pain points it solves, and its proof points. A Context Center has two parts: this ICP (one per team) and a set of product profiles (managed separately via apollo_context_center_create_product / apollo_context_center_update_product). This tool sets only the ICP. Use this when the team is setting up its Context Center. To edit an existing profile, use the Update tool (apollo_context_center_update_profile) instead. BEFORE calling: confirm the field values with the user — do not invent company positioning, value props, or competitors. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Update fields on the team's EXISTING Context Center Ideal Customer Profile (ICP). Each field you send REPLACES the prior value of that field; fields you omit are left unchanged. This requires a Context Center to already exist. If the team has no Context Center yet, use apollo_context_center_create_profile instead (it auto-creates one). This is the team's shared profile — an edit changes it for everyone on the team and overwrites prior content, so it is not reversible. BEFORE calling: read the current profile with apollo_context_center_show, confirm the new values with the user, and send only the fields you intend to change. Get explicit user confirmation before writing. AFTER calling: echo only the profile id and a short summary of which fields changed back to the user — do not paste the full payload. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Fetch a single product from the team's Context Center by its Apollo id. Use this to read a product's current details before editing or referencing it in messaging. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Add a product (or service) to the team's Context Center. Products describe specific offerings Apollo can reference when generating outreach. Each call creates a NEW product record — calling twice creates two products. To change an existing product, do not call this again; read it first with apollo_context_center_show_product and confirm with the user. BEFORE calling: confirm the product name and description with the user. Only product_or_service_name is required. AFTER calling: echo only the product id and name back to the user. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Update an existing product in the team's Context Center. Each field you send REPLACES the prior value of that field; fields you omit are left unchanged. BEFORE calling: read the product first (apollo_context_center_show_product or apollo_context_center_show) and confirm the new values with the user. AFTER calling: echo only the product id and a short summary of what changed back to the user. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Search conversations for the current team, sorted by start time descending. Use this tool to discover conversation IDs before calling get_transcript, get_insights, or get_recording_links. Returns a paginated list where each conversation includes: id, topic, start_time (ISO 8601), duration (seconds), state, host_id, participant_count, has_transcript, and source. If multiple conversations match, present topic, start_time, and source for each match and ask the user to confirm which conversation they mean before calling get_transcript, get_insights, or get_recording_links. Do not assume or pick one on their behalf. Filters available: user_id (host), state, date_range (start_time min/max), q_keywords (topic), source. Use source=phone_call to get only phone call recordings; source=meeting for video meeting recordings. Deleted and failed conversations are excluded regardless of filters. Pagination: use page (1-indexed, default 1) and per_page (default 20, max 50). Increment page while has_more is true to walk through all results. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Retrieve the transcript for a single conversation. The end user will not provide a conversation id directly. Call Search Conversations (apollo_conversations_search) first to find candidates, then pass the id from that search result. If multiple conversations match, present topic and start_time and ask the user to confirm which one before calling this tool. When exactly one conversation clearly matches, proceed without extra confirmation. Returns conversation metadata plus the transcript in the requested format. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Retrieve AI-generated insights for a single conversation. The end user will not provide a conversation id directly. Call Search Conversations (apollo_conversations_search) first to find candidates, then pass the id from that search result. If multiple conversations match, present topic and start_time and ask the user to confirm which one before calling this tool. When exactly one conversation clearly matches, proceed without extra confirmation. Only available once insights have been fully processed (state=insights_generated). Returns four sections: - summary: plaintext overview including outcome, pricing discussion, next steps, objections, and pain points - action_items: timestamped items identified during the conversation, with speaker attribution - questions: questions raised during the call, with speaker and timestamp - tracker_insights: topic tracker hits (e.g. competitor mentions, pricing triggers), with timestamp and spoken sentence If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Fetch temporary presigned recording links for a single conversation. The end user will not provide a conversation id directly. Call Search Conversations (apollo_conversations_search) first to find candidates, then pass the id from that search result. If multiple conversations match, present topic and start_time and ask the user to confirm which one before calling this tool. When exactly one conversation clearly matches, proceed without extra confirmation. Links expire when the underlying presigned URL signature expires (GCS enforces this). expires_at on each link is parsed from that signature — do not cache or reuse links past that time. Returns only playable media recordings (video, audio, active_speaker_view, shared_screen_view). Returns an empty links array when no recordings are available or accessible. Each link includes: type, url, and expires_at (ISO 8601). If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create a new deal (opportunity) in Apollo. A deal represents a potential sale tied to an account, with stage, amount, and close date. Only `name` is required; other fields are commonly set at creation time and can be left blank to take Apollo defaults. If the team has a connected CRM (Salesforce, HubSpot, etc.), the new deal is pushed to the CRM as part of creation. BEFORE calling this tool: 1. DEDUP — call apollo_deals_search to check for existing deals matching the same name (and account_id if known). If any are found, present them to the user and ask whether to proceed or skip. Do not create if the user says skip. 2. Wait for explicit user confirmation before calling this endpoint. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Search the deals (opportunities) in your team's Apollo account. Returns a paginated list of deals matching the supplied filters. All filters AND together; omit a filter to ignore it. Use page + per_page to walk results. Use this tool before creating a deal to check whether a similar opportunity already exists for the same account. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Retrieve a single deal (opportunity) by its Apollo ID, including full details (stage, amount, close date, owner, account, contact roles). Use Search Deals first if you do not already have the opportunity_id. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

List the domains the team has purchased through Apollo. Returns each domain's id, domain name, status, billing period, SPF/DKIM/DMARC diagnostics, and any mailboxes already provisioned on it. Call this to obtain a domain_purchase_id before purchasing a mailbox — a mailbox can only be provisioned on a domain the team already owns, and the mailbox email's domain must match the domain returned here. Never guess a domain_purchase_id; use only ids returned by this tool. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

List the team's Apollo-provisioned (purchased) mailboxes. Returns each mailbox's id, email, mailbox type (type_cd), provisioning status (status_cd: pending_setup | active | inactive), assigned user, forwarding email, and billing period. Use this to check the status of a purchased mailbox, or to see what mailboxes the team already owns. This lists PURCHASED mailboxes only — not mailboxes connected via OAuth (use the email accounts list for those). Optionally filter by domain_purchase_id to see mailboxes on one purchased domain. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Purchase one or more Apollo-provisioned outbound mailboxes against a domain the team already owns. THIS CONSUMES CREDITS and provisions real mailboxes — it is irreversible from this tool. No deduplication is applied — Apollo does not pre-check that the mailbox address is free; provisioning will fail if it is already in use. The mailbox is automatically owned by the authenticated user — do NOT ask for or look up any user/owner id, and do not call other tools to resolve one. CREDIT COST: Charged per mailbox, by mailbox type, when the mailbox is provisioned. Cost per mailbox (in unified credits): shared = 300, google = 800, outlook = 1500. Total cost = (cost per mailbox for the chosen type) × (number of mailboxes). All mailboxes in one request must share the same mailbox_type, so the total is always count × the per-type cost above. (Teams on legacy export credits are charged ~1/5 of these amounts; if unsure which applies, state the unified-credit number and note it may be lower on legacy plans.) MANDATORY CONFIRMATION — You MUST say this EXACT message to the user before calling this endpoint, filling in the real numbers: "Purchasing [N] [mailbox_type] mailbox(es) will consume [N × per-type cost] credits. Do you want to proceed?" Do NOT paraphrase. Do NOT say "consumes credits" — state the exact credit total number. Do NOT proactively show the remaining credit balance; only show it if the user asks. Do NOT call this endpoint without explicit user approval. Provisioning is asynchronous: newly created mailboxes start in status_cd "pending_setup" and become "active" once ready. The endpoint will reject the purchase if the team has insufficient credits. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Get a List of Email Accounts endpoint to retrieve information about the linked email inboxes that your teammates use in your Apollo account. In particular, this endpoint returns IDs for each of your team's linked email accounts, which can be used with the Add Contacts to a Sequence endpoint. The response includes a "default" field on each account — the account with default: true is the user's primary sending mailbox and should be auto-selected when adding contacts to sequences (unless the user explicitly requests a different one). Always call this endpoint before adding contacts to a sequence. Never guess or fabricate email account IDs — use only IDs returned by this endpoint. If the user's intended sender is ambiguous (e.g., multiple team members share a first name), present all matching email accounts to the user and ask them to select the correct one before proceeding. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Search for Sequences endpoint to search for the sequences that have been created for your team's Apollo account. This endpoint should be called before adding contacts to a sequence to retrieve the correct sequence ID. If multiple sequences match the search query, you must present all matching sequences to the user and ask them to confirm which one they intend before proceeding. Do not assume or pick one on their behalf. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Fetch a single sequence's full step-by-step detail: its ordered steps and, for each step, its touches (emailer_touches) and the email template content (subject and body). This is the same step/touch/email content the sequence page shows in the Apollo UI. Use it for two things: 1. Inspect what a sequence sends — "show me the emails/steps in this sequence". 2. Get the ids required to EDIT a sequence. Call this before apollo_sequences_update to obtain each step's id, each touch's id, each template's id, the step positions, and the sequence's current active value — all of which that tool's declarative-diff update needs to change, add, or remove specific steps/touches on an existing sequence. Find the sequence id first via apollo_emailer_campaigns_search. The response is large; when answering the user, summarize the steps and email content rather than pasting the full payload. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Add Contacts to a Sequence endpoint to add contacts to existing sequences in your team's Apollo account. This action sends real emails from a real person's mailbox and is irreversible once emails are dispatched. Before calling this endpoint, follow these steps in order: 1. Call the Search for Sequences endpoint to find the target sequence by name. If multiple sequences match, present all matches to the user and ask them to confirm which sequence they intend. Do not assume. 2. Call the Get a List of Email Accounts endpoint to retrieve valid sender email account IDs. Never guess or fabricate send_email_from_email_account_id — always use id(s) returned by Get a List of Email Accounts. Auto-select the mailbox where default is true — this mirrors the UI behavior where the user's default mailbox is pre-selected. If the user explicitly names a different mailbox or asks to change it, use that instead. If the user's request is ambiguous (e.g., "Sarah's account" matches multiple email accounts), list all matching options and ask the user to choose. Accepts one id as a string, or multiple ids as an array of strings (for multi-mailbox rotation). 3. Present the user with a confirmation summary that includes: the sender email address (from default or user selection), the sequence name, the number of contacts to be added, and the enrollment status (active or paused). Wait for the user to explicitly confirm before proceeding. Do not enroll contacts without explicit user approval, even if the user says "just do it" — always show the summary first. 4. Only after the user explicitly confirms, call this endpoint to enroll the contacts. In Apollo terminology, a contact is a person that your team has explicitly added to your database. Only contacts can be added to sequences. To enrich a person's data, call the People Enrichment endpoint. Then, to add the person as a contact in your database, call the Create a Contact endpoint. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Remove or stop contacts from one or more Apollo sequences. This action modifies live sequence enrollment state and may affect active outbound workflows. - remove: permanently removes the contact from the sequence. - stop: halts future sequence steps for the contact while preserving their stop context. BEFORE calling this tool: 1. Confirm the affected contact IDs — call apollo_contacts_search if unknown. 2. Confirm the sequence IDs — call apollo_emailer_campaigns_search if unknown. 3. Confirm the mode (remove or stop) explicitly with the user. The default is remove, which is permanent — do not assume remove when the user may intend stop. 4. If mode is stop, confirm the stop_reason with the user. Do not invent one. 5. Present a summary: affected contacts, sequence names, mode, and reason (if stop). 6. Wait for explicit user confirmation before proceeding. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Activate (turn on) an existing sequence so that contacts enrolled in it begin receiving emails and tasks. This is the toggle that flips active=false to active=true. THIS ACTION HAS REAL-WORLD CONSEQUENCES. Once active, Apollo will start sending emails from the user's mailbox on the configured schedule. Activation is irreversible for emails already dispatched. BEFORE calling this tool you MUST: 1. Confirm the user has reviewed the sequence's steps and message bodies (e.g. by surfacing a step-by-step summary). 2. Confirm the user has selected a sender email account (apollo_email_accounts_index) and added contacts (apollo_emailer_campaigns_add_contact_ids), if relevant. 3. Get explicit user confirmation in the same turn — do not assume prior consent. The sequence must have at least one step. The team must not have hit its sequence limit. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Return a single contact's sequence enrollment/engagement timeline — the same enrollment activity a user sees on the contact's Apollo timeline — as a time-ordered list of events: enrolled, paused (with reason where available), resumed, failed, completed/removed, and replied. Each event includes the event type, when it happened, and the sequence (and step) it relates to. Use this to answer "what happened with this contact in the sequence over time" — after finding the contact via apollo_contacts_search. Pass sequence_id to narrow the feed to one sequence. This is per-contact history; for a sequence's per-email metrics use apollo_emailer_messages_search. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Creates a draft email message for a contact. The draft is saved but NOT sent until you call apollo_emailer_messages_send_now. BEFORE calling this tool: 1. Call apollo_email_accounts_index to get the user's mailboxes. Note the id of the mailbox where default: true — you will need it for send_now. If the user explicitly names a different mailbox, note that id instead. 2. Present a confirmation summary to the user: - From: <mailbox email> (default mailbox) - To: <contact email> - Subject: "<subject line>" - Body preview (first 100 chars) Wait for explicit user confirmation before creating the draft. AFTER creating: - The response includes the emailer_message id. - Call apollo_emailer_messages_send_now with that id and the chosen email_account_id to schedule delivery. If the user has already confirmed everything and just wants the email sent in one step, do not pause again: call this tool to create the draft, then immediately call apollo_emailer_messages_send_now with the returned emailer_message id and the chosen mailbox. From the user's perspective this is a single "send now" action. The recipient defaults to the contact's email. You may optionally set or override the recipients (including non-contact addresses) by passing a recipients array, where each entry has an email and a recipient_type_cd of "to", "cc", or "bcc". Overriding recipients changes who receives the email but not the contact it is associated with. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Sends a drafted email immediately. The send_from parameter sets which mailbox sends the email. You MUST provide it with the email_account_id and the email address from apollo_email_accounts_index. Use the mailbox where default: true unless the user explicitly requests a different one. This tool completes the send in-process, so the response status is normally the FINAL result: - "completed" → the email was sent. - "failed" → the send was blocked or failed; the response includes not_sent_reason and a human-readable failure_reason (e.g. a permission or safeguard block). A "failed" response means the email was NOT delivered — surface the reason to the user and do NOT report success. If the send is deferred by mailbox rate limits or warmup pacing, the status will instead be "scheduled"/"delayed"; in that case confirm the final outcome by calling apollo_emailer_messages_email_send_status with the message id. THIS ACTION SENDS A REAL EMAIL from a real person's mailbox. Never call this without explicit user confirmation of the recipient, subject, and body. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Check the delivery status of an email after calling apollo_emailer_messages_send_now. Pass the emailer_message id from the send_now response. If status is "scheduled" or "drafted", the email is still being processed. Wait 10-20 seconds and poll again. Typical delivery completes within 5-30 seconds. Give up after 4 polling attempts (~40-60 seconds) and tell the user the email is queued — they can check Apollo later. Terminal statuses: - "completed" — email was delivered successfully. - "failed" — email failed to send. The response includes not_sent_reason and failure_reason with details (e.g. bounce, quota exceeded, spam block). If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Report on the emails of a sequence (emailer_campaign). Two ways to call it: 1. LIST / STATUS COUNTS — pass emailer_campaign_id with display_mode "metadata_mode" to get the per-status counts the Apollo UI shows (Total, Scheduled, Scheduled-Delayed, Sent, Delivered, Not Opened, Not Sent, plus Opened, Clicked, Replied, Bounced, Unsubscribed, Spam Blocked). Omit display_mode to get a page of the matching emailer message records instead. 2. DRILL-DOWN — pass ids (a batch of up to 10 emailer_message ids, e.g. from a previous list call) to get per-message engagement (opened, num_opens, last_opened_at, clicked, replied, bounced) plus the per-record event timeline (each open/click with timestamp, location, device). Every per-message record also reports the A/B variant that contact was actually sent, when the email belongs to a sequence step that is split-testing: a `variant` object with `touch_id`, `label` (A/B/C, matching the Apollo UI), and the variant's `subject`. Use it to attribute each contact's outcome to a specific variant — e.g. reply rate of Test A vs Test B recipients, or to list the contacts who received a particular variant. Non-sequence / one-off emails omit `variant`. This endpoint does NOT support filtering by contact_id — passing contact_id returns a validation error rather than silently ignoring it. To scope emails to a specific contact, tag the contact and filter by contact_label_ids, or pull by emailer_campaign_id / specific message ids and narrow client-side. Use emailer_message_stats to filter the list by one or more statuses. Use this tool for per-message / per-sequence email detail. For aggregate metrics over a date range across many sequences/users, use apollo_analytics_sync_report instead. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Fetch the content of one or more SENT emails by id — subject, body (plain text or raw HTML), recipients, sent time, and status. Pass an ids array (e.g. ids returned by apollo_emailer_messages_search) to read a batch in a single call — for example every sent email in a sequence — instead of calling this once per email. Use this after listing or drilling into a sequence's emails with apollo_emailer_messages_search, when you need to see what was actually written (e.g. which messaging drove a reply or an open). Returns the team's own sent emails only: customer replies, inbound messages, and drafts are not accessible and are omitted from results. Set body_format to "html" when the raw HTML body matters (links, structure); it defaults to plain text. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

List all sending schedules available in the user's team. A schedule defines the time windows (days of week, hours of day, time zone) during which Apollo will send emails for a sequence. Use this tool when the user wants to pick a non-default schedule for a new sequence (apollo_sequences_create accepts emailer_schedule_id). If the user does not specify a schedule preference, omit emailer_schedule_id when creating the sequence and Apollo will use the user's default. Returns an array of schedules, each with id, name, default flag, time_zone, and the per-day windows. Echo only id and name back to the user when presenting choices. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Call this tool to report when a previous Apollo tool returned an unexpected, empty, or unhelpful result — for example, when a search returned no results despite valid inputs, a record was not found when it should exist, or a tool response was ambiguous or unclear. Include the name of the tool that failed and a clear description of what went wrong. Do NOT call this for successful tool results or expected empty states (e.g. a deliberate empty search).

List your team's fields so you can set them on accounts or contacts. Use this BEFORE calling the Create/Update/Bulk Create tools for accounts or contacts whenever you need to set a custom field. Each field is returned with its `id`, `label`, `type`, `modality` ('account', 'contact', etc.), `source`, and — for picklist/multipicklist fields — its allowed options as `picklist_values: [{ "id": "...", "name": "..." }]`. The option `name` is what you send when setting a record's value; the option `id` is what you resend to apollo_fields_update when changing the field's option set (options resent without their existing id are deleted and recreated, orphaning stored record values). Narrow the results with the filters below; always pass `modality` matching the record you are working with so you only get back relevant fields: - `modality`: restrict to one record type ('contact', 'account', 'opportunity', ...). - `source`: 'custom' returns fields your team created (the default, and what you almost always want when setting custom values); 'system' returns Apollo's built-in standard fields (name, email, title, etc.). CRM mapping is NOT a source — every returned field carries its CRM mapping separately. - `limit`: cap the number of fields returned. Pass a field's `id` exactly as returned as the key in the `typed_custom_fields` object on the create/update tools, e.g. `typed_custom_fields: { "<id>": "<value>" }`. For picklist fields, send one of the allowed option NAMES (not ids); for multipicklist fields, send an array of names. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

List the Apollo lists (also called labels) that belong to your team. In Apollo terminology, a list is a named, saved group of records — most commonly a list of contacts or a list of accounts. Each returned list includes its id, name, modality (e.g. "contacts" or "accounts"), cached record count, and app_url — a canonical, shareable deep link that opens the list in the Apollo web app (format: https://app.apollo.io/#/lists/<list_id>). The same URL works for both contacts and accounts lists. Surface app_url to the user when they want to view or share a list. Call this first to discover existing lists and their ids before updating a list (apollo_labels_update) or adding/removing records (apollo_labels_add_entity_ids_to_label_names, apollo_labels_remove_entity_ids_from_label_names). If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create a new, empty Apollo list (label) for your team. In Apollo terminology, a list is a named, saved group of records. Supply the modality to choose whether this is a list of contacts or a list of accounts. List names must be unique per modality within your team; creating a list whose name already exists for that modality returns an error. To rename an existing list, use Update List (apollo_labels_update). To add records to a list use Add Records to Lists (apollo_labels_add_entity_ids_to_label_names) — that tool will also create the list on the fly if the supplied name does not yet exist. No deduplication is applied beyond the per-modality name-uniqueness check described above — a list with a new name is always created as a separate list, even if it duplicates the purpose of an existing one, so check apollo_labels_index first if you may be recreating an existing list. The response includes the new list's id and its app_url — a canonical, shareable deep link that opens the list in the Apollo web app (format: https://app.apollo.io/#/lists/<list_id>). Surface app_url to the user so they can jump straight to the list they just created. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Rename an existing Apollo list (label). Pass the list id and the new name. Use List Lists (apollo_labels_index) to discover the id of the list you want to rename. The new name must be unique per modality within your team; reusing an existing name for that modality returns an error. This tool only renames a list — it does not add or remove records (use apollo_labels_add_entity_ids_to_label_names / apollo_labels_remove_entity_ids_from_label_names) and it cannot delete a list. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Add one or more contacts or accounts to one or more Apollo lists. Identify the records by their Apollo ids (entity_ids) and the lists by name (label_names). The modality must match the kind of records and lists — use "contacts" when adding contacts and "accounts" when adding accounts. If a supplied list name does not exist yet for that modality it is created automatically, so this tool can both create-and-populate a list in a single call. Get contact ids from apollo_contacts_search and account ids from apollo_accounts_search. Adding a record that is already on a list is a no-op (no duplicates are created). The response echoes back the affected lists, each with its id and app_url — a canonical, shareable deep link that opens the list in the Apollo web app (format: https://app.apollo.io/#/lists/<list_id>). Surface app_url to the user so they can review the records they just added. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Remove one or more contacts or accounts from one or more Apollo lists. Identify the records by their Apollo ids (entity_ids) and the lists by name (label_names). Get entity ids from apollo_contacts_search or apollo_accounts_search, and list names from apollo_labels_index. The modality must match the kind of records and lists — use "contacts" for contacts and "accounts" for accounts. Removing records from a list is destructive: list membership is dropped immediately and the records stop appearing in any view, workflow, or automation scoped to that list. This only detaches the records from the named lists; it does NOT delete the records themselves and it does NOT delete the list. Removing a record that is not on a list is a no-op. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Searches Apollo's global company database (all companies Apollo indexes, not just your team's saved accounts). Use this tool for prospecting — there is no separate saved-accounts search tool. Use the Organization Search endpoint to find companies in the Apollo database. Several filters are available to help narrow your search. RESPONSE SHAPE — results come back in TWO buckets and their IDs are not interchangeable. `organizations` holds net-new companies, where the row's `id` is the Apollo organization ID. `accounts` holds companies your team has already saved, where the row's `id` is an ACCOUNT id and the organization ID is a separate `organization_id` field on the same row. Whenever you feed a company from this response into an organization-ID filter on another tool (for example `organization_ids` on apollo_mixed_people_api_search), use `id` for an `organizations` entry and `organization_id` for an `accounts` entry. No filter raises an error on a mis-passed account `id` and most will simply match nothing, so `organization_id` is the only value guaranteed to work. Note the two buckets also differ in domain fields: `accounts` entries carry `domain`, `organizations` entries carry `primary_domain`. To protect Apollo's performance for all users, this endpoint has a display limit of 50,000 records (100 records per page, up to 500 pages). Add more filters to narrow your search results as much as possible. DEFAULT FOR AGENTS: Use apollo_organizations_lookup (Organization Lookup) for free organization discovery. It supports fuzzy name lookup and discovery filters, returning shallow candidate records (id, name, domain, website_url, logo_url). Use this paid Organization Search tool only when the user explicitly asks for full organization details in search results. CREDIT COST: Exactly 1 credit per request that returns at least one result. 0 credits if there are no matches. Credits spent on a successful search cannot be undone. MANDATORY CONFIRMATION — You MUST say this EXACT message to the user before calling this endpoint. Do NOT paraphrase: "This will consume 1 credit. Do you want to proceed?" Do NOT proactively show remaining credit balance. Only show it if the user asks. Do NOT say "consumes credits" — say "1 credit". If this search is part of a larger batch, confirm the TOTAL count and credit cost upfront. Do NOT call this endpoint without explicit user approval. For roughly 20-30+ candidates headed for enrichment, decide this NOW, before enriching: create a record collection for them (apollo_custom_objects_create) and run enrichment there via apollo_fields_create + apollo_dynamic_field_enrichment_enrich. Do NOT loop apollo_organizations_bulk_enrich across batches and track results yourself in the conversation — that has no persistence, no resumability, and no direct export path. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Searches Apollo's global people database (all people Apollo indexes, not just your team's saved contacts). Use this tool for prospecting net new people; use apollo_contacts_search only when searching contacts already saved to your team's Apollo account. Use the People API Search endpoint to find people in the Apollo database. Several filters are available to help narrow your search. This endpoint is primarily designed for prospecting net new people. This endpoint does not return email addresses or phone numbers. Use the People Enrichment or Bulk People Enrichment endpoints to enrich data. Some contact fields, including last names, may be masked or partially obfuscated in search results depending on the user's plan type. When displaying masked values, always inform the user that enrichment is required to reveal the full value, and offer to run the People Enrichment endpoint. Get the id for each result from this endpoint and pass it to apollo_people_bulk_match when enriching search results. Do not wait for unobfuscated last names — masking in search results is expected and does not block enrichment. To protect Apollo's performance for all users, this endpoint has a display limit of 50,000 records (100 records per page, up to 500 pages). For roughly 20-30+ people headed for enrichment, decide this NOW, before enriching: create a record collection for them (apollo_custom_objects_create) and run enrichment there via apollo_fields_create + apollo_dynamic_field_enrichment_enrich. Do NOT loop apollo_people_bulk_match across batches and track results yourself in the conversation — that has no persistence, no resumability, and no direct export path. Add more filters to narrow your search results as much as possible. For teams with Website Visitors access, this search can filter people by visits to the caller's tracked domains. Call apollo_website_visitor_domain_tracker_index to retrieve valid tracked domains and configured intent paths; do not invent domain values. Search results identify people who matched the visitor criteria but do not include their website visitor activity. Person-level visitor identification currently only covers visitors browsing from the United States (company-level tracking is global), so results reflect US-located visitors only. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Default free organization discovery tool for MCP agents. Find organization candidates using a fuzzy company name (domains can be passed as q_organization_fuzzy_name) and/or discovery filters (employee range, locations, revenue, tech stack, funding, etc.). Returns shallow candidate records only: id, name, domain, website_url, and logo_url. Supports pagination via page and per_page. CREDIT COST: Free. This endpoint does not consume credits. Use apollo_organizations_enrich or apollo_organizations_bulk_enrich when the user explicitly asks for canonical or enriched company data (revenue, employee count, funding, phone numbers, etc.). Use apollo_mixed_companies_search only when the user explicitly asks for full organization details in search results (not just candidate lookup). For roughly 20-30+ candidates headed for enrichment, decide this NOW, before enriching: create a record collection for them (apollo_custom_objects_create) and run enrichment there via apollo_fields_create + apollo_dynamic_field_enrichment_enrich. Do NOT loop apollo_organizations_bulk_enrich across batches and track results yourself in the conversation — that has no persistence, no resumability, and no direct export path. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Organization Job Postings endpoint to retrieve the current job postings for a company. Find the organization `id` first with apollo_organizations_lookup — never guess it. This can help you identify companies that are growing headcount in areas that are strategically important for you. To protect Apollo's performance for all users, this endpoint has a display limit of 10,000 records. CREDIT COST: Exactly 1 credit per request. Credits spent on a request cannot be undone. MANDATORY CONFIRMATION — You MUST say this EXACT message to the user before calling this endpoint: "This will consume 1 credit. Do you want to proceed?" Do NOT proactively show remaining credit balance. Only show it if the user asks. Do NOT paraphrase. Do NOT say "consumes credits" — say "1 credit". If this is part of a larger batch, confirm the TOTAL count and credit cost upfront. Do NOT call this endpoint without explicit user approval. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Organization Enrichment endpoint to enrich data for 1 company. Enriched data potentially includes industry information, revenue, employee counts, funding round details, and corporate phone numbers and locations. CREDIT COST: Exactly 1 credit if found. 0 credits if not found. Credits spent on a successful match cannot be undone. MANDATORY CONFIRMATION — You MUST say this EXACT message to the user before calling this endpoint: "Enriching [domain] will consume 1 credit (no charge if not found). Do you want to proceed?" Do NOT proactively show remaining credit balance. Only show it if the user asks. Do NOT paraphrase. Do NOT say "consumes credits" — say "1 credit". If this is part of a larger batch, confirm the TOTAL count and credit cost upfront. Do NOT call this endpoint without explicit user approval. For teams with Website Visitors access, the response also includes website-visitor fields for the caller's own tracked domains: website_intent (low/medium/high), website_last_visit (date), website_unique_visitors, and website_total_visits. These fields are omitted for teams without Website Visitors access. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Bulk Organization Enrichment endpoint to enrich data for up to 10 companies with a single API call. Provide a list of domains to enrich. Enriched data potentially includes industry information, revenue, employee counts, funding round details, and corporate phone numbers and locations. CREDIT COST: Exactly 1 credit per matched company. 0 credits if not found. For N companies, maximum cost is N credits. Credits spent on successful matches cannot be undone. MANDATORY CONFIRMATION — You MUST say this EXACT message to the user before calling this endpoint: "This will enrich [N] companies and consume up to [N] credits (1 credit per match, no charge for unmatched). Do you want to proceed?" Do NOT paraphrase. Always state the exact count and exact credit cost. OPEN-ENDED / SEARCH-THEN-ENRICH: If enriching results from a prior search (e.g. "find and enrich SaaS companies"), you MUST: 1. Call the Profile endpoint with include_credit_usage=true to get the user's remaining credit balance. 2. Confirm the TOTAL scope UPFRONT with remaining balance: "Found [N] companies. Enriching all will use up to [N] credits. You have [X] credits remaining. Do you want to proceed?" Format the [X] credit balance with thousands separators (e.g. 28,045,653), not as a raw integer. 3. Do NOT start enriching in batches and confirm incrementally — confirm the full scope first. For "enrich everyone" or unbounded requests, ask the user to narrow scope or confirm total count before starting. Do NOT call this endpoint without explicit user approval. LARGER REQUIREMENTS: this endpoint caps at 10 domains per call. For roughly 20-30+ companies, or whenever the results need to be enriched further, exported, or referenced again later — do NOT just loop this call across batches and track results yourself in the conversation. Instead, seed a record collection with the companies (apollo_custom_objects_create's `records` param, or `apollo_data_sources_create` + `apollo_data_source_imports_create` for a finder-based import), then use `apollo_fields_create` + `apollo_dynamic_field_enrichment_enrich` to run enrichment there. This persists results, survives interruption, and exports directly via `apollo_csv_exports_export_view` — a conversation-tracked list does none of that. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the People Enrichment endpoint to enrich data for 1 person. Apollo relies on the information you pass via the endpoint's parameters to identify the correct person to enrich. If you provide more information about a person, Apollo is more likely to find a match within its database. By default, this endpoint does not return personal emails or phone numbers. Use the reveal_personal_emails parameter to retrieve personal emails. PREREQUISITE FOR ANY PHONE REVEAL OR WATERFALL (reveal_phone_number, run_waterfall_email, run_waterfall_phone): these are ASYNC and their result can ONLY be retrieved by polling the apollo_webhook_result_show tool. BEFORE setting any of those parameters to true, verify that apollo_webhook_result_show is present in your available tools. If apollo_webhook_result_show is NOT available, do NOT initiate the reveal or waterfall — it would consume credits for a result you cannot retrieve. Instead, tell the user their Apollo connection must be reconnected/re-authorized to enable phone reveal or waterfall enrichment, and ask them to reconnect (re-authenticate) Apollo before trying again. Phone enrichment is ASYNC. When reveal_phone_number=true, the response returns a top-level request_id immediately and the phone numbers are NOT in this response. Call apollo_webhook_result_show with that top-level request_id after ~10 seconds to poll for the enriched phone numbers. Use the top-level request_id, not any nested id. Waterfall enrichment is also ASYNC and poll-based. When run_waterfall_email and/or run_waterfall_phone is true, the response returns waterfall.status "accepted" and a top-level request_id with NO enriched data inline; poll apollo_webhook_result_show with that request_id (retry with backoff up to ~3 min). Waterfall credit cost is VARIABLE and plan-dependent: 0 credits when Apollo's own data satisfies it, otherwise partner-vendor credits that vary by the team's plan and can exceed a standard match — do NOT quote a fixed number for waterfall. WATERFALL BEHAVIOR (capability-gated, decided PER FIELD — email and phone independently): BEFORE offering or running ANY email or phone reveal — waterfall OR standard — call apollo_users_api_profile with include_waterfall_capability=true and read waterfall_email_enabled / waterfall_phone_enabled. This check is REQUIRED even when you intend to propose a standard reveal: you cannot know which path is the default until you have read these flags, so NEVER propose or run an enrichment path before checking. If you are calling apollo_users_api_profile for any other reason (for example include_credit_usage), set include_waterfall_capability=true on that same call. Capability is team-level — fetch it ONCE per conversation and reuse the result; do not call it again for later enrichments in the same conversation. - If waterfall is ENABLED for the requested field, waterfall IS THE DEFAULT reveal path for that field: give the waterfall confirmation below, then run it (set run_waterfall_email / run_waterfall_phone). - If waterfall is NOT enabled for the field and the user did NOT explicitly ask for waterfall: do NOT run waterfall. Use the standard reveal instead — reveal_phone_number for phone; for a missing work email, a standard match already returns the work email, so use reveal_personal_emails only for personal emails — with the standard confirmation, and do not mention waterfall. - If waterfall is NOT enabled and the user EXPLICITLY asked for waterfall (named "waterfall" or an unmistakable synonym — vague phrases like "try every source" or "dig deeper" do NOT count as explicit): do NOT silently fall back. Say exactly: "Waterfall isn't enabled on your account. You can turn it on in Apollo settings (an admin may need to do this). Want me to use the standard reveal for now instead?" Only run the standard reveal if the user accepts. - NEVER surface the raw backend error message or any internal identifier (such as a team id) from a failed waterfall call. If a waterfall call returns waterfall.status "failed", tell the user waterfall isn't set up for their account and offer the standard reveal instead — describe the failure generically and never repeat the backend message text verbatim. CREDIT COST: Exactly 1 credit per matched person. 0 credits if person is not found. Credits spent on a successful match cannot be undone. MANDATORY CONFIRMATION — You MUST say the appropriate EXACT message below before calling this endpoint. Do NOT paraphrase. When reveal_phone_number is false or omitted: "Enriching [name] will use 1 credit (no charge if not found). Do you want to proceed?" When reveal_phone_number=true (ONE combined confirmation — do not ask in two separate turns): "Enriching [name] will use 1 credit, plus additional credits if the phone number is successfully revealed (no charge if the number isn't found). Do you want to proceed?" Wait for explicit confirmation before revealing phone numbers. When run_waterfall_email=true or run_waterfall_phone=true (waterfall enrichment): "Enriching [name] with waterfall enrichment may use additional credits that vary by your plan and data provider and can be substantially more than a standard match (no charge if nothing is found). Do you want to proceed?" Do NOT state a specific credit number for waterfall unless a response in this conversation already carried a waterfall range in mcp_credits (see CREDIT TRANSPARENCY below) — otherwise the cost is plan-dependent and not available to this tool. Do NOT proactively show remaining credit balance, except from an mcp_credits block (see CREDIT TRANSPARENCY below). Otherwise only show it if the user asks about their balance. Do NOT paraphrase the match cost — say "1 credit", not "consumes credits". For the phone reveal, say "additional credits"; do NOT name a separate "direct-dial" or "enrichment" credit type, and do NOT state a specific per-number credit amount (it varies by plan and isn't available to this tool). Wait for explicit user confirmation before proceeding. If this is part of a larger batch, confirm the TOTAL upfront: "Enriching N contacts will cost up to N credits. Proceed?" Do NOT call this endpoint without explicit user approval. Do NOT enrich in a loop without upfront confirmation of full scope. CREDIT TRANSPARENCY (mcp_credits): On some teams, this tool's response includes an mcp_credits block: estimated (the pre-spend quote — the base per-contact cost plus priced add_ons; a waterfall add-on with status "expected" carries the live expected per-contact cost in per_contact/credits and a ceiling in max_per_contact/max), spent (pending until async work settles, then charged with the real amount), and balance_before/balance_after. When a response includes this block, ALWAYS present it to the user unprompted: the estimated cost per type, whether the spend is pending or already charged, and the remaining balance (thousands separators). Quote a waterfall range as "an estimated [expected] credits per contact, up to [max]" — these live numbers OVERRIDE the no-fixed-number rules above. Reuse the latest mcp_credits figures when confirming a follow-up enrichment in this conversation instead of calling the cost "variable". When the block is absent, follow the confirmation copy above unchanged. The response may include a website_visitor summary (last visit, total visits, and intent over the last 90 days) when the calling team tracks website visitors for this person. This reflects US-located visitors only, since person-level website visitor tracking is US-only. It costs no additional credits and is omitted entirely when the team/user isn't entitled to website visitor data or no visit history exists. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

For each person, provide identifying details such as first name, last name, email, organization name, domain, or LinkedIn URL. By default, this endpoint does not return personal emails or phone numbers. PREREQUISITE FOR ANY PHONE REVEAL OR WATERFALL (reveal_phone_number, run_waterfall_email, run_waterfall_phone): these are ASYNC and their result can ONLY be retrieved by polling the apollo_webhook_result_show tool. BEFORE setting any of those parameters to true, verify that apollo_webhook_result_show is present in your available tools. If apollo_webhook_result_show is NOT available, do NOT initiate the reveal or waterfall — it would consume credits for a result you cannot retrieve. Instead, tell the user their Apollo connection must be reconnected/re-authorized to enable phone reveal or waterfall enrichment, and ask them to reconnect (re-authenticate) Apollo before trying again. When reveal_phone_number=true, phone enrichment is ASYNC: the response returns a top-level request_id and NO phone numbers. Poll apollo_webhook_result_show with that top-level request_id (~10s, retry on 404) to retrieve the numbers. Waterfall enrichment is also ASYNC and poll-based. When run_waterfall_email and/or run_waterfall_phone is true, the response returns waterfall.status "accepted" and ONE top-level request_id for the whole batch with NO enriched data inline; poll apollo_webhook_result_show with that request_id (retry with backoff up to ~3 min). Waterfall credit cost is VARIABLE per person and plan-dependent: 0 when Apollo's own data satisfies it, otherwise partner-vendor credits that vary by the team's plan and can exceed a standard match — do NOT quote a fixed number for waterfall. WATERFALL BEHAVIOR (capability-gated, decided PER FIELD — email and phone independently): BEFORE offering or running ANY email or phone reveal — waterfall OR standard — call apollo_users_api_profile with include_waterfall_capability=true and read waterfall_email_enabled / waterfall_phone_enabled. This check is REQUIRED even when you intend to propose a standard reveal: you cannot know which path is the default until you have read these flags, so NEVER propose or run an enrichment path before checking. If you are calling apollo_users_api_profile for any other reason (for example include_credit_usage), set include_waterfall_capability=true on that same call. Capability is team-level — fetch it ONCE per conversation and reuse the result; do not call it again for later enrichments in the same conversation. - If waterfall is ENABLED for the requested field, waterfall IS THE DEFAULT reveal path for that field: give the waterfall confirmation below, then run it (set run_waterfall_email / run_waterfall_phone) for the whole batch. - If waterfall is NOT enabled for the field and the user did NOT explicitly ask for waterfall: do NOT run waterfall. Use the standard reveal instead — reveal_phone_number for phone; for missing work emails, a standard match already returns the work email, so use reveal_personal_emails only for personal emails — with the standard confirmation, and do not mention waterfall. - If waterfall is NOT enabled and the user EXPLICITLY asked for waterfall (named "waterfall" or an unmistakable synonym — vague phrases like "try every source" or "dig deeper" do NOT count as explicit): do NOT silently fall back. Say exactly: "Waterfall isn't enabled on your account. You can turn it on in Apollo settings (an admin may need to do this). Want me to use the standard reveal for now instead?" Only run the standard reveal if the user accepts. - NEVER surface the raw backend error message or any internal identifier (such as a team id) from a failed waterfall call. If a waterfall call returns waterfall.status "failed", tell the user waterfall isn't set up for their account and offer the standard reveal instead — describe the failure generically and never repeat the backend message text verbatim. CREDIT COST: Exactly 1 credit per matched person. 0 credits if not found. For N people, maximum cost is N credits. Credits spent on successful matches cannot be undone. MANDATORY CONFIRMATION — You MUST say ONE of these EXACT messages to the user before calling this endpoint. Do NOT paraphrase. Always state the exact count and exact credit cost. When reveal_phone_number is false or omitted: "This will enrich [N] people and consume up to [N] credits (1 credit per match, no charge for unmatched). Do you want to proceed?" When reveal_phone_number=true: "This will enrich [N] people and use up to [N] credits (1 credit per match, no charge for unmatched), plus additional credits for each phone number successfully revealed (no charge if a number isn't found). Do you want to proceed?" A single combined confirmation is required when reveal_phone_number=true — do NOT ask for enrichment and phone-reveal approval in two separate turns. When run_waterfall_email=true or run_waterfall_phone=true (waterfall enrichment): "This will enrich [N] people with waterfall enrichment, which may use additional credits that vary by your plan and data provider and can be substantially more than a standard match (no charge for people where nothing is found). Do you want to proceed?" Do NOT state a specific credit number for waterfall unless a response in this conversation already carried a waterfall range in mcp_credits (see CREDIT TRANSPARENCY below) — otherwise the cost is plan-dependent and not available to this tool. OPEN-ENDED / SEARCH-THEN-ENRICH: If enriching results from a prior search (e.g. "find and enrich SaaS contacts"), you MUST: 1. If a person id is available, pass only the id returned by apollo_mixed_people_api_search for each person in each details entry. Do not use first_name, last_name, or last_name_obfuscated from search results. 2. Call the Profile endpoint with include_credit_usage=true to get the user's remaining credit balance. 3. Confirm the TOTAL scope UPFRONT with remaining balance. When reveal_phone_number is false or omitted: "Found [N] contacts. Enriching all will use up to [N] credits. You have [X] credits remaining. Do you want to proceed?" When reveal_phone_number=true: "Found [N] contacts. Enriching all will use up to [N] credits, plus additional credits for each phone number successfully revealed (no charge if a number isn't found). You have [X] credits remaining. Do you want to proceed?" When running waterfall (run_waterfall_email and/or run_waterfall_phone): "Found [N] contacts. Enriching all with waterfall enrichment may use additional credits that vary by your plan and data provider and can be substantially more than a standard match (no charge for people where nothing is found). You have [X] credits remaining. Do you want to proceed?" Do NOT state a fixed total for waterfall unless a response in this conversation already carried a waterfall range in mcp_credits (see CREDIT TRANSPARENCY below). Format the [X] credit balance with thousands separators (e.g. 28,045,653), not as a raw integer. 4. Do NOT start enriching in batches and confirm incrementally — confirm the full scope first. For "enrich everyone" or unbounded requests, ask the user to narrow scope or confirm total count before starting. Do NOT call this endpoint without explicit user approval. CREDIT TRANSPARENCY (mcp_credits): On some teams, this tool's response includes an mcp_credits block: estimated (the pre-spend quote — the base per-contact cost times the batch size, plus priced add_ons; a waterfall add-on with status "expected" carries the live expected per-contact cost in per_contact and the batch total in credits, with ceilings in max_per_contact/max), spent (pending until async work settles, then charged with the real amount), and balance_before/balance_after. When a response includes this block, ALWAYS present it to the user unprompted: the estimated cost per type, whether the spend is pending or already charged, and the remaining balance (thousands separators). Quote a waterfall range as "an estimated [expected] credits per contact ([credits] total for [N] people), up to [max]" — these live numbers OVERRIDE the no-fixed-number rules above. Reuse the latest mcp_credits figures when confirming a follow-up enrichment in this conversation instead of calling the cost "variable". When the block is absent, follow the confirmation copy above unchanged. LARGER REQUIREMENTS: this endpoint caps at 10 people per call (see `details` below). For roughly 20-30+ people, or whenever the results need to be enriched further, exported, or referenced again later — do NOT just loop this call across batches and track results yourself in the conversation. Instead, seed a record collection with the people (apollo_custom_objects_create's `records` param, or `apollo_data_sources_create` + `apollo_data_source_imports_create` for a finder-based import), then use `apollo_fields_create` + `apollo_dynamic_field_enrichment_enrich` to run enrichment there. This persists results, survives interruption, and exports directly via `apollo_csv_exports_export_view` — a conversation-tracked list does none of that. Each match in the response may include a website_visitor summary (last visit, total visits, and intent over the last 90 days) when the calling team tracks website visitors for that person. This reflects US-located visitors only, since person-level website visitor tracking is US-only. It costs no additional credits and is omitted entirely when the team/user isn't entitled to website visitor data or no visit history exists. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Log a phone-call record in Apollo. Use this to record outbound/inbound dialer activity tied to a contact and (optionally) an account or opportunity. If `call_identifier` is provided and a call with that identifier already exists, the existing record is updated in place — otherwise a new record is created. To explicitly modify an existing call by Apollo ID, use Update Phone Call instead. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Search phone-call records in your team's Apollo account. Returns a paginated list of calls matching the supplied filters. All filters AND together; omit a filter to ignore it. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Update an existing phone-call record (e.g. to attach a note, outcome, or quality feedback). If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create a new multi-step outreach sequence (also called an emailer campaign) in the user's Apollo workspace. A sequence has a name, an optional sending schedule, and an ordered list of steps. Each step is one of: auto_email (Apollo sends automatically), manual_email (rep clicks send), call, action_item, linkedin_step_connect, linkedin_step_message, linkedin_step_view_profile, linkedin_step_interact_post. BEFORE calling this tool: 1. Confirm with the user the sequence name, target audience, goal of the outreach, channel mix, and tone (Direct | Formal | Casual). Do not invent these. 2. Call apollo_emailer_campaigns_search with q_name set to the proposed name to avoid creating a duplicate. If a similarly-named sequence exists, surface it and ask before proceeding. 3. If the user wants a non-default sending schedule, call apollo_emailer_schedules_index and present matches. Otherwise omit emailer_schedule_id; the user's default will be applied. DEFAULTS this tool will use unless the user says otherwise (Apollo best practices): - active: false. Always create inactive. The user must explicitly confirm before activation. - permissions: "team_can_use". - 4-6 steps. Default escalation: auto_email -> auto_email -> linkedin_step_view_profile -> linkedin_step_message -> call. - 3-day intervals between email steps (wait_time: 3, wait_mode: "day"). First step wait_time: 0. - Email body length: 25-85 words. <= 50 words is recommended for cold outreach (correlates with +23% reply rate). - Subject line: <= 9 words; concrete; no clickbait. - At most 3 A/B variants per step (additional emailer_touches in the same step). PER-CONTACT CUSTOMIZED BODIES (a fully personalized, individually-written email per contact): To give each enrolled contact a completely different, hand-tailored email body — not just token-merge of {{first_name}}/{{company}}, but a distinct message per person — deliver that body through the sequence using a CONTACT custom field as a merge variable: 1. Ensure a long-text / multi-line CONTACT custom field exists to hold the body, e.g. "custom_email_body_seq_1". Find it with apollo_fields_index (use the field whose modality is 'contact') and note BOTH its name and its id. The field itself is created once in the Apollo UI — there is no MCP tool to create custom fields. If no suitable field exists, tell the user to create one in Apollo first; do not invent a field id. 2. In that step's emailer_template, set body_html to reference the field by its NAME as a merge variable, e.g. "{{custom_email_body_seq_1}}" (optionally wrapped with fixed framing and a signature). Use a separate field per step if different steps need different custom bodies (custom_email_body_seq_1, custom_email_body_seq_2, ...). 3. Write each contact's unique body INTO that custom field via apollo_contacts_update or apollo_contacts_bulk_create — typed_custom_fields keyed by the field id — BEFORE enrolling them. 4. Enroll the contacts with apollo_emailer_campaigns_add_contact_ids. At send, Apollo resolves the merge variable to each contact's own stored value, so every contact receives their individually-written email while the sequence still handles cadence, scheduling, mailbox rotation, tracking, and auto-pause-on-reply. AFTER creation: - The response will be large (full sequence with steps and touches). Echo only the sequence id, name, and a short step summary back to the user — do not paste the full payload. - To activate the sequence, call apollo_emailer_campaigns_approve with the sequence id ONLY after the user explicitly confirms sender email account, schedule, and step content. Activation will eventually send real emails from a real mailbox; never activate without explicit user approval. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Update an existing sequence's metadata, schedule, steps, touches, and templates in a single call. DECLARATIVE DIFF SEMANTICS — the emailer_steps array you send is the FULL intended state of the sequence after this call: - A step with an `id` that matches an existing step → that step is UPDATED in place. - A step without an `id` → a NEW step is CREATED. - An existing step whose `id` is NOT in your payload → that step is DELETED. - The same rules apply per-touch within each step (touch.id present = update, absent = create, missing existing = delete). - `position` is required on every step and must form a complete 1..N sequence in the order you intend. BEFORE calling this tool: 1. Fetch the current sequence state — either from the apollo_sequences_create response earlier in this conversation, or by calling apollo_emailer_campaigns_search. You need each step's `id`, each touch's `id`, AND the current `active` value. If you don't have all three in context, call apollo_emailer_campaigns_search first. 2. Show the user a clear before/after summary including which steps will be added, updated, removed, or reordered. Get explicit confirmation before calling. 3. If the sequence is currently `active` and the user has contacts enrolled, warn them that step changes can affect contacts mid-sequence. 4. LABEL SAFETY — label_names is a full replacement, not an append. - The search response returns label_ids, not names. Before updating labels, call apollo_labels_index to resolve existing label_ids to their names. - To ADD a label: read the current label_names from the search response, then pass the existing array plus the new label. Example: current ["vip"], adding "q3" → pass label_names: ["vip", "q3"] - To REMOVE a label: pass the existing array minus the label to remove. Example: current ["vip", "q3"], removing "q3" → pass label_names: ["vip"] Never pass only the new label — that erases all others. EXAMPLES: - Edit step 2's body only: pass all existing steps with their ids; only step 2's template body_html differs. - Add a LinkedIn step at position 3: send existing steps 1, 2 unchanged, then a new step (no id) at position 3, then existing steps shifted to positions 4, 5, ... - Delete a step: omit it from the payload; positions of the remaining steps must reflow as 1..N. PER-CONTACT CUSTOMIZED BODIES: to make (or keep) a step deliver a fully per-contact, individually-written body, set that step's emailer_template.body_html to a CONTACT custom field merge variable referenced by NAME (e.g. "{{custom_email_body_seq_1}}"), and write each contact's body into that field via apollo_contacts_update before enrollment. See the same note on apollo_sequences_create for the full flow. The field is created in the Apollo UI (no MCP tool creates custom fields). The response is large (full sequence with steps and touches). Echo only the sequence id and a short before/after step summary back to the user. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create a single task in Apollo. A task is an action item (call, email, LinkedIn step, generic action_item) assigned to a user and tied to a contact, account, or opportunity. REQUIRED: in addition to user_id and type, you MUST provide at least one of contact_id, account_id, or opportunity_id. Calls without any association will fail. Use Bulk Create Tasks when creating more than one task at a time. If the team has a connected CRM, the task may be pushed to the CRM as part of creation. BEFORE calling this tool: 1. DEDUP — call apollo_tasks_search to check for existing open tasks matching the same (contact_id/account_id, type). If any are found, present them to the user and ask whether to proceed or skip. Do not create if the user says skip. 2. Wait for explicit user confirmation before calling this endpoint. ID RESOLUTION: To resolve a company or account name to an account_id, use apollo_mixed_companies_search and take the id field from its results. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Create many tasks in a single call. Pass an array of task attribute objects under tasks_attributes. Each object accepts the same fields as the single Create Task endpoint. REQUIRED: in addition to user_id and type, each task MUST provide at least one of contact_id, account_id, or opportunity_id. Tasks without any association will fail. Use the single Create Task endpoint when creating only one task. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Search the tasks in your team's Apollo account. Returns a paginated list of tasks matching the supplied filters. All filters AND together; omit a filter to ignore it. With no task_status filter this returns only scheduled (open / still-to-do) tasks — i.e. the team's due tasks. Sort by due date with sort_by_field=due_at (sort_ascending=true for soonest-first). Use this tool before creating tasks when checking for duplicates, reviewing existing work, or finding task IDs by assignee, contact, account, or opportunity. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Fetch the full detail of a single task by ID, including the action to perform (e.g. the LinkedIn message body or call script), the associated contact, and — for tasks that belong to a sequence — the sequence name and step position. For an email step, the response also includes an `emailer_message` object with the subject and body of the email the task will send — so you can preview the exact email in this one call, even for a task that has not been sent yet (no need to chain Search Emails / Get Email Content, which only return already-sent messages). Call this before completing or skipping a task to see what it asks you to do. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Mark a single task as completed. For a task that belongs to a sequence, completing it advances the contact to the next step of that sequence. Complete a task only after the real-world action it describes (sending the LinkedIn message, placing the call, etc.) has actually been performed. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Edit an existing task in place — change its title, note, priority, due date, assignee, or the message body (subject / body_text) for email and LinkedIn-step tasks. Use this instead of skipping and recreating a task. Only scheduled (open) tasks can be edited fully. For a task that is already completed or skipped only note, priority, and contact_id are applied; all other fields are ignored. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Skip a single task without performing it. For a task that belongs to a sequence, skipping it moves the contact past this step. Tasks controlled by a workflow approval cannot be skipped. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Retrieve credit usage stats for the authenticated team — credits used, remaining, and reset windows for enrichment/people-search/email-reveal credits. Takes no input — scoped to the authenticated team automatically. For a single user's credit balance, use the Profile endpoint with include_credit_usage=true. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Use the Profile endpoint to get the user's profile information (name, email, title, id) Set include_credit_usage to true to include credit usage information in the response. Credit Usage includes information like remaining credits, credits used etc. Use this endpoint when the user asks about their remaining credits or credit usage. Set include_waterfall_capability to true to learn whether the team has waterfall email and/or phone enrichment enabled. Check this before offering or running waterfall enrichment, so you know whether to default to waterfall or fall back to native reveal for each field. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

List or search the users (teammates) in your team's Apollo account. Useful when you need a user's Apollo ID to set as owner/assignee on another resource (deal owner_id, task user_id, account/contact owner_id). For the authenticated user's own profile, use the Profile endpoint instead. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Poll for the result of an asynchronous enrichment request: either a phone-number reveal started by apollo_people_match or apollo_people_bulk_match with reveal_phone_number=true, or a WATERFALL enrichment (email and/or phone) started by apollo_people_match or apollo_people_bulk_match with run_waterfall_email=true and/or run_waterfall_phone=true. Pass the top-level request_id returned by that enrichment call (not any nested id). POLLING (default assumption is KEEP POLLING): A not-yet-ready result comes back as a 404 with error_code: "result_pending", carrying a retry_after_seconds value. Wait retry_after_seconds and poll again. How long to keep polling depends on which kind of request you started: - STANDARD phone reveal (reveal_phone_number=true, no waterfall): give up after ~5 attempts (roughly 50 seconds total), then use the "still processing" message below. - WATERFALL (run_waterfall_email and/or run_waterfall_phone): back off and keep polling for up to ~3 minutes before giving up — waterfall enrichment can legitimately take much longer than a standard phone reveal. Bulk requests (apollo_people_bulk_match) take longer than single requests (apollo_people_match) for either kind, so lean toward the longer end of whichever ceiling applies. TERMINAL RESPONSES — do NOT retry these, regardless of any retry_after_seconds hint: - 200 with status: success — result is ready. For phone results (reveal or waterfall phone), phone numbers are grouped by type (mobile_phone, direct_phone, corporate_phone, home_phone, other_phone). For waterfall email results, the result also carries an emails field per person (see EMAIL RESULTS below). Results are available for 30 days. - 200 with status: failed — enrichment failed on Apollo's side. Tell the user: "Apollo attempted this enrichment but it failed. No credits were charged." For a standard phone reveal you can be more specific: "Apollo attempted to reveal the phone number but the enrichment failed. No credits were charged for the reveal." For a waterfall request: "Apollo attempted to run waterfall enrichment but it failed. No credits were charged." - 404 with error_code: "request_id_unknown" — the request_id was never issued, or was mistyped. This is distinct from a pending result: do NOT retry. Tell the user: "That request ID isn't recognized by Apollo. This usually means the ID was mistyped or was never issued. Please double-check the request ID or start a fresh enrichment request." Do NOT tell the user to try again later for this case. - 410 with error_code: "request_id_expired" — the request_id was valid but its result has aged out past the 30-day retention window. Do NOT retry. Tell the user: "That result is no longer available — results expire 30 days after the request. Please start a fresh enrichment request to get an up-to-date result." Do NOT tell the user to try again later for this case. - 400 with error_code: "invalid_request_id" — request_id was malformed. Tell the user the ID is invalid and to pass the top-level request_id from a fresh match/bulk_match call. - Pending 404, retries exhausted (~5 attempts for a standard reveal, ~3 minutes for waterfall) — the job is still processing on Apollo's side. Tell the user: "This enrichment is still processing and hasn't returned yet from this tool. Credits are only charged for what Apollo successfully finds, so if the job later completes you'll be charged only for what was found. To view the result once it's ready, open Apollo (app.apollo.io) and search for the contact by name." When the person's first_name/last_name are known from the enrichment, name the contact explicitly (e.g. "search for Jane Smith in Apollo"). Do NOT say the reveal or enrichment "failed" or "could not be retrieved" in this case — it timed out from the poll's perspective, not from Apollo's, and the job may still succeed. CREDIT TRANSPARENCY (mcp_credits): On some teams a settled poll result includes an mcp_credits block: spent (the credits actually charged for the async work) and balance_before/balance_after. When present, ALWAYS report it to the user unprompted, e.g. "This enrichment used [spent.credits] credits. You now have [balance_after] credits available." (thousands separators). Do not wait to be asked about cost or balance. NO-NUMBER-ON-FILE (success with empty phone arrays): When status is success but every phone_type array is empty, tell the user Apollo doesn't have a phone number on file for this contact. Only add "No credits were charged" when the result's top-level credits_consumed is 0 (or absent/zero). For a combined email-and-phone waterfall request, the other field may have succeeded and consumed credits — in that case do NOT say "No credits were charged"; just report that no phone number was found. EMAIL RESULTS (waterfall email enrichment, run_waterfall_email): When a waterfall email result completes successfully, each person carries an emails array. Each entry has: email (the address), email_status_cd (deliverability, e.g. "verified" / "extrapolated" / "unavailable"), email_source_cd, position (lower = higher priority), extrapolated_email_confidence, and vendor_validation_statuses (an array of the per-vendor validation results from the waterfall cascade). Present the email address(es) from the email field only — never fabricate or reformat the address. If a person has more than one entry, present all of them, highest-priority (lowest position) first; do not silently pick one. Surface email_status_cd alongside each address so the user knows how reliable it is. Each vendor_validation_statuses entry has third_party_validator_name (the vendor that validated, may be blank if unresolved), third_party_validator_id, raw_status, and timestamp. raw_status is that vendor's OWN status string and is NOT normalized across vendors — email_status_cd is the normalized deliverability to rely on; treat raw_status only as supplementary vendor detail and do not equate values across vendors. NO-EMAIL-FOUND (success with an empty emails field): When status is success but the emails field for a person is empty, tell the user Apollo didn't find an email address on file for this contact. Only add "No credits were charged" when the result's top-level credits_consumed is 0 (or absent/zero). For a combined email-and-phone waterfall request, the other field may have succeeded and consumed credits — in that case do NOT say "No credits were charged"; just report that no email address was found. DNC (DO NOT CALL) HANDLING — MANDATORY: Each returned phone number carries a dnc_status_cd, one of: "found", "not_found", "pending". Only "found" means the number is on a Do Not Call registry. When ANY returned number has dnc_status_cd: "found", you MUST surface a Do Not Call warning prominently alongside that number — immediately before or on the same line as the number, never in a footnote or buried in a table cell. Use wording consistent with this (do NOT cite specific statutes beyond the TCPA, and do NOT invent penalty amounts): "⚠️ Do Not Call — this number is listed on a Do Not Call registry. Check applicable telemarketing regulations before dialing; this may implicate the TCPA and other applicable regulations. Consider removing it from active dialing sequences and do not call this number unless you have a separate legal basis." Then present the number itself with a short "(Do Not Call)" marker (do not restate the digits inside this description — use the actual sanitized_number from the response). If multiple returned numbers are flagged, use one combined warning followed by a per-number list, each flagged number carrying a "(Do Not Call)" marker inline. Never omit the warning and never downgrade it to a footnote. When dnc_status_cd is "not_found", "pending", or absent, do NOT assert the number is DNC-listed — "pending" means screening is still in progress, not that the number is clear. ANTI-FABRICATION: NEVER fabricate, guess, or substitute a phone number OR an email address from training data, web knowledge, or any non-Apollo source. Only report phone numbers and email addresses present in this response. Do NOT offer a company switchboard, main line, guessed/pattern-generated email address, or any other stand-in when a reveal or waterfall enrichment doesn't yield a number or email. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Retrieve the website visitor domain tracker configuration for the team. Returns the tracker id, team id, the list of active allowed referrer domains (with tracking status, contact-level tracking settings, and intent paths), the maximum domain limit for the team, and whether visitor credits are exhausted. The tracker is team-scoped — one tracker per team. If no tracker exists yet, this call creates an empty one automatically (find-or-create) and returns its id. ALWAYS call this tool first — before update or any domain changes — to obtain the tracker id and referrer `_id` values. Never guess ids; only use values returned by this tool. Requires the team to have the `can_access_website_visitors` product feature and the calling user to have the `can_manage_website_visitors` permission. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Return the ready-to-embed Apollo website visitor tracking snippet for the team, with the team's tracker id already substituted in — so callers never hand-assemble the template or guess the loader url. Also returns `placement_rules` (what a correct install must satisfy). ALWAYS call this tool to obtain the snippet — never hand-assemble the template or substitute the appId yourself. This tool reads the team's tracker directly and returns its id as `app_id`, so you do NOT need to call the index tool first. If the team has no tracker yet, it returns a not-found error (it does not create one). The snippet is team-scoped: one script works across ALL of the team's tracked domains. Adding a domain (via the update tool) is what enables visitor attribution for that domain — the script alone does not register a domain. So a typical flow is: add the domain, get this script, embed it, and deploy. Use the returned `placement_rules` to place the snippet correctly in the site's code — they are framework-agnostic requirements to satisfy, not per-framework instructions. When answering the user, summarize in plain language. Do not discuss internal configuration such as person-level visitor identification. Requires the team to have website visitors product access and the calling user to have permission to manage website visitors. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Add, edit, or delete a domain in the team's website visitor domain tracker. The `action` field inside `domain_data` controls which operation is performed: - "add": Register a new domain for visitor tracking. `domain` and `_id` are required — generate a new UUID (e.g. via `SecureRandom.uuid`) and pass it as `_id`; the backend uses it as the referrer's identifier. If the team's domain limit is already reached, the call returns an error with `limit_exceeded: true`, the current domain count, the maximum allowed, and whether the team has the Inbound add-on (which raises the limit). - "edit": Update an existing tracked domain's hostname, contact-level tracking flag, or intent paths. `_id` (the referrer's Apollo id) is required. Always include `domain` as well — use the current hostname from index even if you are not changing it. - "delete": Soft-delete a domain from the tracker. `_id` is required. The domain stops receiving visitor data but its history is preserved. BEFORE calling this tool: 1. Call apollo_website_visitor_domain_tracker_index to get the tracker id, `domain_limit`, and `_id` values for existing referrers. 2. For "add": generate a fresh UUID for `_id` and check `domain_limit` — warn the user if they are at or near their limit. 3. For "edit" and "delete": use the exact `_id` from index — never guess or reuse ids from prior sessions. For "edit", always pass `domain` too (even if unchanged). Requires the team to have the `can_access_website_visitors` product feature and the calling user to have the `can_manage_website_visitors` permission. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Email the Apollo website visitor tracking JavaScript snippet to one or more recipients. Typically used to send the script to a developer who will install it on the team's website. Returns `success: true` and `sent_count` when all emails are delivered. On partial failure, returns the successful `sent_count` alongside a `failed_recipients` list. Rate limited to 10 sends per hour per user — exceeding this returns a 429 error. BEFORE calling this tool: 1. Confirm recipient email addresses and the subject line with the user. 2. Generate the `script` parameter using the steps below — do not ask the user for script content and do not invent a custom snippet. How to generate the `script` parameter: 1. Call apollo_website_visitor_domain_tracker_index (creates a tracker if needed). 2. Copy the tracker `id` from the response. This is the only value that varies per team. Use that exact string — never an example or guessed id. 3. Start from the exact template below. Replace `<TRACKER_ID>` with that `id`. 4. Do not change the loader URL, function names, or structure — only substitute the id. 5. Pass the resulting string as the `script` argument (max 4000 characters). Script template — replace `<TRACKER_ID>` with the `id` from index: <script>function initApollo(){var n=Math.random().toString(36).substring(7),o=document.createElement("script");o.src="https://assets.apollo.io/micro/website-tracker/tracker.iife.js?nocache="+n,o.async=!0,o.defer=!0,o.onload=function(){window.trackingFunctions.onLoad({appId:"<TRACKER_ID>"})},document.head.appendChild(o)}initApollo();</script> The `appId` value inside the snippet must match the tracker `id` from index exactly. Requires the team to have the `can_access_website_visitors` product feature and the calling user to have the `can_manage_website_visitors` permission. If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.

Returns visit counts, unique-visitor counts, and top visited paths for a single visiting company on one of your team's tracked websites, over a date range. Two keys with different meanings: - `organization_id` = the visiting company you want a report on. Get it from apollo_organizations_enrich (organization.id). Never fabricate it. - `domain` = one of YOUR team's tracked websites (where Apollo's tracking pixel is installed), NOT the visiting company's domain. Discover valid values via apollo_website_visitor_domain_tracker_index. Only returns data for companies that actually visited your tracked site; a company with no visits returns "stats not found". If this tool returns an unexpected, empty, or unhelpful result, call `apollo_feedback_log` to report it.