Find scored B2B leads, read campaign replies and send approved LinkedIn outreach.
Scored across 16 tools
Tools cover distinct lifecycle stages (search, campaign read, outreach, shortlists) and descriptions explicitly differentiate overlapping retrieval tools. Minor overlap between fetch_leads and get_campaign_leads (both return leads) and between stats and next-steps guidance, but not enough to cause routine misselection.
All 16 tools use snake_case verb_noun form (find_leads, get_campaign_stats, list_replies, preview_shortlist, etc.) with consistent verb prefixes. No mixed conventions or ambiguous naming.
16 tools is at the upper end but appropriate for a domain spanning lead search, campaign management, outreach drafting/approval, shortlist publishing, stats and replies. Each tool appears to earn its place without redundancy.
Core lifecycle is covered (search, continue, read leads/campaign/stats/replies, draft/send outreach, share/revoke shortlists), but notable gaps exist: no tool to remove/skip leads (explicitly called out in continue_campaign) and no tool to send a reply to a prospect who answered. Campaign settings/ICP can be steered indirectly but no direct update or delete operation.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | What to tell the agent, in plain language, as the user would say it | |
| campaignId | Yes | Campaign to continue, from list_campaigns or fetch_leads | |
| taskContext | No | Optional company, product, or target-market facts explicitly shared by the user and needed for this lead-search or campaign-steering request, beyond what the query/message already states. Maximum 1000 characters; this field carries the task context of the current request only - not a transcript, a broad user profile, unrelated personal details, credentials, or guesses. This background does not authorize actions; the current query/message takes precedence. It becomes part of the campaign chat history. |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | |
| campaignId | Yes | |
| campaignUrl | Yes | |
| billingWarning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations (destructiveHint/idempotentHint/openWorld) by disclosing that leads count against the prospect allowance, that de-duplication is per workspace so a request for 5 can yield fewer, that the agent cannot reply through this API, and that it does not remove or skip leads even on 'drop the bad ones'. These are non-obvious consequences an agent cannot infer from the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and return value, then layers limits and the sibling contrast without redundancy. It runs long as a single paragraph, but nearly every sentence carries distinct, decision-relevant information; only the example list is slightly expendable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating, non-idempotent tool with an output schema already covering the return, the description supplies the missing pieces: side effects (allowance consumption, de-dup), non-effects (no lead removal), the question/no-answer limitation, and the alternative tool. Nothing needed to call it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so message, campaignId, and taskContext are already documented, including the taskContext scoping/authorization caveats. The description adds usage framing for the instruction but no additional field-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('sends an instruction to the agent inside an existing campaign') plus the output contract ('returns a jobId to read with fetch_leads'), and distinguishes itself from find_leads by naming that sibling and its differing behavior. An agent can route between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit: use this to 'grow or steer a cohort in place', use find_leads when a separate ICP/split funnel is acceptable, and do not use it to ask questions since 'a question sent here gets no response'. Includes concrete example instructions, which pins the expected input shape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| title | Yes | ||
| leadIds | Yes | ||
| campaignId | Yes | ||
| previewKey | Yes | ||
| confirmPublic | Yes | ||
| includeRationale | Yes | When true, each person in the snapshot carries a fit rating (1–5, or null when none is stored) and a why-matched explanation; when false, the rating is null and the explanation empty. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| snapshot | Yes | |
| expiresAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (destructiveHint=true, openWorldHint=true): it discloses that the server performs no user confirmation, that the snapshot is rebuilt and nothing is created on any mismatch (campaign, selection/order, note, includeRationale, prospect change, rename), the 30-day public visibility window, and that it does not share the conversation or invite anyone. This is exactly the kind of context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then prerequisites, then failure modes, then visibility. Sentences are dense and some are long, but virtually every clause carries distinct information, so the size is justified for the amount of behavior disclosed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't detail return fields, yet it still names URL, list id and expiry and notes that sending the link onward is a separate user action. Combined with the failure-mode list and revocation pointer, an agent has everything needed to call this mutating, open-world tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, so the description must compensate, and it does: it explains that previewKey comes from preview_shortlist, that confirmPublic records the caller's confirmation rather than prompting the user, and that note/leadIds order/campaignId participate in the snapshot-match check. includeRationale's meaning is left to the schema, keeping this short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Publishes') and resource ('a preview_shortlist snapshot as a link') and names the sibling previews (preview_shortlist, revoke_shortlist) it relates to. An agent can distinguish it from the read-only preview and the revoke tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Makes the prerequisite explicit (requires the previewKey that preview_shortlist returned plus confirmPublic: true) and points to revoke_shortlist for undoing the link. It doesn't give an explicit 'when not to use this' statement, but the gating condition is clear enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The jobId returned by find_leads | |
| limit | No | How many leads to return (default 100) |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | |
| leads | Yes | |
| total | Yes | |
| status | Yes | One of "pending", "completed", "stalled"; more values may be added later. `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. |
| newLeads | Yes | |
| progress | Yes | |
| returned | Yes | |
| campaignId | Yes | |
| campaignUrl | Yes | |
| agentMessage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnly/idempotent annotations, detailing the exact status state machine, partial lead results, 35-second poll waits, agentMessage filtering quirks, and the fact that the agent cannot be replied to through this API. This is rich behavioral disclosure that materially helps an agent use the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long, but the length is justified by the complexity of the job-state semantics. It is front-loaded with a clear one-sentence purpose and organized into status, output fields, and timing behavior. It could be tightened with headers, but every sentence carries meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with this much behavioral nuance, the description is remarkably complete: it covers status transitions, timing distributions, output fields, edge cases, polling behavior, and caveats like null agentMessage. Even with an output schema present, the description adds indispensable context an agent needs to interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context by explaining that jobId can come from either find_leads or continue_campaign, but it does not substantially add meaning to the limit parameter beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns the status and any results of a find_leads or continue_campaign job, by jobId.' This clearly identifies what the tool does and differentiates it from the sibling launch tools find_leads and continue_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that fetch_leads is the polling/status tool for find_leads and continue_campaign jobs, and explains the job lifecycle and wait behavior. It does not explicitly state 'use this instead of X' the way the calibration high example does, but the context strongly implies when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many leads to find (default 5) | |
| query | Yes | Natural-language lead brief, e.g. 'find 5 fintech founders in NYC' | |
| taskContext | No | Optional company, product, or target-market facts explicitly shared by the user and needed for this lead-search or campaign-steering request, beyond what the query/message already states. Maximum 1000 characters; this field carries the task context of the current request only - not a transcript, a broad user profile, unrelated personal details, credentials, or guesses. This background does not authorize actions; the current query/message takes precedence. It becomes part of the campaign chat history. |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | |
| progress | Yes | |
| campaignId | Yes | |
| campaignUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructive/openWorld/non-idempotent, and the description goes well beyond them: async background execution that continues after the conversation moves on, concrete latency expectations (first leads within 5 min in half of searches, final report ~10 min after start), and the critical cost disclosure that every lead found counts against the workspace's prospect allowance. This is exactly the behavioral context an agent needs before triggering a costly, destructive search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what the tool does and its return value, then layers timing, cost, and the limit caveat. It is long but nearly every sentence adds decision-relevant detail; a slight trim of the latency statistics would tighten it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the async lifecycle, the sibling used to read results, the immediate return (jobId, campaignUrl, progress), latency expectations, quota impact, and UI behavior on MCP Apps hosts. With an output schema present, no further return-value explanation is required, so the definition is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds genuine meaning about `limit`: it is a target the agent aims at rather than a hard cap, so results may exceed it. The query and taskContext semantics are left to the schema, which documents them thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('starts a live B2B lead search'), the population it targets (real people with LinkedIn profiles matched to the workspace ICP), and how it differs from siblings by noting status/results are read via fetch_leads. An agent can distinguish it from get_campaign_leads or list_campaigns without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to fetch_leads with the same jobId for reading status and results, and frames the tool as the initiation step. It lacks an explicit when-not-to-use clause (e.g. don't re-run for an existing job), so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | Campaign id, as returned by list_campaigns or fetch_leads |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| icp | Yes | |
| tags | Yes | |
| title | Yes | |
| createdAt | Yes | |
| updatedAt | Yes | |
| leadsTotal | Yes | |
| campaignUrl | Yes | |
| leadsApprove | Yes | |
| outreachTemplate | Yes | |
| outreachAutoApprove | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral context: data returns exactly as stored in snake_case, the summary strings are not scoring criteria, no key is guaranteed present, and it explains how to interpret outreachTemplate personalization. This goes well beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence contributes meaning: it explains the main purpose, the structure of the ICP, clarifies which fields drive scoring, warns about missing keys, and interprets the outreach template. It is front-loaded with the primary purpose and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested ICP structure with critical/preferential rules), the description thoroughly explains the semantics and caveats. Since an output schema exists, it doesn't need to describe return values, but it explains how to interpret the data. Nothing an agent needs to decide when to call it or understand its output is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already fully documents campaignId with format and description. The description does not add any additional parameter-specific meaning, so the baseline of 3 applies. No extra compensation needed since coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns one campaign's ICP - the ideal-customer profile... plus its outreach template and settings.' It clearly distinguishes the tool's scope from siblings that return leads or stats. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context—when you need the ICP and outreach settings, use this tool. However, it does not explicitly mention alternatives or conditions where another sibling (e.g., get_campaign_leads) would be more appropriate. It provides clear context but lacks explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many leads to return (default 50) | |
| leadIds | No | Optional; when set, only these leads are returned, e.g. positiveLeadIds from get_campaign_stats | |
| campaignId | Yes | Campaign id, as returned by list_campaigns or fetch_leads |
| Name | Required | Description |
|---|---|---|
| leads | Yes | |
| total | Yes | |
| returned | Yes | |
| campaignId | Yes | |
| campaignUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context beyond them: cross-session reachability, output-field parity with fetch_leads, and the get_campaign_stats bucket-resolution use of leadIds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose in the first clause, then differentiation against fetch_leads, then the leadIds workflow tip. Tightly written with little waste, though the 'same fields as fetch_leads, including score and scoreExplanation' clause is mildly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A read-only, 3-parameter tool with a full schema, an output schema, and complete annotations is well-covered by this description. The cross-session caveat and sibling differentiation are the key additions; nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description goes slightly beyond the schema by explaining what leadIds accomplishes in workflow terms ('resolves the reply buckets from get_campaign_stats back into named people'), adding use-case meaning beyond the schema's raw field documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the leads of any campaign by campaignId') and immediately distinguishes itself from the sibling fetch_leads by scope. An agent can tell what it does and how it differs from fetch_leads without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the selecting condition: it 'covers campaigns not started in this session, which fetch_leads cannot reach,' and explains why (fetch_leads requires a same-session jobId). This effectively routes the agent to the right tool, though it does not state explicit when-not conditions or mention the other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | Campaign id, as returned by list_campaigns or fetch_leads |
| Name | Required | Description |
|---|---|---|
| rates | Yes | |
| responses | Yes | |
| campaignId | Yes | |
| leadsTotal | Yes | |
| campaignUrl | Yes | |
| invitesSent | Yes | |
| messagesSent | Yes | |
| invitesAccepted | Yes | |
| invitesScheduled | Yes | |
| messagesScheduled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds extensive behavioral nuance: de-duplication by lead, rates computed over their own denominators, nulls when denominator is zero, sentiment evaluated once per lead ever, and the meaning of all-zero results. It also clarifies that 'LinkedIn reactions' actually refers to replies because Onsa stores no likes. This goes far beyond annotations, fully disclosing the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and dense, but every sentence contributes unique behavioral insight. It opens with a crisp one-sentence summary, then systematically addresses edge cases and clarifications. It is well-structured and front-loaded with the core purpose. While it could be trimmed slightly, the complexity of the data justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is exhaustive for a read-only stats tool. It covers return structure, de-duplication logic, rate denominators, null semantics, the difference between counts and actions, scheduled counts, sentiment evaluation, and the all-zero case. The output schema exists but the description enriches it with practical interpretation. Nothing an agent needs to correctly interpret the returned data is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, campaignId, is already well described in the schema: 'Campaign id, as returned by list_campaigns or fetch_leads.' The description adds no additional parameter-specific meaning. Since schema description coverage is 100%, the baseline of 3 applies; the description is not required to compensate, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the exact output: 'Returns the outreach funnel for one campaign: invites sent, invites accepted, messages sent, and replies split into positive / negative / other by sentiment.' It uses a specific verb ('returns') and a precise resource ('one campaign'). It also distinguishes itself from list_replies by noting that tool returns text while this one counts, which differentiates it from a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong contextual guidance by contrasting with list_replies: 'list_replies returns their text, and this tool only counts them.' It also explains why counts may differ from the Overview widget, helping agents choose the right tool. However, it does not explicitly state 'use this instead of X when you need aggregate counts,' but the guidance is clear enough for a competent agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| leadId | Yes | Lead to read, from any tool that returns leads |
| Name | Required | Description |
|---|---|---|
| memo | Yes | |
| name | Yes | |
| leadId | Yes | |
| companyName | Yes | |
| memoWrittenAt | Yes | |
| scoreExplanation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds critical behavioral context beyond annotations: most leads have no memo, so a null return is common and not an error, and it clarifies the source of the memo (Onsa's agent). This is valuable and does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, using three sentences that each add distinct value: content of the memo, comparison to scoreExplanation, and the null-return behavior. No fluff or redundant phrasing; the most critical information (memo content and null case) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return format is not needed. The description covers the tool's purpose, contents, typical null behavior, and relationship to the alternative source. Nothing an agent needs to invoke it correctly or interpret results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter leadId, which already explains it is the lead to read. The description adds the hint 'from any tool that returns leads', which is mildly helpful but does not substantially alter parameter meaning. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Returns the research memo' about one lead, and enumerates its contents (role history, company size/stage, public statements, angle). It clearly distinguishes itself from scoreExplanation by noting it is 'usually far richer' and serves as the basis for fact-based outreach. This differentiates it from sibling tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it: for building outreach on a specific, checkable fact, and notes it is richer than scoreExplanation. It also states that when no memo exists (common case), scoreExplanation is the fallback. This gives clear context and implies alternatives, though it does not explicitly name a sibling tool or a hard 'when not to use' condition, so it loses one point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many campaigns to return, newest first (default 50) |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| returned | Yes | |
| campaigns | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond that: newest-first ordering, default limit and returned/total omission signal, field list, and the caveat that a campaign row exists as soon as a search starts and is often empty with leadsTotal 0. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main action is front-loaded in the first sentence, and each subsequent sentence adds useful operational detail (limit behavior, fields, follow-up routing, cohort identification, empty newest rows) without fluff. Length is justified for a central list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with an output schema and strong annotations, the description covers scope, ordering, limit semantics, return fields, caveats, and downstream tool usage. Nothing an agent needs to select or invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains limit and its default. The description adds the returned/total consequence of limiting, but this is primarily output behavior, so it only marginally enriches the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb ('Lists'), resource ('campaigns (past lead searches)'), and scope ('in this workspace that the user takes part in'), plus ordering ('newest first'). It clearly separates this from sibling detail tools by naming what an id can be used for next.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly maps follow-up tools to their purposes ('get_campaign for its ICP, get_campaign_leads for its people...') and warns that generic MCP titles make title unreliable, telling the agent how to interpret results. This is more than clear context; it routes to alternatives by need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | No | Optional campaign to inspect; omitted for workspace guidance |
| Name | Required | Description |
|---|---|---|
| note | No | |
| items | Yes | |
| scope | No | |
| total | No | |
| returned | No | |
| campaigns | No | |
| campaignId | No | |
| leadsTotal | No | |
| nextAction | No | |
| campaignUrl | No | |
| workspaceUrl | No | |
| campaignTitle | No | |
| workspaceState | No | |
| searchAvailability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds substantial context beyond that: caveats about the 'replied' bucket being a floor, Onsa not recording whether we replied or whether someone was contacted outside Onsa, withdrawn/unreachable invites leaving no trace, sentiment judged once per lead, counts complete, and leadIds capped at 200. This is exactly the kind of behavioral detail that prevents an agent from over-trusting the data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each clause earns its place: mode behavior, sibling differentiation, reply-bucket caveat, data limitations, and caps. It is front-loaded with the core purpose before branching into details, and the information is tightly packed without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, an output schema, and annotations already covering safety, the description is complete: it explains both invocation modes, the meaning of returned buckets, how to get more detail, and the known data limits. No gap remains that would prevent an agent from invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% for the single optional campaignId, the description adds meaning far beyond the schema: it explains that omitting campaignId returns workspace-level guidance (first-search question, progress, campaign names/statuses) and that a single accessible campaign resolves automatically, while providing campaignId returns a ranked campaign-specific to-do list. This substantially informs parameter choice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns read-only guidance for what to do next.' It clearly differentiates itself from siblings by stating that get_campaign_stats answers 'how is it doing' and list_replies is better for replies specifically. The two conditional modes (with and without campaignId) are crisply delineated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: it answers 'what should I do about this campaign today' versus get_campaign_stats for 'how is it doing', and explicitly recommends list_replies for reply-specific needs because its `awaitingOurReply` compares timestamps. It also tells the agent to pass `leadIds` to get_campaign_leads to resolve buckets into named people, which is actionable routing to an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many drafts to return (default 50) | |
| campaignId | No | One campaign to limit the list to; when omitted, the list covers every campaign the user takes part in |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| pending | Yes | |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it is explicitly non-sending and points to rewrite_outreach/send_outreach for the mutating paths. Return-format detail is left to the output schema, which is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core purpose before the scoping rule and the disambiguation. No filler, though the sibling callout sentence is slightly compressed in a way that reads as two thoughts stapled together.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema and annotations are rich, and the description covers the remaining gaps: what the queue means, default scoping, and that the tool is read-only relative to its write siblings. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including campaignId's omit-to-list-all behavior. The description restates that behavior but adds no syntax, format, or default detail (e.g. limit) beyond the schema. Baseline 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('lists outreach messages the agent has drafted') and pins down the exact concept via the 'a message for X is ready' queue. An agent can distinguish this from list_replies or list_next_steps without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains scoping explicitly ('Without campaignId, the list covers every campaign in this workspace') and names the two sibling tools that perform writes, clarifying this one does not. It stops short of stating when an agent should prefer this over e.g. list_replies, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum replies to return, newest first (default 50) | |
| campaignId | Yes | Campaign to read replies from |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| returned | Yes | |
| campaignId | Yes | |
| campaignUrl | Yes | |
| campaignTitle | Yes | |
| conversations | Yes | |
| awaitingOurReplyCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context: the semantics of sentiment null (unscored vs neutral), the structural nature of awaitingOurReply (only sees Onsa-sent messages, hand-made replies invisible), daysSinceLastReply as elapsed days even if answered, looksLikeBroadcast as a floor not verdict, and top-level count spanning the whole campaign with exclusions. This far exceeds the minimal annotation coverage and clarifies subtle data interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place, explaining nuanced semantics that an agent must understand to interpret results correctly. It is front-loaded with the core purpose, then systematically explains the three derived fields and the top-level count, using clear structure. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't restate return structure. It covers edge cases (unscored replies, hand-made replies, broadcast detection limits, daysSinceLastReply semantics) and clarifies the meaning of derived fields and the top-level counter. For a read-only tool with rich output semantics, this is complete for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters fully documented (limit with default and ordering, campaignId with format). The description adds no new parameter-level semantics beyond what the schema already provides, so the baseline of 3 is appropriate. It does mention the interaction between limit and the top-level count, but that pertains to output behavior rather than parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: returns reply text paired with the outbound message, and explicitly contrasts with get_campaign_stats which counts replies. The verb 'returns' and resource 'reply text' are specific, and the sibling differentiation is explicit, leaving no ambiguity about purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct guidance on when to use this tool versus get_campaign_stats, noting that this returns the words while the sibling counts and labels. It also explains when this tool may return more replies than the funnel counts, clarifying its scope and limitations relative to the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| title | Yes | ||
| leadIds | Yes | ||
| campaignId | Yes | ||
| includeRationale | Yes | When true, each person in the snapshot carries a fit rating (1–5, or null when none is stored) and a why-matched explanation; when false, the rating is null and the explanation empty. |
| Name | Required | Description |
|---|---|---|
| snapshot | Yes | |
| previewKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the bar is lower, yet the description adds real behavior: no publication occurs, the snapshot's exact field set, the conditional rationale fields, and the 30-day public viewability of a resulting link. It stops short of stating auth or rate-limit expectations, but the added context is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and the 'publishes nothing' constraint, then details the payload and the downstream key. Dense but every clause carries information; only the snapshot field enumeration could be trimmed since the output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be described, yet the description still outlines the snapshot contents and ties the output to create_shortlist, giving the agent enough to chain calls. Missing only edge details such as length limits and campaignId ownership semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (includeRationale alone is documented), so the description carries most of the burden and does so reasonably: it pins leadIds to the 1–50 range, explains title as the campaign's name and note as the snapshot note, and restates includeRationale's effect. It omits the title/note length limits that the schema enforces, which keeps it below 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Prepares a preview') and resource ('1–50 selected prospects from a campaign'), and immediately distinguishes itself from the write path by noting it 'publishes nothing'. An agent can tell this apart from create_shortlist and revoke_shortlist without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Makes the preview→create workflow explicit by saying the result contains 'the previewKey that create_shortlist requires', and names revoke_shortlist as the undo path for the link that a later create produces. It doesn't spell out a when-not-to-use condition, but the create/preview split is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| revoked | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true already declared, the description adds real operational context: effect is immediate ('Future views stop immediately') and irreversible for already-copied content ('previously copied or downloaded information cannot be recalled'), plus an authorization constraint (creator-only). It doesn't address idempotent re-calls despite idempotentHint=true, so it stops short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the core action first, then preconditions, then consequences. No padding, no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation; the description covers the id's provenance, the authorization requirement, and the destructive/irreversible effects, which is everything an agent needs to invoke this single-parameter mutation correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate; it does by telling the agent the id originates from create_shortlist rather than being an arbitrary UUID, which is the one non-obvious fact about a single required uuid parameter. It adds no validation or format detail beyond the schema pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Revokes a list link') and anchors it to a sibling ('the id create_shortlist returned'), so an agent can distinguish it from create_shortlist and preview_shortlist without reading either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies a precondition ('only the user who created the link can revoke it') which implies who may call it, but never states when to reach for this tool versus siblings such as create_shortlist or preview_shortlist, nor any when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 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. | |
| leadId | Yes | Lead whose draft to rewrite, from list_pending_outreach | |
| subject | No | Email subject; only email delivery reads it, and send_outreach, a LinkedIn send, does not. When omitted, the stored subject stays unchanged, so a body-only edit keeps it; a string replaces it, and null clears it. |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| leadId | Yes | |
| subject | Yes | |
| updated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations flag destructiveHint=true and idempotentHint=true; the description adds substantive context: the draft 'stays in the approval queue' and 'this tool sends nothing', clarifying the side effect boundary. It does not explain what 'destructive' means here (e.g., does it overwrite unsaved edits?) or auth requirements, but it goes beyond raw annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the action and scope. Every clause earns its place by connecting sibling tools or clarifying side effects; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be explained. The description is complete enough for correct invocation, though it could note whether rewriting requires the draft to be in a specific state or whether concurrent edits are overwritten.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description itself adds little parameter detail, though the schema's own descriptions (notably the three-name aliasing of 'text') already handle semantics thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('replaces the text of an outreach draft') with a precise scope qualifier ('that is waiting for approval'). This distinguishes it from send_outreach (sends) and list_pending_outreach (reads), making sibling differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly situates the tool in the workflow: drafts come from list_pending_outreach, richer research from get_lead_memo. Implies when to use (editing a queued draft) but does not explicitly state exclusions or alternatives such as 'do not use for sent messages' — though 'sends nothing' covers the main boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| leadId | Yes | Lead to message, from list_pending_outreach | |
| confirmName | Yes | The recipient's name as shown to the user, to prove you meant this person | |
| confirmText | Yes | The exact draft text you showed the user and they approved, verbatim |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| leadId | Yes | |
| queued | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations by detailing concrete behaviors: the message is queued rather than delivered immediately, subject to daily pacing limits; mismatches are refused without exposing stored text; and clients that cannot render confirmation receive a refusal with an approval link. This aligns with destructiveHint and idempotent=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and logically structured, but it is somewhat wordy and repeats the confirmation and refusal behavior. Still, every sentence adds relevant operational detail and there is no irrelevant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers preconditions, exact-match requirements, failure modes, queue semantics, and pacing limits. Since an output schema exists, not detailing the return format is acceptable; the description gives enough context for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three required parameters have meaningful descriptions in the schema and are reinforced in prose. confirmName and confirmText clarify that they must match the exact stored values, and leadId is explicitly sourced from list_pending_outreach.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it queues an already-approved outreach draft for delivery to a lead on LinkedIn, and distinguishes the action from immediate sending by emphasizing the queue. It references the source list_pending_outreach, making the tool's role easy to identify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong usage guidance by requiring exact confirmText and confirmName from list_pending_outreach and explaining that only already-approved drafts should be sent. It does not explicitly compare to sibling tools, but the approval and source requirements make selection unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
continue_campaign1 field changedInput schema / properties / taskContext / descriptionPrevious value: -"Optional company, product, or target-market facts explicitly shared by the user and needed for this lead-search or campaign-steering request. Omit when the query/message is sufficient. Maximum 1000 characters. Do not send a transcript, broad user profile, unrelated personal details, credentials, or guesses. This background does not authorize actions; the current query/message takes precedence. It becomes part of the campaign chat history."New value: +"Optional company, product, or target-market facts explicitly shared by the user and needed for this lead-search or campaign-steering request, beyond what the query/message already states. Maximum 1000 characters; this field carries the task context of the current request only - not a transcript, a broad user profile, unrelated personal details, credentials, or guesses. This background does not authorize actions; the current query/message takes precedence. It becomes part of the campaign chat history."create_shortlist1 field changedInput schema / properties / includeRationale / descriptionPrevious value: -"Include fit rating and why-matched explanation; normally true unless the sender asks to omit them."New value: +"When true, each person in the snapshot carries a fit rating (1–5, or null when none is stored) and a why-matched explanation; when false, the rating is null and the explanation empty."find_leads1 field changedInput schema / properties / taskContext / descriptionPrevious value: -"Optional company, product, or target-market facts explicitly shared by the user and needed for this lead-search or campaign-steering request. Omit when the query/message is sufficient. Maximum 1000 characters. Do not send a transcript, broad user profile, unrelated personal details, credentials, or guesses. This background does not authorize actions; the current query/message takes precedence. It becomes part of the campaign chat history."New value: +"Optional company, product, or target-market facts explicitly shared by the user and needed for this lead-search or campaign-steering request, beyond what the query/message already states. Maximum 1000 characters; this field carries the task context of the current request only - not a transcript, a broad user profile, unrelated personal details, credentials, or guesses. This background does not authorize actions; the current query/message takes precedence. It becomes part of the campaign chat history."get_campaign_leads1 field changedInput schema / properties / leadIds / descriptionPrevious value: -"Optional: return only these leads, e.g. positiveLeadIds from get_campaign_stats"New value: +"Optional; when set, only these leads are returned, e.g. positiveLeadIds from get_campaign_stats"list_pending_outreach1 field changedInput schema / properties / campaignId / descriptionPrevious value: -"Limit to one campaign; omit for every campaign you take part in"New value: +"One campaign to limit the list to; when omitted, the list covers every campaign the user takes part in"preview_shortlist1 field changedInput schema / properties / includeRationale / descriptionPrevious value: -"Include fit rating and why-matched explanation; normally true unless the sender asks to omit them."New value: +"When true, each person in the snapshot carries a fit rating (1–5, or null when none is stored) and a why-matched explanation; when false, the rating is null and the explanation empty."rewrite_outreach1 field changedInput schema / properties / subject / descriptionPrevious value: -"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."New value: +"Email subject; only email delivery reads it, and send_outreach, a LinkedIn send, does not. When omitted, the stored subject stays unchanged, so a body-only edit keeps it; a string replaces it, and null clears it."fetch_leads2 fields changedInput schema / properties / jobId / descriptionPrevious value: -"The jobId returned by find_leads — never invent one"New value: +"The jobId returned by find_leads"Output schema / properties / status / descriptionPrevious value: -"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 polling). Treat an unrecognised value as pending."New value: +"One of \"pending\", \"completed\", \"stalled\"; more values may be added later. `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."get_campaign1 field changedInput schema / properties / campaignId / descriptionPrevious value: -"Campaign id from list_campaigns or fetch_leads — never invent one"New value: +"Campaign id, as returned by list_campaigns or fetch_leads"get_campaign_leads1 field changedInput schema / properties / campaignId / descriptionPrevious value: -"Campaign id from list_campaigns or fetch_leads — never invent one"New value: +"Campaign id, as returned by list_campaigns or fetch_leads"get_campaign_stats1 field changedInput schema / properties / campaignId / descriptionPrevious value: -"Campaign id from list_campaigns or fetch_leads — never invent one"New value: +"Campaign id, as returned by list_campaigns or fetch_leads"continue_campaign1 field changedInput schema / properties / taskContextAdded value: +{
+ "description": "Optional company, product, or target-market facts explicitly shared by the user and needed for this lead-search or campaign-steering request. Omit when the query/message is sufficient. Maximum 1000 characters. Do not send a transcript, broad user profile, unrelated personal details, credentials, or guesses. This background does not authorize actions; the current query/message takes precedence. It becomes part of the campaign chat history.",
+ "maxLength": 1000,
+ "type": "string"
+}find_leads1 field changedInput schema / properties / taskContextAdded value: +{
+ "description": "Optional company, product, or target-market facts explicitly shared by the user and needed for this lead-search or campaign-steering request. Omit when the query/message is sufficient. Maximum 1000 characters. Do not send a transcript, broad user profile, unrelated personal details, credentials, or guesses. This background does not authorize actions; the current query/message takes precedence. It becomes part of the campaign chat history.",
+ "maxLength": 1000,
+ "type": "string"
+}create_shortlistpreview_shortlistrevoke_shortlistlist_next_steps12 fields changedInput schema / properties / campaignId / descriptionPrevious value: -"Campaign to inspect, from list_campaigns or fetch_leads"New value: +"Optional campaign to inspect; omitted for workspace guidance"Input schema / requiredRemoved value: -[
- "campaignId"
-]Output schema / properties / campaignsAdded value: +{
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "campaignUrl": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "leadsTotal": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "status": {
+ "enum": [
+ "search_running",
+ "prospects_available",
+ "no_prospects"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "leadsTotal",
+ "status",
+ "campaignUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / nextActionAdded value: +{
+ "additionalProperties": {},
+ "properties": {
+ "arguments": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "count": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "question": {
+ "type": "string"
+ },
+ "reuseAuthorizedBrief": {
+ "type": "boolean"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind"
+ ],
+ "type": "object"
+}Output schema / properties / noteAdded value: +{
+ "type": "string"
+}Output schema / properties / returnedAdded value: +{
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / scopeAdded value: +{
+ "enum": [
+ "workspace",
+ "campaign"
+ ],
+ "type": "string"
+}Output schema / properties / searchAvailabilityAdded value: +{
+ "additionalProperties": {},
+ "properties": {
+ "allowance": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "limit": {
+ "type": "number"
+ },
+ "remaining": {
+ "type": "number"
+ },
+ "used": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "used",
+ "limit",
+ "remaining"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "enum": [
+ "available",
+ "blocked",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "reason",
+ "allowance"
+ ],
+ "type": "object"
+}Output schema / properties / totalAdded value: +{
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / workspaceStateAdded value: +{
+ "type": "string"
+}Output schema / properties / workspaceUrlAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "campaignId",
- "campaignTitle",
- "campaignUrl",
- "leadsTotal",
- "items"
-]New value: +[
+ "items"
+]fetch_leads2 fields changedOutput schema / properties / progressAdded value: +{
+ "additionalProperties": {},
+ "properties": {
+ "elapsedSeconds": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "startedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "startedAt",
+ "elapsedSeconds",
+ "note"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "jobId",
- "status",
- "total",
- "returned",
- "newLeads",
- "campaignId",
- "campaignUrl",
- "agentMessage",
- "leads"
-]New value: +[
+ "jobId",
+ "status",
+ "total",
+ "returned",
+ "newLeads",
+ "campaignId",
+ "campaignUrl",
+ "agentMessage",
+ "progress",
+ "leads"
+]find_leads4 fields changedOutput schema / properties / campaignIdAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / campaignUrlAdded value: +{
+ "type": "string"
+}Output schema / properties / progressAdded value: +{
+ "additionalProperties": {},
+ "properties": {
+ "elapsedSeconds": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "startedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "startedAt",
+ "elapsedSeconds",
+ "note"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "jobId"
-]New value: +[
+ "jobId",
+ "campaignId",
+ "campaignUrl",
+ "progress"
+]fetch_leads2 fields changedOutput schema / properties / status / descriptionAdded value: +"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 polling). Treat an unrecognised value as pending."Output schema / properties / status / enumRemoved value: -[
- "pending",
- "completed"
-]continue_campaignfetch_leadsfind_leadsget_campaignget_campaign_leadsget_campaign_statsget_lead_memolist_campaignslist_next_stepslist_pending_outreachlist_repliesrewrite_outreachsend_outreachFind, qualify and message B2B leads from public LinkedIn data; every send is human-approved.
LinkedIn + cold email outreach: find leads, launch personalized campaigns, manage replies.
Run LinkedIn outreach from your AI chat: find leads, launch campaigns, send, and reply.
Build prospecting lists from buying signals, enrich them, and run LinkedIn outreach.
Add one secure layer between your agents and this server.
