# Onsa (remote · api.onsa.ai)

Find scored B2B leads, read campaign replies and send approved LinkedIn outreach.

- Trust score: 85/100 (high trust)
- Change this week: +5
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- remote · `api.onsa.ai`: 85/100 (this document), [markdown](https://verifymcp.io/servers/ai-onsa-onsa/api-mcp.md), [page](https://verifymcp.io/servers/ai-onsa-onsa/api-mcp)

## Channel facts

- Endpoint: `https://api.onsa.ai/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## 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-20.

- **Endpoint Security**: 94/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without 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.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 78/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 4173 tokens (~298/item across 14 items; 13 tools + 1 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 40/100
  - Stability observed for 12 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.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 15 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).
  - Supports UI / widget rendering.

## Install

### How do I install the Onsa MCP server?

Onsa is a hosted endpoint at https://api.onsa.ai/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 ai-onsa-onsa 'https://api.onsa.ai/api/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "ai-onsa-onsa": {
      "url": "https://api.onsa.ai/api/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "ai-onsa-onsa": {
      "type": "http",
      "url": "https://api.onsa.ai/api/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.ai-onsa-onsa]
url = "https://api.onsa.ai/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-onsa-onsa": {
      "type": "remote",
      "url": "https://api.onsa.ai/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ai-onsa-onsa --url 'https://api.onsa.ai/api/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ai-onsa-onsa:
    url: "https://api.onsa.ai/api/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "ai-onsa-onsa": {
      "Transport": "http",
      "Url": "https://api.onsa.ai/api/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add ai-onsa-onsa -t streamable-http -u 'https://api.onsa.ai/api/mcp'
```

### Other

```json
{
  "mcpServers": {
    "ai-onsa-onsa": {
      "type": "http",
      "url": "https://api.onsa.ai/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-20 (score 85, +2)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “fetch_leads” rewrote its description, which is the text the model reads
- [security] Tool “find_leads” rewrote its description, which is the text the model reads
- [functional] The server now declares the “resources” capability
- [functional] First check of Capabilities: pass
- [functional] First check of Schema quality: 100
- [functional] New resource “lead-search-card”

### 2026-09-19 (score 83, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-17 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-15 (score 81, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-13 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-10 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-09 (score 78, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “continue_campaign” rewrote its description, which is the text the model reads
- [security] Tool “fetch_leads” rewrote its description, which is the text the model reads
- [security] Tool “find_leads” 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_campaign_leads” rewrote its description, which is the text the model reads
- [security] Tool “get_campaign_stats” rewrote its description, which is the text the model reads
- [security] Tool “get_lead_memo” rewrote its description, which is the text the model reads
- [security] Tool “list_campaigns” rewrote its description, which is the text the model reads
- [security] Tool “list_next_steps” rewrote its description, which is the text the model reads
- [security] Tool “list_pending_outreach” rewrote its description, which is the text the model reads
- [security] Tool “list_replies” rewrote its description, which is the text the model reads
- [security] Tool “rewrite_outreach” rewrote its description, which is the text the model reads
- [security] Tool “send_outreach” rewrote its description, which is the text the model reads
- [functional improvement] Schema quality: 346 → 302
- [functional improvement] Stability: unverified → 0.03

### 2026-09-08 (score 77)

First indexed and scored.

## MCP tools (13)

### `find_leads` (~214 tokens)

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: first leads usually arrive 5-10 minutes after it starts and most searches complete within 15 minutes, and its status and results are read with fetch_leads. 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.

Input parameters:

- `limit` (integer): How many leads to find (default 5)
- `query` (string, required): Natural-language lead brief, e.g. 'find 5 fintech founders in NYC'

Output parameters:

- `campaignId`
- `campaignUrl` (string)
- `jobId` (string)
- `progress` (object)

### `fetch_leads` (~386 tokens)

Fetch search results

Returns 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. While a search has produced no leads yet, one call waits up to 35 seconds for the first ones before answering, so a call can take that long. `progress` carries startedAt, elapsedSeconds and a note on how long searches usually take. 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.

Input parameters:

- `jobId` (string, required): The jobId returned by find_leads — never invent one
- `limit` (integer): How many leads to return (default 100)

Output parameters:

- `agentMessage`
- `campaignId`
- `campaignUrl` (string)
- `jobId` (string)
- `leads` (array)
- `newLeads`
- `progress` (object)
- `returned` (integer)
- `status` (string): One of: "pending" (search still running), "completed" (a batch of leads arrived — not a promise that no more will), "stalled" (no leads after ~15 minutes; read agentMessage for the reason and stop po…
- `total` (integer)

### `list_campaigns` (~200 tokens)

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.

Input parameters:

- `limit` (integer): How many campaigns to return, newest first (default 50)

Output parameters:

- `campaigns` (array)
- `returned` (integer)
- `total` (integer)

### `get_campaign` (~195 tokens)

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.

Input parameters:

- `campaignId` (string, required): Campaign id from list_campaigns or fetch_leads — never invent one

Output parameters:

- `campaignUrl` (string)
- `createdAt`
- `icp`
- `id` (string)
- `leadsApprove` (boolean)
- `leadsTotal` (integer)
- `outreachAutoApprove` (boolean)
- `outreachTemplate`
- `tags` (array)
- `title` (string)
- `updatedAt`

### `get_campaign_leads` (~150 tokens)

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.

Input parameters:

- `campaignId` (string, required): Campaign id from list_campaigns or fetch_leads — never invent one
- `leadIds` (array): Optional: return only these leads, e.g. positiveLeadIds from get_campaign_stats
- `limit` (integer): How many leads to return (default 50)

Output parameters:

- `campaignId` (string)
- `campaignUrl` (string)
- `leads` (array)
- `returned` (integer)
- `total` (integer)

### `continue_campaign` (~243 tokens)

Steer a 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.

Input parameters:

- `campaignId` (string, required): Campaign to continue, from list_campaigns or fetch_leads
- `message` (string, required): What to tell the agent, in plain language, as the user would say it

Output parameters:

- `billingWarning`
- `campaignId` (string)
- `campaignUrl` (string)
- `jobId` (string)

### `list_pending_outreach` (~128 tokens)

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. Omitting campaignId covers the whole workspace. This tool sends nothing: rewrite_outreach replaces a draft's text, and send_outreach queues one for delivery.

Input parameters:

- `campaignId` (string): Limit to one campaign; omit for every campaign you take part in
- `limit` (integer): How many drafts to return (default 50)

Output parameters:

- `pending` (array)
- `returned` (integer)
- `total` (integer)

### `get_lead_memo` (~136 tokens)

Get lead research 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.

Input parameters:

- `leadId` (string, required): Lead to read, from any tool that returns leads

Output parameters:

- `companyName`
- `leadId` (string)
- `memo`
- `memoWrittenAt`
- `name`
- `scoreExplanation`

### `rewrite_outreach` (~178 tokens)

Rewrite outreach draft

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.

Input parameters:

- `leadId` (string, required): Lead whose draft to rewrite, from list_pending_outreach
- `subject`: Email subject. OMIT it to leave the stored subject untouched (do this for LinkedIn, and whenever you are only changing the body); pass null only if you genuinely mean to clear it.
- `text` (string, required): The full replacement message. This same string is called `draftText` when list_pending_outreach returns it, and `confirmText` when you pass it to send_outreach — three names, one set of bytes.

Output parameters:

- `leadId` (string)
- `subject`
- `text` (string)
- `updated` (boolean)

### `send_outreach` (~244 tokens)

Send outreach message

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.

Input parameters:

- `confirmName` (string, required): The recipient's name as shown to the user, to prove you meant this person
- `confirmText` (string, required): The exact draft text you showed the user and they approved, verbatim
- `leadId` (string, required): Lead to message, from list_pending_outreach

Output parameters:

- `leadId` (string)
- `name`
- `queued` (boolean)

### `list_replies` (~382 tokens)

Read prospect 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.

Input parameters:

- `campaignId` (string, required): Campaign to read replies from
- `limit` (integer): Maximum replies to return, newest first (default 50)

Output parameters:

- `awaitingOurReplyCount` (integer)
- `campaignId` (string)
- `campaignTitle` (string)
- `campaignUrl` (string)
- `conversations` (array)
- `returned` (integer)
- `total` (integer)

### `list_next_steps` (~254 tokens)

What to do next

Returns what this campaign still needs from a human, as 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.

Input parameters:

- `campaignId` (string, required): Campaign to inspect, from list_campaigns or fetch_leads

Output parameters:

- `campaignId` (string)
- `campaignTitle` (string)
- `campaignUrl` (string)
- `items` (array)
- `leadsTotal` (integer)

### `get_campaign_stats` (~386 tokens)

Get campaign funnel

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'.

Input parameters:

- `campaignId` (string, required): Campaign id from list_campaigns or fetch_leads — never invent one

Output parameters:

- `campaignId` (string)
- `campaignUrl` (string)
- `invitesAccepted` (integer)
- `invitesScheduled` (integer)
- `invitesSent` (integer)
- `leadsTotal` (integer)
- `messagesScheduled` (integer)
- `messagesSent` (integer)
- `rates` (object)
- `responses` (object)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/ai-onsa-onsa/api-mcp#diagnostics

## Score history

- 2026-09-20: 85
- 2026-09-19: 83
- 2026-09-18: 82
- 2026-09-17: 82
- 2026-09-16: 81
- 2026-09-15: 81
- 2026-09-14: 80
- 2026-09-13: 80
- 2026-09-12: 79
- 2026-09-11: 79
- 2026-09-10: 79
- 2026-09-09: 78
- 2026-09-08: 77

## Common questions

### What is the Onsa MCP server?

Onsa is an MCP server listed in the public MCP registry as ai.onsa/onsa. Find scored B2B leads, read campaign replies and send approved LinkedIn outreach. This page covers its hosted endpoint (https://api.onsa.ai/api/mcp).

### Is the Onsa MCP server safe to use?

Onsa 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 Onsa MCP server expose?

Onsa exposes 13 tools: find_leads, fetch_leads, list_campaigns, get_campaign, get_campaign_leads, and 8 more. Their descriptions and schemas cost roughly 3,096 tokens of context every time the server is loaded.

### Does the Onsa MCP server require authentication?

Yes. Onsa 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 Onsa MCP server still maintained?

Onsa is still listed as active in the MCP registry. We last reached this channel on 20 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://api.onsa.ai/api/mcp
- Website: https://onsa.ai/mcp
- Changelog RSS feed: https://verifymcp.io/servers/ai-onsa-onsa/api-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/ai-onsa-onsa/api-mcp.json
- HTML version of this page: https://verifymcp.io/servers/ai-onsa-onsa/api-mcp