Skip to main content
Glama

Onsa

Get campaign funnel

get_campaign_stats
Read-onlyIdempotent

Get the outreach funnel for one campaign: invites sent, invites accepted, messages sent, and replies split into positive / negative / other by sentiment. If the user asks to analyse "LinkedIn reactions" they almost certainly mean the REPLIES people sent — use list_replies for the actual text; this tool only counts them. (Onsa stores no post likes or emoji reactions at all.) LinkedIn and email are merged, as in Onsa's Overview page. These count LEADS, not actions — a lead invited twice counts once — so where a lead was re-invited these read slightly lower than the Overview widget, which counts actions. Say so if the user compares the two. IMPORTANT: invitesSent can EXCEED leadsTotal, and that never means anyone was invited twice — the counters are already de-duplicated by lead. It means a lead who was contacted has since been skipped or deleted: action rows survive that, leadsTotal does not count it. Do not report such a gap as a double invite. Use it to judge which ICP cohort actually earned replies. rates already gives you acceptancePct, replyPct, positivePct and negativePct over the correct denominators — use them rather than doing the arithmetic yourself, and never divide by leadsTotal, which counts every prospect in the cohort including those never contacted. RANK COHORTS ON positivePct, NEVER ON replyPct: a rejection is a reply, so a cohort that provokes people scores high on replyPct while producing nothing. A high replyPct next to a high negativePct means the copy is annoying its audience — say that, do not call it engagement. IMPORTANT LIMIT ON ALL FOUR RATES: they count only replies Onsa has SCORED, so an unscored or still-in-window reply is in none of them and list_replies can legitimately show more replies than these rates imply — quote them as "of the replies Onsa scored", and use list_replies when the question is how many people actually answered. A rate is null when its denominator is 0, meaning nothing was sent, so no rate exists; that is different from the COUNTS above, which are genuinely 0 in that case. Two further caveats worth stating when you report these: the *Scheduled counts are everything queued regardless of date, and sentiment is evaluated once per lead ever, not once per reply. A campaign whose invites were never sent reads as all zeros, which means "not tried yet", not "failed". Counts alone cannot tell the user what to DO: follow this with list_next_steps for the ranked to-do list and list_replies for the words.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
campaignIdYesCampaign id from list_campaigns or fetch_leads — never invent one

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
ratesYes
responsesYes
campaignIdYes
leadsTotalYes
campaignUrlYes
invitesSentYes
messagesSentYes
invitesAcceptedYes
invitesScheduledYes
messagesScheduledYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and idempotentHint=true, but the description adds substantial behavioral nuance beyond that: counts LEADS not actions, de-duplication semantics, rates only include scored replies, null rates vs zero counts, and the meaning of invitesSent exceeding leadsTotal. This is rich context that prevents misinterpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very long and covers many edge cases, which is valuable, but it is not concise. It is structured with paragraphs and important caveats are flagged with 'IMPORTANT', so it is organized, but the sheer length reduces its conciseness score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool and the presence of an output schema, the description covers all necessary guidance for correct invocation: counting semantics, rate denominators, null handling, and common pitfalls. It also provides guidance on how to report results, making it fully complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for the single parameter (campaignId) with a clear explanation. The tool description does not add further parameter-specific semantics beyond what the schema provides, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise statement of the tool's function: 'Get the outreach funnel for one campaign: invites sent, invites accepted, messages sent, and replies split into positive / negative / other by sentiment.' It clearly identifies the resource (campaign) and the specific metrics, and distinguishes itself from siblings like list_replies and list_next_steps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly directs the agent when to use alternatives: if the user asks about 'LinkedIn reactions' they mean REPLIES, so use list_replies for the actual text. It also says to follow with list_next_steps for ranked to-do lists. It provides clear exclusion criteria and routing to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources