# Emailchaser (remote · app.emailchaser.com) Run cold email outbound from an AI agent: campaigns, leads, replies, sender accounts, autopilot. - Trust score: 85/100 (high trust) - Change this week: +3 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-09-29 ## Components - remote · `app.emailchaser.com`: 85/100 (this document), [markdown](https://verifymcp.io/servers/com-emailchaser-emailchaser/api-mcp.md), [page](https://verifymcp.io/servers/com-emailchaser-emailchaser/api-mcp) ## Channel facts - Endpoint: `https://app.emailchaser.com/api/mcp` - Transports: `streamable-http` - Auth: `required` - Version: `1.0.1` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-09-29. - **Endpoint Security**: 89/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation is enforced on tool calls, but the challenge carries no valid RFC 9728 metadata, so a client cannot discover where to get a token. - HTTPS is enforced; there's no plaintext access path. - The HSTS (Strict-Transport-Security) header is present. - DNSSEC check failed: this domain isn't protected by DNSSEC. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 73/100 - AI-judged instruction clarity (excellent). - Context-footprint check failed: tool/resource definitions use about 15811 tokens (~156/item across 101 items; 101 tools + 0 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 57/100 - Stability observed for 17 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 100/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 100% of tool parameters carry a description. - **Tool Safety**: 100/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - All 9 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation. - An AI judge read all 102 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### How do I install the Emailchaser MCP server? Emailchaser is a hosted endpoint at https://app.emailchaser.com/api/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add --transport http com-emailchaser-emailchaser 'https://app.emailchaser.com/api/mcp' ``` ### Cursor ```json { "mcpServers": { "com-emailchaser-emailchaser": { "url": "https://app.emailchaser.com/api/mcp" } } } ``` ### VS Code ```json { "servers": { "com-emailchaser-emailchaser": { "type": "http", "url": "https://app.emailchaser.com/api/mcp" } } } ``` ### Codex ```toml [mcp_servers.com-emailchaser-emailchaser] url = "https://app.emailchaser.com/api/mcp" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "com-emailchaser-emailchaser": { "type": "remote", "url": "https://app.emailchaser.com/api/mcp", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add com-emailchaser-emailchaser --url 'https://app.emailchaser.com/api/mcp' --transport streamable-http ``` ### Hermes ```yaml mcp_servers: com-emailchaser-emailchaser: url: "https://app.emailchaser.com/api/mcp" ``` ### Netclaw ```json { "McpServers": { "com-emailchaser-emailchaser": { "Transport": "http", "Url": "https://app.emailchaser.com/api/mcp" } } } ``` ### Vellum ```bash assistant mcp add com-emailchaser-emailchaser -t streamable-http -u 'https://app.emailchaser.com/api/mcp' ``` ### Other ```json { "mcpServers": { "com-emailchaser-emailchaser": { "type": "http", "url": "https://app.emailchaser.com/api/mcp" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-09-29 (score 85, +1) - [security] Tool “connect_sender_email” rewrote its description, which is the text the model reads - [security] Tool “get_campaign” rewrote its description, which is the text the model reads - [security] Tool “get_sender_email” rewrote its description, which is the text the model reads - [security] Tool “get_sender_email_dns” rewrote its description, which is the text the model reads - [security] Tool “get_sender_email_warmup” rewrote its description, which is the text the model reads - [security] Tool “list_sender_emails” rewrote its description, which is the text the model reads - [security] Tool “update_campaign” rewrote its description, which is the text the model reads - [security] Tool “update_sender_email” rewrote its description, which is the text the model reads - [security] Tool “update_sender_email_warmup” rewrote its description, which is the text the model reads - [cosmetic] “create_campaign” added an optional parameter “minimumHealthScore” - [cosmetic] “update_campaign” added an optional parameter “minimumHealthScore” ### 2026-09-28 (score 84, 0) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-09-26 (score 84, +1) No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-25 (score 83, 0) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-09-24 (score 83, +1) No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-23 (score 82, 0) - [security] The server rewrote its instructions, which are the text every model session reads - [security] Tool “create_dfy_order” rewrote its description, which is the text the model reads - [cosmetic] “create_dfy_order” reworded the description of “domains” - [cosmetic] “create_dfy_order” reworded the description of “mailboxes” ### 2026-09-22 (score 82, +1) No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-21 (score 81, 0) - [functional] New tool “cancel_email_verification_job” - [functional] New tool “create_email_verification_job” - [functional] New tool “get_email_verification_job” - [functional] New tool “get_email_verification_rates” - [functional] New tool “list_email_verification_jobs” - [functional] New tool “list_email_verification_results” ## MCP tools (101) ### `confirm_connection` (~149 tokens) Confirm the connection Confirms the API key works and tells Emailchaser which AI assistant connected. Call it as your first action after connecting, and whenever the user asks you to confirm or check the Emailchaser connection: it records the assistant and time on the key, which the app's API & MCP page watches to show the user you are in, and completes the 'Connect your AI' onboarding step. Idempotent: repeat calls simply refresh the record. Works with read-only keys as well as read & write keys. Input parameters: - `agent` (string): Your name in any form, e.g. claude, chatgpt, cursor, gemini. Normalized to a short lowercase identifier and echoed back ### `list_campaigns` (~97 tokens) List campaigns Lists cold email campaigns in the workspace with their status and stats (sent, replies, bounces). Supports pagination and filtering by status or folder. Input parameters: - `folderId` (integer): Filter by folder ID - `limit` (integer): Page size (default 20, max 200) - `page` (integer): Page number, starting at 1 (20 campaigns per page) - `status` (string): Filter by campaign status ### `create_campaign` (~620 tokens) Create campaign Creates a campaign in the workspace. The campaign starts as a DRAFT and sends nothing. A new campaign has no emails in it, so it cannot be launched until a sequence is written with replace_campaign_sequence and a sender email is attached. Sending limits and deliverability settings can be set here or changed later with update_campaign. Input parameters: - `allowNonBusinessEmails` (boolean): Allow sending to free mailbox providers (gmail.com, etc.) - `dailyLimit` (integer): Cap on the total emails (initial + follow-ups) the campaign may schedule per calendar day in its timezone. Omit for no campaign-level cap; per-mailbox limits still apply - `emoji` (string): Campaign emoji shown in the app. Defaults to a generic one - `flow` (string): Campaign flow. Defaults to multiple_leads_scheduled, which behaves exactly like a campaign created in the app. Only pass api if you specifically want lead validation skipped at launch - `ignoreOutOfOfficeReplies` (boolean): Do not stop follow-ups on out-of-office replies - `isEnabledCatchallValidated` (boolean): Send to catch-all validated addresses - `isEnabledEmailVerifier` (boolean): Verify lead emails before sending - `isEnabledIgnoreHardBouncedLeads` (boolean): Skip leads that previously hard-bounced - `isEnabledIgnoreLeadsWhoAlreadyResponded` (boolean): Skip leads who already responded in another campaign - `isEnabledLlm` (boolean): Enable AI (LLM) features for this campaign - `isEnabledSkipLeadIfAlreadyExists` (boolean): Skip leads that already exist in the workspace - `isEnabledStopFollowUpsForSameCompany` (boolean): Company reply stop: once a lead replies (out-of-office and other automatic replies don't count), stop emailing the other leads at the same company in this campaign. Subdomains count as the same compa… - `isEnabledStopFollowUpsOnReply` (boolean): Stop follow-ups to a lead once they reply - `maximumSendingLimitPerSenderEmail` (integer): Daily sending limit per sender email account - `maximumSendingLimitPerSenderEmailVariation` (integer): Random daily variation applied to the sending limit - `maximumTimeBetweenEmails` (integer): Maximum gap between two sends, in minutes - `minimumHealthScore` (integer): Minimum email account health score for this campaign, 1-100 (see healthScore in list_sender_emails). An account below it, or with no score yet, sends nothing in this campaign, first emails and follow… - `minimumTimeBetweenEmails` (integer): Minimum gap between two sends, in minutes - `name` (string, required): Campaign name - `timezone` (string): IANA timezone, e.g. America/New_York ### `get_campaign` (~100 tokens) Get campaign Retrieves a campaign by ID, including settings, sending schedule, stats and per-status email counts. minimumHealth lists each connected email account on the campaign with its healthScore and whether the campaign's minimum health score (settings.minimumHealthScore) holds it back, with the reason; when every account is held back, allHeldBack is true and message says the campaign is sending nothing. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) ### `update_campaign` (~596 tokens) Update campaign Updates campaign properties such as name, emoji, timezone, sending limits, the minimum email account health score and deliverability settings. Only the provided fields are changed. A new minimum health score re-plans a running campaign at once. Input parameters: - `allowNonBusinessEmails` (boolean): Allow sending to free mailbox providers (gmail.com, etc.) - `dailyLimit` (integer): Cap on the total emails (initial + follow-ups) the campaign may schedule per calendar day in its timezone. Omit for no campaign-level cap; per-mailbox limits still apply - `emoji` (string): Campaign emoji - `id` (integer, required): The numeric campaign ID (from list_campaigns) - `ignoreOutOfOfficeReplies` (boolean): Do not stop follow-ups on out-of-office replies - `isEnabledCatchallValidated` (boolean): Send to catch-all validated addresses - `isEnabledEmailVerifier` (boolean): Verify lead emails before sending - `isEnabledIgnoreHardBouncedLeads` (boolean): Skip leads that previously hard-bounced - `isEnabledIgnoreLeadsWhoAlreadyResponded` (boolean): Skip leads who already responded in another campaign - `isEnabledLlm` (boolean): Enable AI (LLM) features for this campaign - `isEnabledSkipLeadIfAlreadyExists` (boolean): Skip leads that already exist in the workspace - `isEnabledStopFollowUpsAcrossCampaigns` (boolean): Stop follow-ups to a lead in this campaign once they reply in any campaign - `isEnabledStopFollowUpsForSameCompany` (boolean): Company reply stop: once a lead replies (out-of-office and other automatic replies don't count), stop emailing the other leads at the same company in this campaign. Subdomains count as the same compa… - `isEnabledStopFollowUpsOnReply` (boolean): Stop follow-ups to a lead once they reply - `maximumSendingLimitPerSenderEmail` (integer): Daily sending limit per sender email account - `maximumSendingLimitPerSenderEmailVariation` (integer): Random daily variation applied to the sending limit - `maximumTimeBetweenEmails` (integer): Maximum gap between two sends, in minutes - `minimumHealthScore` (integer): Minimum email account health score for this campaign, 1-100 (see healthScore in list_sender_emails). An account below it, or with no score yet, sends nothing in this campaign, first emails and follow… - `minimumTimeBetweenEmails` (integer): Minimum gap between two sends, in minutes - `name` (string): New campaign name - `timezone` (string): IANA timezone, e.g. America/New_York ### `launch_campaign` (~51 tokens) Launch campaign Launches a new campaign or resumes a paused one. The campaign configuration is validated before launching; emails start sending per the campaign schedule. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) ### `pause_campaign` (~37 tokens) Pause campaign Pauses a running campaign and cancels all currently scheduled emails. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) ### `update_campaign_schedule` (~205 tokens) Update campaign schedule Updates a campaign's sending schedule: timezone, sending days, daily time window and frequency. Input parameters: - `daysSchedule` (array): Days of the week to send on, e.g. ["monday", "tuesday", "wednesday"] - `endSchedule` (string): Daily sending window end time, e.g. 17:00 - `everySchedule` (integer): Sending frequency interval - `id` (integer, required): The numeric campaign ID (from list_campaigns) - `maximumTimeBetweenEmails` (integer): Maximum gap between two sends, in minutes - `minimumTimeBetweenEmails` (integer): Minimum gap between two sends, in minutes - `sendAt` (string): Exact send time for single-lead scheduled campaigns (ISO 8601) - `startSchedule` (string): Daily sending window start time, e.g. 09:00 - `timezone` (string, required): IANA timezone the schedule runs in, e.g. Europe/London ### `get_campaign_sequence` (~64 tokens) Get campaign sequence Returns the ordered emails that make up a campaign's sequence, including any A/B variants. delayDays on each step is counted from the previous step, and the first step is always 0. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) ### `replace_campaign_sequence` (~133 tokens) Replace campaign sequence Replaces a campaign's WHOLE sequence with the steps provided. This is not a partial edit: steps you leave out are removed, so send the full sequence every time. Sending the same payload twice leaves the same result, so a retry cannot duplicate steps. Editing a running campaign is allowed and changes future sends only; already-sent emails are untouched. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) - `signature` (string): Optional signature appended to every step - `steps` (array, required): The full sequence, first email first. The first step must have delayDays 0 ### `delete_campaign` (~48 tokens) Delete campaign Permanently deletes a campaign and all associated data, including its emails, sequences and scheduled tasks. This cannot be undone. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) ### `get_campaign_stats` (~109 tokens) Get campaign stats Returns a campaign's performance in one call: totals (sent, replied, positive, bounced, meetings), per-A/B-variant results, per-sequence-step results and a daily time series (UTC days). Use it to judge how a campaign is doing or to compare variants. There is no opens metric anywhere in the response: Emailchaser does not track opens, so its absence is deliberate, not an omission. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) ### `attach_campaign_sender_emails` (~147 tokens) Attach sender emails to campaign Attaches connected sender email accounts to a campaign. A campaign only sends through the senders attached to it, so this call decides which mailboxes it uses. Idempotent: already-attached senders are left untouched and only missing ones are added. The call is refused whole when any requested sender is not a connected sender email in the workspace. Attaching to a running campaign reschedules it so the new senders are picked up. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) - `senderEmailIds` (array, required): Sender email IDs to attach (from list_sender_emails). Every ID must be a connected sender email in the workspace ### `detach_campaign_sender_email` (~121 tokens) Detach sender email from campaign Detaches a sender email from a campaign so the campaign stops sending through that mailbox. Unsent follow-ups to emails this sender already sent are canceled and do not come back on re-attach; a running campaign is rescheduled onto its remaining senders; already-sent emails are untouched. Idempotent: detaching a sender that is not attached is a no-op. Input parameters: - `id` (integer, required): The numeric campaign ID (from list_campaigns) - `senderEmailId` (integer, required): The numeric sender email ID (from list_sender_emails) ### `move_lead_to_campaign` (~114 tokens) Move lead to another campaign Moves a lead from one campaign to another: the lead's unsent emails in the source campaign are deleted, and if the target campaign is running, emails for the lead are enqueued there. Use it to re-route a lead into a better-fitting campaign. Input parameters: - `leadId` (integer, required): The numeric lead ID (returned when the lead was created) - `sourceCampaignId` (integer, required): The campaign the lead is currently in - `targetCampaignId` (integer, required): The campaign to move the lead into ### `list_leads` (~125 tokens) List leads Lists the leads in the workspace, newest first, 20 per page. Filter by exact email to look up a single lead, or by campaign to list only that campaign's leads. This is how you find the ID of a lead you added earlier. Input parameters: - `campaignId` (integer): Filter to the leads in one campaign - `email` (string): Filter by exact email address, which returns at most one lead - `limit` (integer): Page size (default 20, max 200) - `page` (integer): Page number, starting at 1 ### `add_leads` (~123 tokens) Add leads Creates or updates up to 1,000 leads in one request, optionally adding them to a campaign via campaignId. Existing leads (matched by email) are updated instead of duplicated. Returns the id of every lead written, so they can be fetched or updated afterwards. Attributes outside the named fields can be passed in customVariables and become merge tags in email copy. Input parameters: - `campaignId` (integer): Campaign to add the leads to (from list_campaigns) - `leads` (array, required): The leads to create or update (1 to 1,000 per request) ### `get_lead` (~40 tokens) Get lead Retrieves a lead by ID, including contact details and company information. Input parameters: - `id` (integer, required): The numeric lead ID (returned when the lead was created) ### `update_lead` (~203 tokens) Update lead Updates a lead's contact details. Only the provided fields are changed. Input parameters: - `company` (string): Company name - `customVariables` (object): Any attribute the named fields do not cover, e.g. { pageVisited: '/pricing' }. Each key becomes a merge tag usable in email copy as {key}. Keys match case-insensitively with spaces treated as undersc… - `email` (string): Lead email address - `firstName` (string): Lead first name - `id` (integer, required): The numeric lead ID (returned when the lead was created) - `lastName` (string): Lead last name - `linkedin` (string): LinkedIn profile URL - `middleName` (string): Lead middle name - `phone` (string): Phone number - `title` (string): Job title - `website` (string): Company website URL ### `delete_lead` (~40 tokens) Delete lead Permanently deletes a lead by ID. This cannot be undone. Input parameters: - `id` (integer, required): The numeric lead ID (returned when the lead was created) ### `get_lead_conversation` (~115 tokens) Get lead conversation Returns a lead's full email thread in chronological order: outbound emails (sent, scheduled and unsent drafts) plus inbound replies, each with direction and status. AI reply drafts awaiting review are marked isDraft; edit one with update_reply_draft and send it with send_reply_draft (or a human sends it from the app). Use it to read the back-and-forth with one lead before deciding what to do next. Input parameters: - `id` (integer, required): The numeric lead ID (returned when the lead was created) ### `mark_lead_meeting` (~121 tokens) Mark meeting booked on lead Records that a meeting was actually booked with this lead: sets meetingBookedAt to now, sets the lead's category to meeting_booked and fires the LeadCategoryUpdate webhook. Emailchaser never infers meetings from reply text or calendars, so this explicit mark is the only way a meeting is counted (in get_campaign_stats totals.meetings and get_outcomes_report). Idempotent: repeating the call keeps the original timestamp and fires no second webhook. Input parameters: - `id` (integer, required): The numeric lead ID (returned when the lead was created) ### `unmark_lead_meeting` (~100 tokens) Unmark booked meeting on lead Removes the booked-meeting mark from a lead, e.g. when it was recorded by mistake or the meeting was canceled: clears meetingBookedAt and, when the category is still meeting_booked, reverts it to interested. The original booked time is lost. Idempotent: unmarking a lead with no meeting is a no-op. Input parameters: - `id` (integer, required): The numeric lead ID (returned when the lead was created) ### `update_lead_category` (~123 tokens) Update lead category Sets or corrects a lead's category (tag), typically to fix an AI misclassification of a reply. Setting meeting_booked behaves exactly like mark_lead_meeting. Changing the category away from meeting_booked does NOT clear the booked-meeting mark; use unmark_lead_meeting for that. A real change fires the LeadCategoryUpdate webhook; setting the value the lead already has is a no-op. Input parameters: - `category` (string, required): The category to set - `id` (integer, required): The numeric lead ID (returned when the lead was created) ### `list_replies` (~186 tokens) List replies Lists inbound emails (replies received from prospects) in the workspace, newest first, 20 per page. Filter by AI response category, campaign, lead or a time floor. responseCategory is null while AI categorization is still pending. This tool only lists: to answer a reply, review its AI draft (list_reply_drafts), edit it if needed (update_reply_draft) and send it with send_reply_draft. Input parameters: - `campaignId` (integer): Filter by campaign ID - `category` (string): Filter by AI response category - `leadId` (integer): Filter by lead ID - `limit` (integer): Page size (default 20, max 200) - `page` (integer): Page number, starting at 1 - `since` (string): Only replies received at or after this time (RFC3339 or YYYY-MM-DD) ### `list_reply_drafts` (~114 tokens) List AI reply drafts Lists AI-suggested reply drafts awaiting review, newest first, 20 per page. Each draft answers the inbound reply referenced by inReplyToEmailId. Nothing here has been sent: a draft stays a draft until a human sends it from the app or send_reply_draft is called. Edit one first with update_reply_draft if the wording needs work. Input parameters: - `limit` (integer): Page size (default 20, max 200) - `page` (integer): Page number, starting at 1 ### `update_reply_draft` (~131 tokens) Edit AI reply draft Edits the subject and/or body of an AI reply draft before it goes out. Provide at least one field; provided fields must be non-empty. This never changes the draft's status or sends anything: the draft stays a draft until a human sends it from the app or send_reply_draft is called. Emails that are not AI reply drafts (sent or scheduled emails, inbound replies, sequence templates) are refused. Input parameters: - `body` (string): New body - `id` (integer, required): The numeric reply draft ID (from list_reply_drafts) - `subject` (string): New subject line ### `send_reply_draft` (~142 tokens) Send AI reply draft Sends an AI reply draft to the prospect through the conversation's sender mailbox; it is scheduled for delivery right away and cannot be recalled. The draft's CURRENT subject and body are what goes out, so read it first (list_reply_drafts or get_lead_conversation) and fix it with update_reply_draft if needed. Refused with 409 for anything that is not a sendable AI reply draft (already sent or scheduled emails, inbound replies, sequence templates) and with 422 when the conversation has no connected sender mailbox or no resolvable recipient. Input parameters: - `id` (integer, required): The numeric reply draft ID (from list_reply_drafts) ### `list_sender_emails` (~241 tokens) List sender emails Lists the sending email accounts in the workspace, 20 per page, with their connection status, daily limits and health score. Filter to one campaign's senders, to connected or disconnected mailboxes only, or to one workspace on the account. healthScore is the account's health score: 0-100, higher is better, the share of its warm-up emails over the last 7 full days that landed in the inbox rather than spam. It moves daily as warm-up emails land in the inbox (up) or in spam (down), and is null while warm-up is off or before 20 warm-up emails were checked. Use it to pick the accounts to add to a campaign. Input parameters: - `campaignId` (integer): Only the sender emails attached to this campaign - `isConnected` (boolean): true for mailboxes that are connected and able to send, false for disconnected ones - `limit` (integer): Page size (default 20, max 200) - `page` (integer): Page number, starting at 1 - `spaceId` (integer): Only the sender emails of this workspace (from list_workspaces) ### `get_sender_email` (~120 tokens) Get sender email Retrieves a connected sending email account by ID, including its health score. healthScore is the account's health score: 0-100, higher is better, the share of its warm-up emails over the last 7 full days that landed in the inbox rather than spam. It moves daily as warm-up emails land in the inbox (up) or in spam (down), and is null while warm-up is off or before 20 warm-up emails were checked. Input parameters: - `id` (integer, required): The numeric sender email ID (from list_sender_emails) ### `connect_sender_email` (~225 tokens) Connect sender email Connects an SMTP/IMAP mailbox to the workspace using an app password, with no browser step. Google and Microsoft mailboxes are NOT supported here because both require an interactive consent screen that cannot be automated; connect those in the app. The address must be on a business domain, so gmail.com and similar are rejected. The returned account's healthScore is null until warm-up has checked 20 of its emails (see get_sender_email). Input parameters: - `email` (string, required): The mailbox address, on a business domain - `firstName` (string): Sender first name - `imapServerUrl` (string, required): IMAP host, optionally with a port, e.g. imap.fastmail.com:993 - `lastName` (string): Sender last name - `loginString` (string): Login username if it differs from the email address - `password` (string, required): App password for the mailbox, not the account login password - `smtpServerUrl` (string, required): SMTP host, optionally with a port, e.g. smtp.fastmail.com:587 ### `update_sender_email` (~190 tokens) Update sender email Updates a connected sending email account's display name, signature or daily sending limits. Only the provided fields are changed. Warm-up settings are separate: use update_sender_email_warmup. The returned account includes its healthScore (see get_sender_email). Input parameters: - `currentDailyLimit` (integer): Today's effective daily limit - `familyName` (string): Sender last name - `givenName` (string): Sender first name - `id` (integer, required): The numeric sender email ID (from list_sender_emails) - `maximumSendingsLimitPerDay` (integer): Maximum emails this mailbox may send per day - `minimumSendingsLimitPerDay` (integer): Minimum emails per day during gradual build-up - `signature` (string): Email signature appended to sends from this mailbox - `toggleGradualBuildUp` (boolean): Ramp the daily limit up gradually (recommended for new mailboxes) ### `get_sender_email_dns` (~158 tokens) Get sender email DNS vitals Checks the sender domain's SPF, DKIM, DMARC and MX records and reports each as OK, WARNING, MISSING or ERROR with human-readable issues (the same checks behind the app's DNS vitals view), plus the mailbox's warm-up status: whether it is enrolled, today's ramp target, the daily cap and its healthScore (0-100, higher is better, the share of its warm-up emails over the last 7 full days that landed in the inbox rather than spam). Use it to diagnose deliverability. DNS lookups run live at request time, so the call can take a few seconds but never returns stale records. Input parameters: - `id` (integer, required): The numeric sender email ID (from list_sender_emails) ### `get_sender_email_warmup` (~176 tokens) Get sender email warm-up settings Reads a mailbox's warm-up settings: whether warm-up is on, the ramp (startLimit warm-up emails on the first day, increaseBy more each sending day, up to capLimit a day), weekdays-only, timezone, today's ramp target (currentPerDay) and the account's healthScore (0-100, higher is better, the share of its warm-up emails over the last 7 full days that landed in the inbox rather than spam; null while warm-up is off or before 20 were checked). Warm-up volume is separate from the campaign sending limits changed with update_sender_email. When configured is false the mailbox has never warmed, and the values shown are the defaults that switching warm-up on would use. Input parameters: - `id` (integer, required): The numeric sender email ID (from list_sender_emails) ### `update_sender_email_warmup` (~340 tokens) Update sender email warm-up Switches warm-up on or off and changes the warm-up ramp for up to 100 mailboxes in one call, applying the same settings to each. Only the settings provided change. Warm-up sends startLimit emails on the first day and adds increaseBy each sending day until it reaches capLimit a day; this is separate from campaign sending limits. A mailbox that has never warmed needs enabled: true to take any other setting, and is then enrolled with the defaults (2 a day, 2 more each day, up to 10 a day, weekdays only, UTC) plus the settings given. Raising capLimit on a mailbox that is already warming lifts today's target without restarting its ramp. Each mailbox succeeds or fails on its own: the result lists the updated mailboxes' settings, each with its healthScore (see get_sender_email_warmup), under updated, and any failures with the reason under failed. Input parameters: - `capLimit` (integer): Most warm-up emails per day; the ramp stops here - `enableReplies` (boolean): Let warm-up recipients reply, adding reply signals - `enabled` (boolean): true switches warm-up on, false switches it off - `ids` (array, required): Sender email IDs to update (from list_sender_emails) - `increaseBy` (integer): Warm-up emails added each sending day until the cap - `startLimit` (integer): Warm-up emails on the first day - `timezone` (string): IANA timezone for the warm-up send window, e.g. America/New_York - `weekdaysOnly` (boolean): Send warm-up emails Monday to Friday only ### `list_inbox_placement_tests` (~89 tokens) List inbox placement tests Lists every inbox placement test defined in the workspace, newest first. A test is the definition: the email content, which mailboxes send it and, for a recurring test, how often it runs. Each execution of a test is a run (list_inbox_placement_runs). Inbox placement is a paid add-on: a workspace without it gets an error, not an empty list. ### `list_inbox_placement_runs` (~134 tokens) List inbox placement runs Lists inbox placement runs, newest first, optionally only those of one test. Each run counts how many probe emails landed in the inbox, in spam, in a Gmail category tab (promotions) or nowhere (missing, which usually means a silent block). Counters are only final once status is completed. Any rate of -1 means NOT MEASURED yet and must never be reported as 0%. Input parameters: - `limit` (integer): How many runs to return (default 50, max 200) - `testId` (integer): Only runs of this test (from list_inbox_placement_tests) ### `get_inbox_placement_run` (~139 tokens) Get inbox placement run Returns one inbox placement run with its complete report: the headline inbox / spam / promotions / missing split, the breakdown per mailbox provider and per sending mailbox, and the content spam rules the copy triggered. 'Promotions' rolls up every Gmail category tab. 'Missing' means the probe was never found in any folder, which usually indicates a silent block: a worse problem than spam, with a different fix. spamScore is in tenths of a point (47 means 4.7) and -1 means not scored. Input parameters: - `id` (integer, required): The numeric inbox placement run ID (from list_inbox_placement_runs) ### `list_inbox_placement_run_results` (~96 tokens) List inbox placement run probes Returns one row per probe email of a run: which of your mailboxes sent it, which seed mailbox received it, where it landed and how many seconds it took to arrive. deliverySeconds is worth watching on its own: greylisting and throttling show up there before they show up in a placement number. Input parameters: - `id` (integer, required): The numeric inbox placement run ID (from list_inbox_placement_runs) ### `get_inbox_placement_stats_by_date` (~134 tokens) Get inbox placement stats by date Rolls completed inbox placement runs up by UTC calendar day over a window, for a trend. Defaults to the last 30 days. Days on which nothing ran are ABSENT from the series rather than zero: never report a missing day as 0% placement, it means nobody ran a test that day. Input parameters: - `from` (string): Start of the window, RFC3339, e.g. 2026-08-01T00:00:00Z. Defaults to 30 days ago - `to` (string): End of the window, RFC3339. Defaults to now ### `get_sender_reputation` (~100 tokens) Get sender reputation and mailbox health Returns the latest health check for every connected mailbox: SPF, DKIM, DMARC and MX status (OK, WARNING, MISSING or ERROR), blacklist listings with their delisting links, measured inbox placement over recent runs and a combined 0-100 health score. blacklistsChecked is reported next to blacklistsListed so the count is never read as a total. A placementScore or healthScore of -1 means not measured, not zero. ### `get_deliverability_insights` (~98 tokens) Get deliverability insights What is wrong with deliverability across the workspace right now, worst first, each with the action that fixes it. Combines the inbox placement measured over the window with the latest health check of every connected mailbox: authentication records, blacklist listings and measured placement per mailbox. The best first call when asked 'why are we landing in spam'. Input parameters: - `days` (integer): How many days of runs to summarise (default 30) ### `list_webhooks` (~25 tokens) List webhooks Lists the webhook endpoints registered for the workspace, with their event type and status. ### `create_webhook` (~88 tokens) Create webhook Registers a webhook endpoint that receives a POST request whenever the selected event happens (email sent, reply received, bounce, lead created, lead category updated, or campaign status changed). Input parameters: - `name` (string): Display name for the webhook, shown in the app - `type` (string, required): The event type to subscribe to - `url` (string, required): HTTPS URL that will receive the events ### `update_webhook` (~106 tokens) Update webhook Updates a registered webhook's name, URL, event type or enabled state. Only the provided fields are changed. Disabling a webhook stops deliveries without deleting it. Input parameters: - `id` (integer, required): The numeric webhook ID (from list_webhooks) - `isEnabled` (boolean): Enable or disable deliveries without deleting the webhook - `name` (string): New display name - `type` (string): New event type - `url` (string): New HTTPS URL to receive events ### `delete_webhook` (~38 tokens) Delete webhook Deletes a registered webhook endpoint by ID so it stops receiving events. Input parameters: - `id` (integer, required): The numeric webhook ID (from list_webhooks) ### `list_blocklist_entries` (~162 tokens) List blocklist entries Returns the suppression entries (blocked domains and email addresses) that apply to this workspace, newest first. Blocked entries are never emailed by any campaign. By default that spans both lists: this workspace's own entries and the account-wide ones inherited from the main workspace. Each entry reports which list it came from. Input parameters: - `limit` (integer): Page size (default 100, max 1,000) - `offset` (integer): Number of entries to skip (default 0) - `scope` (string): Which list to return: "workspace" for this workspace's own entries, "global" for the account-wide list, "all" for both (default) - `search` (string): Case-insensitive substring match on the domain or address ### `add_blocklist_entries` (~174 tokens) Add blocklist entries Adds up to 1,000 suppression entries in one call so no campaign ever emails them. Each value is either a full email address (contains @) or a bare domain; the type is inferred per value. Existing entries and invalid values are skipped, so the call is safe to retry and suited to carrying over a suppression list from another sending platform. Scope defaults to "workspace"; "global" blocks across every workspace on the account and only works from the main workspace. Input parameters: - `scope` (string): "workspace" (default) blocks for this workspace only; "global" blocks for every workspace on the account - `values` (array, required): Email addresses and/or domains to block, e.g. ["competitor.com", "jane@acme.com"] (1 to 1,000 per request) ### `remove_blocklist_entries` (~194 tokens) Remove blocklist entries Unblocks up to 1,000 domains or email addresses in one call, so campaigns can email them again. Pass values (domains or addresses, matched case-insensitively) and/or ids (entry IDs from list_blocklist_entries); a value that is not blocked is counted as skipped rather than failing the call. Scope defaults to "workspace" and never touches the account-wide list unless asked; removing an account-wide entry only works from the main workspace. Input parameters: - `ids` (array): Blocklist entry IDs to remove (from list_blocklist_entries). Provide values, ids or both - `scope` (string): Which list to remove from: "workspace" (default), "global", or "all" - `values` (array): Email addresses and/or domains to unblock, e.g. ["competitor.com", "jane@acme.com"] (1 to 1,000 per request) ### `get_blocklist_entry` (~75 tokens) Get blocklist entry Returns one suppression entry by ID: the blocked domain or email address, when it was added and which list it belongs to. Entries inherited from the account-wide list are visible from a sub-workspace too and report scope "global". Input parameters: - `id` (integer, required): The numeric blocklist entry ID (from list_blocklist_entries) ### `update_blocklist_entry` (~143 tokens) Update blocklist entry Changes one suppression entry's blocked value, its scope, or both; provide at least one. A value containing @ is stored as an email address, otherwise as a domain, so an entry can be converted between the two. Moving an entry to or from the account-wide list ("global") requires the main workspace's key and moves the entry onto the main workspace. Input parameters: - `id` (integer, required): The numeric blocklist entry ID (from list_blocklist_entries) - `scope` (string): "workspace" blocks for this workspace only; "global" blocks for every workspace on the account - `value` (string): The new domain or email address to block ### `remove_blocklist_entry` (~91 tokens) Remove one blocklist entry Removes one suppression entry by ID, so campaigns can email that domain or address again. This cannot be undone: the entry and the record of when it was added are gone. A sub-workspace key cannot remove an account-wide entry it merely inherits. To unblock many values at once use remove_blocklist_entries. Input parameters: - `id` (integer, required): The numeric blocklist entry ID (from list_blocklist_entries) ### `import_instantly` (~80 tokens) Import from Instantly Imports your Instantly.ai campaigns and leads into Emailchaser using your Instantly API key. Imported campaigns are created as DRAFTS — nothing sends until you review and launch them. Runs in the background and returns a job id. Input parameters: - `instantlyApiKey` (string, required): Your Instantly.ai API key (Instantly → Settings → API keys) ### `list_instantly_accounts` (~143 tokens) List Instantly sending accounts Fetches the sending accounts of an Instantly.ai workspace using your Instantly API key, together with a pre-filled CSV for Emailchaser's bulk IMAP/SMTP connection flow. A read-only preview before an import: nothing is written to the workspace. Mailbox passwords cannot be exported from any provider, so each account is either reconnected via Google/Microsoft OAuth in the app or bulk-uploaded with app passwords using the CSV. The backend treats all non-GET calls as writes, so this needs a read & write API key. Input parameters: - `instantlyApiKey` (string, required): Your Instantly.ai API key (Instantly → Settings → API keys) ### `copilot_plan` (~114 tokens) Copilot: plan a campaign Given a company website, the honest AI SDR builds an ideal-customer-profile (ICP) and a suggested cold-email sequence. Read-only — creates nothing. Returns the ICP (personas, titles, industries, suggested Sales Navigator keywords) and a draft sequence you can review or pass to copilot_launch. Input parameters: - `context` (string): Optional extra context, e.g. 'we sell to dental clinics in the US' - `website` (string, required): The company website to analyze, e.g. https://acme.com ### `copilot_launch` (~170 tokens) Copilot: launch a draft campaign Creates a DRAFT campaign from a sequence and starts finding + verifying leads for it from a LinkedIn Sales Navigator search. Nothing sends — the campaign stays a draft until you review and launch it. Returns the new campaign id and a lead-finding job id. Input parameters: - `icp` (object): Optional ICP object as returned by copilot_plan, stored with the campaign for reference only - `name` (string, required): Campaign name - `salesNavData` (string): Optional base64 LinkedIn session payload from the browser extension; required for lead-finding to actually run - `salesNavSearchUrl` (string, required): A LinkedIn Sales Navigator people-search URL to source leads from - `sequence` (array, required): The email sequence: the first step is the initial email, the rest are follow-ups ### `create_icp` (~252 tokens) Create ICP Stores a manually-authored Ideal Customer Profile (ICP): who the workspace sells to, as targeting criteria (titles, seniorities, industries, company sizes, locations, keywords). Set makePrimary to promote it to the workspace's active profile. Use copilot_plan instead when you want the AI to build the ICP from a website. Input parameters: - `companySizes` (array): Company headcount ranges, e.g. ["11-50", "51-200"] - `industries` (array): Industries, e.g. ["Software"] - `keywords` (array): Free-text keywords, e.g. ["b2b saas"] - `locations` (array): Locations, e.g. ["United States"] - `makePrimary` (boolean): Promote this profile to the workspace's active one, demoting any existing primary - `name` (string, required): Profile name, e.g. "Mid-market SaaS RevOps leaders" - `seniorities` (array): Seniority levels, e.g. ["owner", "director"] - `summary` (string): One to three sentences describing who the workspace sells to - `titles` (array): Job titles to target, e.g. ["CEO", "Head of Sales"] ### `list_icps` (~76 tokens) List ICPs Lists the workspace's stored Ideal Customer Profiles (ICPs), newest first, with their targeting criteria, whether each is AI-generated or human-edited, and the estimated audience size. Input parameters: - `limit` (integer): Page size (default 50, max 200) - `page` (integer): Page number, starting at 1 ### `get_primary_icp` (~44 tokens) Get primary ICP Returns the workspace's active (primary) Ideal Customer Profile — the profile the workspace currently targets; at most one is primary. Errors with 404 when none is set. ### `get_icp` (~55 tokens) Get ICP Retrieves one Ideal Customer Profile by ID, including its targeting criteria, whether it is AI-generated or human-edited, primary status and estimated audience size. Input parameters: - `id` (integer, required): The numeric ICP ID (from list_icps) ### `update_icp` (~200 tokens) Update ICP Applies a partial edit to an Ideal Customer Profile: omitted fields are left unchanged, and sending an empty list clears that list. Any edit marks the profile as human-authored. Input parameters: - `companySizes` (array): Company headcount ranges, e.g. ["11-50", "51-200"] - `id` (integer, required): The numeric ICP ID (from list_icps) - `industries` (array): Industries, e.g. ["Software"] - `keywords` (array): Free-text keywords, e.g. ["b2b saas"] - `locations` (array): Locations, e.g. ["United States"] - `name` (string): New profile name - `seniorities` (array): Seniority levels, e.g. ["owner", "director"] - `summary` (string): New one-to-three-sentence summary - `titles` (array): Job titles to target, e.g. ["CEO", "Head of Sales"] ### `delete_icp` (~48 tokens) Delete ICP Deletes an Ideal Customer Profile. Deleting the primary leaves the workspace without an active profile. This cannot be undone. Input parameters: - `id` (integer, required): The numeric ICP ID (from list_icps) ### `set_primary_icp` (~54 tokens) Set primary ICP Promotes an Ideal Customer Profile to the workspace's active one, demoting any existing primary. At most one profile is primary per workspace. Input parameters: - `id` (integer, required): The numeric ICP ID (from list_icps) ### `refresh_icp_audience_size` (~71 tokens) Refresh ICP audience size Re-counts how many prospects match an ICP's targeting criteria against the live data provider and caches the result on the profile. Sizing is free — it never spends credits; only revealing contact details is metered. Input parameters: - `id` (integer, required): The numeric ICP ID (from list_icps) ### `get_audience_size` (~220 tokens) Get audience size Counts how many prospects match ad-hoc targeting criteria (titles, seniorities, industries, company sizes, locations, keywords) without saving anything. Free — searching never spends credits; only revealing contact details is metered. Use it to validate targeting before creating an ICP or sourcing leads. A read-only key may call it: a read-only key can use the read (list and get) tools plus confirm_connection, get_audience_size and search_lead_finder. Input parameters: - `companySizes` (array): Company headcount ranges, e.g. ["11-50", "51-200"] - `industries` (array): Industries, e.g. ["Software"] - `keywords` (array): Free-text keywords, e.g. ["b2b saas"] - `locations` (array): Locations, e.g. ["United States"] - `seniorities` (array): Seniority levels, e.g. ["owner", "director"] - `titles` (array): Job titles to target, e.g. ["CEO", "Head of Sales"] ### `source_prospects` (~265 tokens) Source prospects into a campaign (spends credits) SPENDS CREDITS. Queues a background job that searches Emailchaser's contact database with an Ideal Customer Profile's targeting criteria, reveals the matching people and adds them to the campaign as leads. Uses the workspace's primary ICP when icpId is omitted, and adds 50 prospects unless count says otherwise (max 500 per call). Every stored prospect costs the reveal price in credits (1 at the time of writing; the response reports creditsPerProspect and estimatedCredits, the most this batch can cost). Duplicates, blocklisted domains and contacts without an email address are filtered out before any credit is spent. Asynchronous: poll list_leads with campaignId to watch the prospects arrive. Calling again for the same campaign and profile pages deeper into the audience instead of re-revealing (and re-paying for) the same people. Check get_credit_balance and get_audience_size first. Input parameters: - `campaignId` (integer, required): The campaign the sourced prospects are added to (from list_campaigns) - `count` (integer): How many prospects to add in this call (default 50, max 500) - `icpId` (integer): The ICP whose targeting criteria drive the search (from list_icps). Defaults to the primary ICP ### `get_lead_finder_filters` (~123 tokens) Lead Finder: filter values and limits Returns the values Lead Finder's list filters accept (seniorities, jobFunctions, companySizes, revenue, industries, countries, headquartersCountries, regions, continents), the limits that apply to this workspace (page sizes, deepest page, people per add, first-N count, imports running at once, and the daily browsing allowance with what is left today), and creditsPerProspect, what adding one person to a campaign costs. Free, and makes no call to the data provider. Call it before search_lead_finder so filter values match exactly. ### `search_lead_finder` (~549 tokens) Lead Finder: search the contact database (free) Searches Emailchaser's B2B contact database (Lead Finder) with explicit filters and returns one page of matching people, masked: first name, last initial, title, seniority, job function, company name, industry, size and revenue band, and location. Email addresses, domains, LinkedIn URLs and phone numbers are never shown; contact details are revealed only when people are added to a campaign with add_lead_finder_prospects. Spends no credits, but every result row uses the account's daily browsing allowance (rowsLeftToday; 2,000 rows a day by default, 250 on a trial). An account may start 20 searches a minute. Searches that find nobody also draw on a bucket of 120 that refills one every 30 seconds; while it is empty every new search is refused for a moment (rate_limited, reason empty_searches, with retryAfterSeconds). The same page asked for again within 10 minutes costs nothing. total is the exact audience size only when totalIsExact is true; otherwise it is a lower bound (often 50,000). If status is running or totalStatus is pending, call get_lead_finder_search with the searchId: total, hasMore and maxPage are recomputed then. status failed means the search did not run, and error says why (rate_limited, timeout, provider_blocked, budget_exhausted, invalid_filters, expired or internal): it is not an empty audience, so try again later. Each result's ref is what add_lead_finder_prospects takes, valid for 60 minutes after its page was last shown. inWorkspace means Lead Finder added that person to this workspace and their lead is still there, so adding them again is skipped for free; someone who is a lead from another source shows false, and adding them is skipped for free too. A read-only key may use this tool. Input parameters: - `filters` (object, required): Who to look for. Every field is optional but at least one include filter is required. Free-text fields take up to 50 values of up to 100 characters each (get_lead_finder_filters has the limits that a… - `page` (integer): Results page, starting at 1 (default 1). The deepest page is 100 by default, and a search's maxPage says how deep that audience goes - `pageSize`: People per page: 25 (default) or 50 ### `get_lead_finder_search` (~176 tokens) Lead Finder: read a search Reads a search started with search_lead_finder, by its searchId. While it is still running, or while its exact total is still being counted (totalStatus pending), the call waits up to about six seconds, so calling again straight away is fine. A finished page can be re-read for 10 minutes after it was fetched (less if it came from cache), and re-reading it in that window keeps its refs valid for another 60 minutes. After that the call answers status failed with error expired, though refs already shown stay usable until 60 minutes after they were last shown; running search_lead_finder again shows them afresh and uses browsing rows. After 15 minutes the search is not found. Input parameters: - `searchId` (string, required): The searchId returned by search_lead_finder ### `add_lead_finder_prospects` (~844 tokens) Lead Finder: add people to a campaign (spends credits) SPENDS CREDITS, AND BY DEFAULT METERED EMAIL VERIFICATION. Adds people from the Lead Finder contact database to a campaign as leads, revealing their contact details, in the background. Pass refs (from search_lead_finder results; up to 1,000 different people by default) to add exactly those people, or pass filters and count (1 to 5,000 by default) to add count people matching the filters who are not in the workspace yet. A filters add always walks the matches from the top and skips anyone already a lead, free and not counted, so repeating the same add adds the NEXT count people and charges again. Never repeat an add to retry: after an error or a timeout, call list_lead_finder_imports to see whether it started. A filters add stops early when the audience runs out or once it has looked at five people for every one requested (at least 1,000). People already added count toward that limit even though skipping them is free, so after an add of more than about 1,000 people a small follow-up can stop with nobody added. Every person a filters add looks at, added or skipped, also uses the account's daily allowance for filters adds (25,000 people by default). Each person added costs 1 credit ($0.033 at list), reported as creditsPerProspect; the response reports estimatedCredits, the most the add can cost in credits, and the wallet must hold that much for it to start. People already in the workspace, blocklisted, without a usable address, on a personal mailbox when the campaign only takes business addresses, or marked invalid by verification are skipped and cost no credits. verifyEmails (on by default) checks every screened address with the paid email verification waterfall, including the ones it marks invalid: one or two checks per address, billed as metered usage on the next invoice (price per check: GET /email-verification/rates in the REST API), within the account's monthly verification spend limit. Catch-all and unconfirmed addresses are added and charged, and so is every a… Input parameters: - `campaignId` (integer, required): The numeric campaign ID (from list_campaigns) - `count` (integer): How many people not yet in the workspace to add with filters (1 to 5,000 by default; get_lead_finder_filters has the limit that applies) - `filters` (object): Add people matching these filters (same shape as search_lead_finder). Needs count. The matches are walked from the top every time and people already in the workspace are skipped, so a repeat adds the… - `refs` (array): Refs of the people to add, from search_lead_finder results. Duplicates and blanks are dropped before sending; up to 1,000 different people per add by default (get_lead_finder_filters has the limit th… - `verifyEmails` (boolean): Check each address with the paid email verification waterfall before adding it (default true): one or two checks per address, billed on the next invoice, including addresses that turn out invalid. In… ### `list_lead_finder_imports` (~74 tokens) Lead Finder: list adds Lists the workspace's Lead Finder adds (people added to campaigns from the contact database), newest first, each with its progress: requested, added, skipped and why, what email verification said, and credits spent. Input parameters: - `limit` (integer): How many to return (default 10, max 50) ### `get_lead_finder_import` (~256 tokens) Lead Finder: add progress Returns one Lead Finder add's progress: status (running, completed, failed or canceled), how many people were added and skipped and why (skipReasons), what email verification said, and credits spent. added, creditsSpent and status can still change until finishedAt is set, so poll it after add_lead_finder_prospects until it is. A completed add's endReason is all_selected, requested_reached, audience_exhausted or fetch_limit, and a canceled one's is canceled. A failed add can still have added and charged people (see added and creditsSpent); lastError says why it stopped: insufficient_credits, contact_cap_reached, results_expired, budget_exhausted, provider_blocked, invalid_filters, campaign_not_found or internal. A new filters add to finish a partial one starts from the top again and counts the people already added toward its fetch limit (five people per one requested, at least 1,000), so after a large add, pick the missing people by ref from search_lead_finder results instead. Input parameters: - `id` (integer, required): The import ID (importId from add_lead_finder_prospects or list_lead_finder_imports) ### `cancel_lead_finder_import` (~164 tokens) Lead Finder: stop an add Stops a running Lead Finder add. It reads canceled at once. A batch the worker is already writing is still added and charged; a batch still being screened or verified is dropped, though verification checks already made are billed. Credits held for the rest are released. Until finishedAt is set, added, creditsSpent and even status can still change: if that batch was the add's last, it ends completed or failed instead. People already added stay in the campaign. A stopped add cannot be resumed: start a new add_lead_finder_prospects instead. Stopping one that already finished changes nothing. Input parameters: - `id` (integer, required): The import ID (importId from add_lead_finder_prospects or list_lead_finder_imports) ### `plan_autopilot` (~205 tokens) Autopilot: size a budget plan Turns a monthly budget in dollars into a concrete outbound setup: how many domains and mailboxes it buys, monthly sending volume, prospects per month, and costs (one-off setup, recurring, first month). creditsUsd, recurringUsd and firstMonthUsd value prospect credits at the list price, 1 credit ($0.033 at list) per revealed prospect, and a note says when that puts the monthly cost above the budget. Pure computation — nothing is created or charged. expectedMeetingsPerMonth is a planning estimate on pessimistic assumptions, not a promise. Use it to answer 'what does $X/month get me' before start_autopilot_run. Input parameters: - `budgetUsd` (number, required): Total monthly budget in US dollars, inclusive of the platform subscription - `maxMailboxes` (integer): Cap on mailboxes regardless of budget. 0 means no cap - `platformUsd` (number): Subscription cost to reserve before sizing infrastructure. Defaults to 0 ### `start_autopilot_run` (~377 tokens) Autopilot: start a run Starts an autopilot run for a company website: the AI builds an ICP, writes a sequence and checks that prospects match, then STOPS at an approval gate. Nothing is revealed, charged or sent and no sending accounts are bought until approve_autopilot_run is called; approval then reveals the first batch at 1 credit ($0.033 at list) per prospect, up to targetProspects and at most 2,000. The call is refused when the wallet cannot cover that batch. When budgetUsd is given, the sized budget plan is snapshotted on the run and returned in this response, the only response that carries it, with credits valued at list, and targetProspects defaults to the plan's monthly prospects. Without budgetUsd the run can never buy sending accounts, so the workspace needs one connected before approval or the run fails. Requires an active subscription (any plan). Input parameters: - `budgetUsd` (number): Monthly budget in US dollars; sizes a plan that is snapshotted on the run - `maxMailboxes` (integer): Cap on the budget plan's mailboxes. 0 means no cap - `replyMode` (string): How inbound replies are handled: off, draft (default: AI drafts a reply for a human to send), approve, or auto. auto SENDS AI replies to interested prospects without review, so only pass it when the… - `targetProspects` (integer): How many prospects approval reveals first, at 1 credit ($0.033 at list) each (at most 2,000 in one batch). Defaults to the budget plan's monthly prospects when budgetUsd is given, else 50 - `website` (string, required): The company website to seed the run from, e.g. https://acme.com ### `list_autopilot_runs` (~89 tokens) Autopilot: list runs Lists the workspace's autopilot runs, newest first, with status (pending, building_icp, writing_sequence, sourcing_prospects, awaiting_approval, running, paused, completed, failed) and linked ICP/campaign IDs. Input parameters: - `limit` (integer): Page size (default 50, max 200) - `page` (integer): Page number, starting at 1 ### `get_autopilot_run` (~80 tokens) Autopilot: get a run Returns one autopilot run including its full audit trail. It does not return the budget plan: that comes back only from start_autopilot_run (when budgetUsd was given) and from plan_autopilot. Use it to check progress. Input parameters: - `id` (integer, required): The numeric autopilot run ID (from list_autopilot_runs) ### `approve_autopilot_run` (~243 tokens) Autopilot: approve a run Approves an autopilot run that is awaiting approval — the one human gate in the flow. CAN SPEND REAL MONEY: approval first reveals the run's prospects at 1 credit ($0.033 at list) each, then, if the workspace has no connected sending account, places one done-for-you order sized from the plan snapshotted at start, at most 10 .com domains and at most six mailboxes per domain, never more mailboxes than the plan, charged at the prices in effect when the order is placed. So the plan's mailbox and domain counts are a ceiling and its dollar figures an estimate, not an exact quote. No credits are bought, but the reveal and later top-ups spend the wallet's credits. If a sending account is already connected, no infrastructure is bought; a run started without budgetUsd and with no connected account fails. Show the user the plan from the start_autopilot_run response before calling this. Nothing is revealed, bought or sent before this call; after it, sending starts without further confirmation. Input parameters: - `id` (integer, required): The numeric autopilot run ID (from list_autopilot_runs) ### `pause_autopilot_run` (~69 tokens) Autopilot: pause a run Suspends an autopilot run that is still in flight; resume later with resume_autopilot_run. Pausing never skips the approval gate. A completed or failed run cannot be paused. Input parameters: - `id` (integer, required): The numeric autopilot run ID (from list_autopilot_runs) ### `resume_autopilot_run` (~81 tokens) Autopilot: resume a run Resumes a paused autopilot run. A run paused before approval goes back to awaiting approval — resuming can never skip the gate. A failed run resumes from the stage it failed at once the cause (e.g. insufficient credits) is fixed. Input parameters: - `id` (integer, required): The numeric autopilot run ID (from list_autopilot_runs) ### `kill_autopilot_run` (~108 tokens) Autopilot: kill a run Engages the kill switch: the run halts wherever it is and can NEVER be resumed, and any campaign the run launched is paused so nothing more sends. Use pause_autopilot_run instead when you might want to continue later. The optional reason is recorded in the run's audit trail. Input parameters: - `id` (integer, required): The numeric autopilot run ID (from list_autopilot_runs) - `reason` (string): Why the run is being killed, for the audit trail ### `get_credit_balance` (~103 tokens) Get credit balance Returns the workspace's credit wallet: available, reserved, lifetime granted and used, and the monthly grant. Credits pay for prospect reveals and AI work (list price $0.033 each). A new workspace sees zeros, not an error. unlimited is true when Emailchaser has made this workspace's credits free: every credit action then goes through without using available and is never refused for lack of credits, so there is no need to check the balance or buy credits. ### `list_credit_transactions` (~220 tokens) List credit transactions Lists the workspace's credit ledger, newest first: every grant, spend, reservation and refund with the balance after each entry. Filter by movement kind, reason or a time window. Use it to see where credits went, or to check for a stripe_topup entry after an unconfirmed purchase_credits call. An entry with free set to true was written while the workspace's credits were free: its amount is what the action would have cost, and no credits moved. Input parameters: - `kind` (string): Filter by movement type - `limit` (integer): Page size (default 50, max 200) - `page` (integer): Page number, starting at 1 - `reason` (string): Filter by what the credits were spent on or granted for - `since` (string): Only entries at or after this time (RFC3339 or YYYY-MM-DD) - `until` (string): Only entries at or before this time (RFC3339 or YYYY-MM-DD; a bare date means midnight UTC at the start of that day) ### `purchase_credits` (~262 tokens) Buy credits (charges real money) SPENDS REAL MONEY. Immediately charges the workspace's saved default card (the one behind the active subscription), off-session, with no confirmation step beyond this call — every successful call is a new charge. Buys 1,000 to 10,000 prospect credits at the tiered list price: $33/1k · $20/1k from 5k. The server prices the charge, so treat this as the list price and not a quote. Errors carry a machine-readable code: billing_required and payment_failed mean no money moved (fix billing or the card, then retry); credits_free means this workspace's credits are free, so nothing was charged and there is nothing to buy; temporarily_unavailable means the purchase stopped before any charge, so it is safe to retry shortly; purchase_incomplete means the card WAS charged but crediting failed — do NOT retry, support is already notified; purchase_unconfirmed means the outcome is unknown or the purchase completed without a balance to report — check list_credit_transactions for a stripe_topup entry before retrying. After a timeout or a dropped connection, check the same way before calling this again. Input parameters: - `credits` (integer, required): How many prospect credits to buy (1,000 to 10,000) ### `get_outcomes_report` (~198 tokens) Get outcomes report Puts money against results for a time window: credit spend (grouped by reason, valued at the $0.033 list price) plus done-for-you order costs on one side, and sent emails, replies, positive replies and booked meetings on the other, with cost per reply, per positive reply and per meeting. Subscription fees are NOT included. campaignId narrows the outcome side only — spend stays workspace-level — so per-campaign cost figures are partial attribution, not a true campaign cost. Use it to answer 'what did we spend and what did we get'. Input parameters: - `campaignId` (integer): Narrow the outcome side to one campaign (spend stays workspace-level) - `since` (string): Window start, RFC3339 or YYYY-MM-DD (inclusive) - `until` (string): Window end, RFC3339 or YYYY-MM-DD (inclusive; a bare date means midnight UTC at the start of that day) ### `search_dfy_domains` (~120 tokens) Search available sending domains Checks availability and pricing of sending domains derived from a brand name (e.g. 'acme' yields acme-mail.com and similar). Only .com and .org are supported. Free to call — use it to pick domains and see exact prices before create_dfy_order. Input parameters: - `limit` (integer): Maximum suggestions to return - `query` (string, required): Brand name to derive domain suggestions from - `tlds` (string): Comma-separated TLDs to check (default "com,org"; only com and org are supported) ### `create_dfy_order` (~235 tokens) Create done-for-you order (charges real money) SPENDS REAL MONEY. Places a real order for sending domains and pre-warmed mailboxes: domains are registered at their listed price (about $13.99/year for a .com — search_dfy_domains shows the exact price per domain) and each mailbox costs about $3 setup plus $6/month. The order is accepted immediately and provisioned in the background; poll get_dfy_order for progress. Purchased domains redirect visitors to forwardingDomain. Use search_dfy_domains first to confirm availability and price. Every domain in domains needs at least one mailbox in mailboxes whose domainName is that domain, or the order is refused before anything is bought; mailboxes can also go on a domain from an earlier order. Input parameters: - `domains` (array): Domains to purchase. Each one needs at least one mailbox in mailboxes with the same domainName. - `forwardingDomain` (string): Where the purchased domains redirect visitors, e.g. acme.com - `mailboxes` (array): Mailboxes to provision: at least one on every domain in domains. A mailbox can also go on a domain from an earlier order. ### `list_dfy_orders` (~76 tokens) List done-for-you orders Lists the workspace's done-for-you orders, newest first, each with status, cost breakdown and the ordered domains and mailboxes. Internal billing and provider records are never exposed. Input parameters: - `limit` (integer): Page size (default 50, max 200) - `page` (integer): Page number, starting at 1 ### `get_dfy_order` (~76 tokens) Get done-for-you order Returns one done-for-you order: status (created, pending_approval, processing, completed, failed, partially_completed, canceled), cost breakdown and any failure reason. Poll it to track provisioning after create_dfy_order. Input parameters: - `id` (integer, required): The numeric order ID (from create_dfy_order or list_dfy_orders) ### `get_workspace_details` (~43 tokens) Get workspace details Returns the workspace behind the API key: campaign counts broken down by status and the list of members. Useful as a first call to confirm which workspace a key belongs to. ### `list_workspaces` (~85 tokens) List workspaces Lists the workspaces owned by the account behind the API key: the main workspace and its sub-workspaces, each with id, name, icon and creation date. isCurrent marks the workspace this key is bound to. Every other tool acts on the current workspace only; to work in another workspace, connect with that workspace's own key (create_workspace_api_key mints one). ### `create_workspace` (~147 tokens) Create workspace Creates a sub-workspace under the account's main workspace (for example one per client, for an agency) and by default mints a read & write API key bound to it. The key's fullKey is returned exactly ONCE and cannot be retrieved again, so hand it to the user straight away; it never outlives the calling key. Must be called with the main workspace's key: sub-workspace keys are refused. Workspaces are a Professional-plan feature. Input parameters: - `generateApiKey` (boolean): Also mint a read & write API key for the new workspace. Defaults to true - `name` (string, required): Name of the new workspace (1 to 60 characters) ### `create_workspace_api_key` (~237 tokens) Create API key for a workspace Mints a new API key bound to a workspace the calling key already owns: its own workspace, or one of its sub-workspaces when called with the main workspace's key. This is how a workspace whose key was lost gets a new one without a UI step. fullKey is returned exactly ONCE and cannot be retrieved again, so hand it to the user straight away. The new key authorizes the named workspace only and never outlives the calling key. Keys can be revoked in the app under API & MCP. Input parameters: - `id` (integer, required): The numeric workspace ID (from list_workspaces) - `name` (string): Name shown in the app's API key list. Defaults to " key" - `readOnly` (boolean): Mint a read-only key. It can use the read (list and get) tools plus confirm_connection, get_audience_size and search_lead_finder, so it can read, size audiences and browse Lead Finder (which still us… ### `get_billing_profile` (~64 tokens) Get workspace billing profile Returns the registrant and postal contact details held for the workspace: what is filed with the registrar when a done-for-you order buys a domain, and the postal address a CAN-SPAM footer must carry. Errors with 404 until set_billing_profile has been called. ### `set_billing_profile` (~213 tokens) Set workspace billing profile Creates or replaces the workspace's registrant and postal contact details. Do this before create_dfy_order: domain registration files these details with the registrar, so every field except addressLineTwo is required. Idempotent: sending the same body twice leaves the same state. Input parameters: - `addressLineOne` (string, required): Street address - `addressLineTwo` (string): Suite, floor or unit (optional) - `city` (string, required): City - `company` (string, required): Company name - `country` (string, required): ISO 3166-1 alpha-2 country code, e.g. US - `firstName` (string, required): Registrant first name - `lastName` (string, required): Registrant last name - `phone` (string, required): Phone number without the country code - `phoneCc` (string, required): Telephone country calling code without the plus, e.g. 1 - `postalCode` (string, required): Postal or ZIP code - `state` (string, required): State, province or region ### `get_email_verification_rates` (~108 tokens) Get the email verification rate Returns what one email verification costs right now, read from the billing plan the meter actually charges against. Call this before create_email_verification_job rather than assuming a price. Every check runs a waterfall of up to two providers and each one that returns a verdict is one billable verification credit, so an address costs ONE credit when the first provider rejects it outright and TWO when both answer. Budget against perAddressCeilingUsd, which is the common case, not perAddressFloorUsd. ### `create_email_verification_job` (~298 tokens) Verify a list of email addresses (spends money) SPENDS MONEY: every address checked adds metered usage to the workspace's next invoice. This does NOT use prospect credits and it does NOT create or send a campaign — it verifies a list on its own and gives back a per-address verdict you can download as CSV. Call get_email_verification_rates first for the current price: an address costs one verification credit when the first provider rejects it outright and two when both providers answer, so multiply your list size by perAddressCeilingUsd to budget. An address that gets no verdict is NOT billed and comes back with result unknown. Duplicates are removed and unparseable entries are returned in invalid_emails before anything is charged, so the total in the response is what will be billed against, not what you submitted. Needs an active subscription: a trialing or past_due workspace is refused with subscription_not_active. If the workspace's monthly verification allowance runs out mid-job the job does not fail — the remaining addresses come back unknown, marked, still in the download, and unbilled. Poll get_email_verification_job until state is done, then read the results with list_email_verification_results. Input parameters: - `emails` (array, required): The addresses to verify, up to 50,000. Duplicates and unparseable entries are dropped before billing. - `name` (string, required): What to call this job in the app, e.g. 'Q3 conference list' ### `list_email_verification_jobs` (~82 tokens) List email verification jobs Lists the workspace's standalone email verification jobs, newest first, with live counts and what each has billed so far (meterEvents and spentUsd). Input parameters: - `page` (integer): Page number, starting at 1 - `search` (string): Filter by job name - `size` (integer): Page size (default 25, max 200) ### `get_email_verification_job` (~84 tokens) Get an email verification job Returns one verification job: its state, per-verdict counts and what it has billed. Poll until state is done. An errorCode of monthly_limit_reached means the allowance ran out and the remaining addresses came back unknown rather than missing — they are still in the results, marked, and were not billed. Input parameters: - `jobId` (string, required): The job ID ### `list_email_verification_results` (~145 tokens) List an email verification job's results Returns one row per address with its verdict: valid, catchall_validated (the domain accepts everything, so delivery is likely but not proven), invalid, or unknown (no verdict, and not billed). Each row also carries what each provider said and how many verification credits it cost. Filter with result, where 'deliverable' means valid plus catch-all, which is what a campaign will actually send to. Input parameters: - `jobId` (string, required): The job ID - `page` (integer): Page number, starting at 1 - `result` (string): Filter by verdict - `size` (integer): Page size (default 25, max 200) ### `cancel_email_verification_job` (~53 tokens) Cancel an email verification job Stops a running verification job. Addresses already verified stay in the results and stay billed; addresses that never ran are never charged, so cancelling costs nothing further. Input parameters: - `jobId` (string, required): The job ID ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-emailchaser-emailchaser/api-mcp#diagnostics ## Score history - 2026-09-29: 85 - 2026-09-28: 84 - 2026-09-27: 84 - 2026-09-26: 84 - 2026-09-25: 83 - 2026-09-24: 83 - 2026-09-23: 82 - 2026-09-22: 82 - 2026-09-21: 81 - 2026-09-20: 81 - 2026-09-19: 80 - 2026-09-18: 80 - 2026-09-17: 79 - 2026-09-16: 79 - 2026-09-15: 79 - 2026-09-14: 78 - 2026-09-13: 78 - 2026-09-12: 77 - 2026-09-11: 36 - 2026-09-10: 36 ## Common questions ### What is the Emailchaser MCP server? Emailchaser is an MCP server listed in the public MCP registry as com.emailchaser/emailchaser. Run cold email outbound from an AI agent: campaigns, leads, replies, sender accounts, autopilot. This page covers its hosted endpoint (https://app.emailchaser.com/api/mcp). ### Is the Emailchaser MCP server safe to use? Emailchaser scores 85 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm. ### What tools does the Emailchaser MCP server expose? Emailchaser exposes 101 tools: confirm_connection, list_campaigns, create_campaign, get_campaign, update_campaign, and 96 more. Their descriptions and schemas cost roughly 15,569 tokens of context every time the server is loaded. ### Does the Emailchaser MCP server require authentication? Yes. Emailchaser asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything. ### Is the Emailchaser MCP server still maintained? Emailchaser is still listed as active in the MCP registry. We last reached this channel on 29 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced. ## Links - Remote endpoint: https://app.emailchaser.com/api/mcp - Authorisation metadata: https://app.emailchaser.com/.well-known/oauth-protected-resource/api/mcp - Website: https://www.emailchaser.com/mcp-server - Changelog RSS feed: https://verifymcp.io/servers/com-emailchaser-emailchaser/api-mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/com-emailchaser-emailchaser/api-mcp.json - HTML version of this page: https://verifymcp.io/servers/com-emailchaser-emailchaser/api-mcp