continue_campaign
ChatGPTSends an instruction to the agent inside an existing campaign and returns a jobId to read with fetch_leads. This is the tool that grows or steers a cohort in place - 'find 5 more like these', 'look at Singapore and the Gulf instead of US institutions', 'focus on funds over $5bn AuM'. find_leads always creates a separate campaign with its own ICP, which splits the funnel and leaves the two cohorts incomparable. The agent sees the campaign's existing leads and ICP, so they can be referred to. It cannot answer back through this API, so a question sent here gets no response. New leads count against the prospect allowance, and de-duplication is per workspace, so a request for 5 more can yield fewer when the agent rediscovers people already in the workspace. It does not remove or skip leads: 'drop the bad ones' takes nothing out of the cohort or out of the outreach queue.
fetch_leads
ChatGPTReturns the status and any results of a find_leads job, by jobId. Status values: "pending" - the search is still running, though leads may already hold a partial list; "completed" - the agent delivered a batch, which is not a guarantee that no more will arrive, and total may still rise; "stalled" - no leads arrived for about 15 minutes, meaning the agent asked a question, errored, or never delivered. Also returns total (leads in this response), campaignId (accepted by get_campaign, get_campaign_leads and get_campaign_stats) and campaignUrl, a deep link to the prospects tab for this search in Onsa. agentMessage is agent text from this campaign's chat, filtered to what was said after this job started, so it never predates the request - though on a campaign with several searches it can be a late message from an earlier one. A null agentMessage does not mean the agent is silent: artifact-only messages carry no text, and an agent that errored writes nothing there at all. The agent cannot be replied to through this API. Each lead carries name, companyName, linkedInUrl, position, headline, location, industry, companyUrl, email (often null), and score (1-5) with scoreExplanation, the reasoning for why this person matches the ICP.
find_leads
ChatGPTStarts a live B2B lead search with Onsa's agent, matching real people (with LinkedIn profiles) against the workspace's ICP. Takes a natural-language brief - titles, company type, geography, e.g. 'find 5 fintech founders in NYC'. Returns a jobId immediately; the search itself usually takes 3-10 minutes, and its status and results are read with fetch_leads. limit is a target the agent aims at rather than a cap, so it often returns more than asked. Every lead it finds counts against the workspace's prospect allowance.
get_campaign
ChatGPTReturns one campaign's ICP - the ideal-customer profile the agent derived and scores leads against - plus its outreach template and settings. The ICP comes back exactly as stored, in snake_case: perfect_lead and reachable_market are one-line summaries, while company and person hold the rules that actually drive scoring, each an object with critical and preferential rule lists. product and owner describe the seller. The two summary strings are not the scoring criteria; company.critical and person.critical are. No key is guaranteed present. outreachTemplate shows how much personalization the messages allow: a template whose only placeholders are [FIRST_NAME] and [COMPANY_NAME] produces near-identical mail-merge copy for every lead.
get_campaign_leads
ChatGPTReturns the leads of any campaign by campaignId, with the same fields as fetch_leads, including score and scoreExplanation. It covers campaigns not started in this session, which fetch_leads cannot reach because fetch_leads requires a jobId from a find_leads call in the same session. Passing leadIds resolves the reply buckets from get_campaign_stats back into named people.
get_campaign_stats
ChatGPTReturns the outreach funnel for one campaign: invites sent, invites accepted, messages sent, and replies split into positive / negative / other by sentiment. LinkedIn and email are merged, as on Onsa's Overview page. These count leads rather than actions - a lead invited twice counts once - so where a lead was re-invited they read slightly lower than the Overview widget, which counts actions. invitesSent can exceed leadsTotal without anyone having been invited twice: the counters are already de-duplicated by lead, and the gap means a lead who was contacted has since been skipped or deleted, which action rows survive and leadsTotal does not count. Onsa stores no post likes or emoji reactions at all, so 'LinkedIn reactions' in this data means the replies people sent; list_replies returns their text, and this tool only counts them. rates carries acceptancePct, replyPct, positivePct and negativePct, each already computed over its own correct denominator; leadsTotal is not one of those denominators, since it counts every prospect in the cohort including those never contacted. A rate is null when its denominator is 0, meaning nothing was sent so no rate exists - which is different from the counts above being genuinely 0. All four rates count only replies Onsa has scored, so an unscored or still-in-window reply appears in none of them, and list_replies can legitimately show more replies than the rates imply. Two further properties of the data: the *Scheduled counts are everything queued regardless of date, and sentiment is evaluated once per lead ever rather than once per reply. A campaign whose invites were never sent reads as all zeros, which is 'not tried yet' rather than 'failed'.
get_lead_memo
ChatGPTReturns the research memo Onsa's agent wrote about one lead: role history, company size and stage, what they have said publicly, and the angle on them. It is usually far richer than scoreExplanation, and it is the source material for outreach built on a specific, checkable fact rather than a generic opener. Most leads have no memo - Onsa writes one only for prospects it has researched - so memo: null is the common case and not an error, and scoreExplanation is the remaining source in that case.
list_campaigns
ChatGPTLists the campaigns (past lead searches) in this workspace that the user takes part in, newest first. Returns the newest limit of them, default 50; returned against total shows whether older campaigns were omitted. Each entry has id, title, leadsTotal, hasIcp, tags, createdAt and updatedAt. An id is accepted by get_campaign for its ICP, get_campaign_leads for its people, get_campaign_stats for its outreach funnel, list_replies for what prospects wrote back, and list_next_steps for what the campaign still needs a human to do. Searches started over MCP often share a generic title, so the ICP and the dates distinguish cohorts more reliably than the title alone. A campaign row exists from the moment a search starts, so the newest entry is frequently still empty, with leadsTotal 0.
list_next_steps
ChatGPTReturns read-only guidance for what to do next. Without campaignId, it returns the first-search question, active search progress, or campaign names and statuses to choose from. A single accessible campaign is resolved automatically. With campaignId, it returns a ranked to-do list: people who replied, people who accepted an invite but were never messaged, drafts waiting for approval, leads found but never contacted, and setup that is missing. It answers 'what should I do about this campaign today', where get_campaign_stats answers 'how is it doing'. For replies specifically, list_replies is the better source: its awaitingOurReply compares timestamps, while the replied bucket here covers only leads whose sentiment was scored and does not know whether we have since answered. leadIds passed to get_campaign_leads resolves the buckets into named people. Limits of the data: Onsa does not record whether we have already replied, or whether someone was contacted outside Onsa; 'replied' includes only replies whose sentiment was scored, so it is a floor; a withdrawn or unreachable invite leaves no trace, so some 'never contacted' leads may already have been tried. Sentiment is judged once per lead, not per message. Counts are complete; leadIds are capped at 200.
list_pending_outreach
ChatGPTLists outreach messages the agent has drafted that are waiting for a human to approve - the 'a message for X is ready' queue. Each entry carries the draft text, the lead it is for, and why that lead scored as it did. Omitting campaignId covers the whole workspace. This tool sends nothing: rewrite_outreach replaces a draft's text, and send_outreach queues one for delivery.
list_replies
ChatGPTReturns the text of what prospects replied, for every lead in the campaign that answered, paired with the outbound message it answers. get_campaign_stats counts replies and labels them; this returns the words. sentiment is Onsa's own label, written once per lead on their first reply - later replies never change it, and a reply Onsa has not scored yet comes back as sentiment: null, which means unscored rather than neutral. Those unscored replies are absent from get_campaign_stats entirely, so this tool can return more replies than the funnel counts. Three derived fields come with the reply. awaitingOurReply: the prospect spoke last and no sent message followed. It is structural only - a flat 'no thanks' satisfies it too - and Onsa sees only what Onsa sent, so a reply made by hand inside LinkedIn is invisible to it; what the data supports is 'no reply recorded here'. daysSinceLastReply is elapsed whole days rather than time-unanswered: it is populated even where we did answer, so it describes time-unanswered only when awaitingOurReply is also true. looksLikeBroadcast: the prospect's most recent message reached another profile in this campaign word for word, which indicates a mass DM rather than an answer. All three are floors rather than verdicts - a blast only one lead received is indistinguishable from a real reply, and two people who send the same long template are both flagged. Top-level awaitingOurReplyCount spans the whole campaign rather than this page, and leaves out broadcasts and replies scored negative; it can exceed returned when limit is small.
revoke_shortlist
ChatGPTRevokes a list link by the id create_shortlist returned; only the user who created the link can revoke it. Future views stop immediately; previously copied or downloaded information cannot be recalled.
rewrite_outreach
ChatGPTReplaces the text of an outreach draft that is waiting for approval. The current draft and the lead's scoreExplanation come from list_pending_outreach; get_lead_memo carries the richer research on that person. The rewritten draft stays in the approval queue, and this tool sends nothing.
send_outreach
ChatGPTQueues one already-approved outreach draft for delivery to a real person on LinkedIn. It requires confirmText, the draft body character-for-character as stored, and confirmName, the recipient's name: drafts are often near-identical between people, so matching the body alone does not identify which one was meant. A mismatch is refused without returning the stored text, which list_pending_outreach supplies. The server additionally requires a confirmation from the person at the keyboard, rendered by the MCP client and quoting the draft as stored; that approval is single-use and bound to one recipient and one draft. A client that cannot render such a confirmation receives a refusal carrying a link to approve inside the Onsa app, and nothing is queued. On success the message is queued rather than delivered: Onsa sends it on its own schedule, subject to daily pacing limits.
