Official MCP RegistryListed
Onsa
Find scored B2B leads, read campaign replies and send approved LinkedIn outreach.
First seen 2 Oct 2026. Evidence as of 7 Oct 2026.
16
Tools
From an anonymous probe
1
Source listings
Each with its own history
5
Recorded changes
Since first seen
Tools
| Tool | Description | Behaviour |
|---|---|---|
| continue_campaign | Sends 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. | Destructive |
| create_shortlist | Publishes a preview_shortlist snapshot as a link. It requires the previewKey that preview_shortlist returned, and confirmPublic: true. The server itself requests no confirmation from the user: confirmPublic: true records the caller's statement that the user reviewed this snapshot and confirmed publishing it. The server rebuilds the snapshot and creates nothing when the selection or the snapshot no longer matches that previewKey: a different campaign, selection or order of leadIds, a different note, an includeRationale value that changes the snapshot, a prospect changed or removed, or the campaign renamed since the preview. The link makes the snapshot viewable by anyone who has it for 30 days unless it is revoked with revoke_shortlist. This does not share the conversation or invite anyone into the workspace. Returns the URL, list id and expiry to the requester; sending it to another person is a separate user action. | Destructive |
| fetch_leads | Returns the status and any results of a find_leads or continue_campaign job, by jobId. Status values are "pending", "completed" and "stalled", and `leads` can hold a partial list while "pending". For a find_leads job: "pending" while it has no leads, the agent has not answered and it is under about 15 minutes old, and also while it has leads, until a reply carrying leads completes it; "completed" once the agent posts a reply carrying leads while this is the oldest open job on its campaign, usually its final report (`total` can still change afterwards); "stalled" as soon as the agent answers without any leads (a question, or none found), or when no lead has arrived after about 15 minutes - derived on each read, so a lead that lands later turns it back to "pending". For a continue_campaign job: "pending" while `newLeads` is 0 and it is under about 15 minutes old, even after the agent has replied (if that reply confirms a settings-only change, the request is done), and while `newLeads` is above 0, until a reply carrying leads completes it; "completed" once a reply carrying leads arrives on the campaign while this is the oldest open job there (possibly a late reply from an earlier search), or after about 15 minutes with `newLeads` 0 when an agent reply was confirmed; "stalled" after about 15 minutes with `newLeads` 0 when no agent reply was confirmed (agentMessage can still hold one). A reply carrying leads completes only the oldest open job on a campaign, so a newer job stays "pending" meanwhile, even with `newLeads` above 0. A pending search keeps running when the conversation ends, and a later call with the same jobId returns what it found. First leads arrive within 5 minutes in half of searches and within 9 minutes in 9 of 10. More can arrive until the final report, typically about 10 minutes after the start (9 of 10 within 15). Also returns `total` (for a find_leads job, the leads the campaign holds now, skipped and deleted ones excluded; for a continuation, equal to `newLeads`), `newLeads` (continuations only: leads added to the campaign since the continuation started - a count by time, which can include a late batch from an earlier search), `returned` (how many this response carries), `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 the latest agent text in this campaign's chat. For a continuation it is filtered to what was said after the continuation started, though it can be a late message from an earlier search; for a find_leads job it is not filtered, so after a later continue_campaign on the same campaign it can be that request’s reply. 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. While a search is running, one call can wait up to 35 seconds for its first leads or its next batch before answering, so a call can take that long; other calls answer at once. `progress` carries startedAt, elapsedSeconds and a note on where the search stands, whether the next call will wait, and when results are likely. 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. A lead has `signal` (status verified, inferred or none, plus a one-sentence summary) only when the search asked for a need signal. `refinements` appears when leads are returned and the campaign does not filter by company size; each entry is a suggestion the user can accept, not something already done. | Read-only |
| find_leads | Starts 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, with campaignUrl and a `progress` note. The search itself runs in the background and keeps running after the conversation moves on. First leads arrive within 5 minutes in half of searches and within 9 minutes in 9 of 10. More can arrive until the final report, typically about 10 minutes after the start (9 of 10 within 15). Its status and results are read with fetch_leads, with the same jobId at any later time. Hosts that render MCP Apps show a live card that follows the search and lists leads as they arrive. `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. | Destructive |
| get_campaign | Returns 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. | Read-only |
| get_campaign_leads | Returns 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. A lead carries `signal` only when the search asked for a need signal. | Read-only |
| get_campaign_stats | Returns 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'. | Read-only |
| get_lead_memo | Returns 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. | Read-only |
| list_campaigns | Lists 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. | Read-only |
| list_next_steps | Returns 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. | Read-only |
| list_pending_outreach | Lists 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. Without campaignId, the list covers every campaign in this workspace that the user takes part in. This tool sends nothing: rewrite_outreach replaces a draft's text, and send_outreach queues one for delivery. | Read-only |
| list_replies | Returns 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. | Read-only |
| preview_shortlist | Prepares a preview of 1–50 selected prospects from a campaign the user takes part in, and publishes nothing. The snapshot holds a list title, which is the campaign's name, the note, and for each person only a name, role, company, LinkedIn profile and, when includeRationale is true, a fit rating and why-matched explanation. The preview returns the complete snapshot a link would expose, with the previewKey that create_shortlist requires; a created link stays viewable for 30 days by anyone who has it, and can be revoked with revoke_shortlist. | Read-only |
| revoke_shortlist | Revokes 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. | Destructive |
| rewrite_outreach | Replaces 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. | Destructive |
| send_outreach | Queues 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. | Destructive |
Change history
- get_campaign_leads: input schema changed
- get_campaign_leads: description changed (+"A lead carries `signal` only when the search asked for a need signal.")
- fetch_leads: input schema changed
- fetch_leads: description changed (+"A lead has `signal` (status verified, inferred or none, plus a one-sentence summary) only when the search asked for a")
- server instructions changed (+"When a lead has `signal`, show its status and summary beside the lead: it says whether the signal the user asked for was found. When `fetch_leads` returns `refinements`, offer them to the user after the leads and do not run them unasked." -"via `rewrite_outreach`, show the user the result, and only then `send_outreach` with their explicit go-ahead. Never invent a fact about a person; if there is no memo, say so and keep the message honest. GROWING OR STEERING A COHORT: use `continue_campaign`, not")
| Source | Listing | First seen | Last seen | Versions |
|---|---|---|---|---|
| Official MCP Registry | ai.onsa/onsa | 2 Oct 2026 | 7 Oct 2026 | 1 |