Skip to main content
Glama
Sign In

PoliteReach

by com.politereach
OverviewDiscussionsAdmin

LinkedIn Outreach Analytics

li_outreach_analytics
Read-only

Compare outreach performance grouped by strategy, ICP, campaign or account: invite/acceptance rates, reply rates, per-step sends, reply attribution by step, handed-off/failed/completed counts. Also localHours: acceptance and reply rates by PROSPECT-LOCAL send hour, six buckets; sessionLabel and sendWindowMode filter it; sends with no known zone are unbucketed*.

⚠️ READ replyRate AS WHAT IT COUNTS: replies still AWAITING an answer ÷ first messages sent. It FALLS as conversations are marked handled, not as they are answered — so a well-worked strategy scores lower than a neglected one, and handedOff on the same row is the rest of those replies. Judge a strategy with li_outcome_summary, which reads the human verdict, and never quote replyRate on its own as 'how many people replied'.

Also bookings, grouped the same way plus a total: booking links sent, how many agreed to a call, how many booked (agreedToBookedRate), agreedBooked (the numerator of agreedToBookedRate; booked also counts calls booked by people who never agreed), booked without vs after a nudge, median hours from link to booking, closed after a nudge, and bookedFromSequenceLinkNoReply — calls booked straight off the sequence's own link by someone who never replied, which only the calendar can reveal. Rows whose names collide (strategies, ICPs and campaigns are copied per team) carry ' · ', or ' · 2', in label, and rows and bookings.rows name the same key the same way.

groupBy "arm" + experimentId (from li_experiment_assign): per arm × ICP and per arm, n and acceptance (accepted ÷ invited), reply (ever replied ÷ first messages sent) and booking (booked ÷ n) rates, each with k, n and a Wilson 95% interval; people put in the control arm for having no post are reported apart (forcedToControl). Without experimentId it lists your experiments.

Input Schema

NameRequiredDescriptionDefault
groupByYesRow grouping: strategy, icp, campaign, account, or arm (an experiment's arms; needs experimentId)
sessionIdNoLimit to one account by id (li_list_accounts). Omit to cover every account you can see.
experimentIdNogroupBy "arm" only: the experiment (omit to list yours)
sessionLabelNoLimit to one account by label, LinkedIn name, profile slug or member id. Omit to cover every account you can see.
sendWindowModeNoFilter `localHours` to accounts in this send-window mode (account | prospect | both); rows are not filtered

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / experimentId
      Added value: +{
+  "description": "groupBy \"arm\" only: the experiment (omit to list yours)",
+  "type": "string"
+}
    • changedInput schema / properties / groupBy / description
      Previous value: -"Row grouping: strategy, icp, campaign or account"New value: +"Row grouping: strategy, icp, campaign, account, or arm (an experiment's arms; needs experimentId)"
    • changedInput schema / properties / groupBy / enum
      Previous value: -[
-  "strategy",
-  "icp",
-  "campaign",
-  "account"
-]New value: +[
+  "strategy",
+  "icp",
+  "campaign",
+  "account",
+  "arm"
+]
  2. Changed4 schema fields changed
    • addedInput schema / properties / groupBy / description
      Added value: +"Row grouping: strategy, icp, campaign or account"
    • addedInput schema / properties / sendWindowMode / description
      Added value: +"Filter `localHours` to accounts in this send-window mode (account | prospect | both); rows are not filtered"
    • addedInput schema / properties / sessionId / description
      Added value: +"Limit to one account by id (li_list_accounts). Omit to cover every account you can see."
    • addedInput schema / properties / sessionLabel / description
      Added value: +"Limit to one account by label, LinkedIn name, profile slug or member id. Omit to cover every account you can see."
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations cover only the safety profile (readOnlyHint=true), but the description adds substantive behavioural semantics: replyRate counts still-awaiting replies over first messages and falls as conversations are marked handled, sends with no known zone fall into unbucketed*, control-arm members forced for lack of a post are surfaced via forcedToControl, and colliding labels get suffixed with account names. These are exactly the non-obvious behaviours an agent needs and are not derivable from the annotations.

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

Conciseness2/5

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

The text is a dense run-on wall of prose with no headings, bullets, or line breaks, packing metric definitions, caveats and grouping rules into long compound sentences. Much of the booking-metric enumeration is justified only because no output schema exists, but the formatting makes it hard to scan and the warning about replyRate is buried behind a large paragraph.

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

Completeness4/5

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

With no output schema, the description correctly carries the return-value burden and documents the metric groups, the arm experiment output, label collision handling and unbucketed rows. It is effectively complete for calling the tool, though it says nothing about result size, row limits, or pagination.

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?

Schema description coverage is 100%, so the schema already defines every parameter. The description adds only marginal meaning — that sessionLabel/sendWindowMode scope localHours, that groupBy 'arm' needs experimentId — which the schema largely states itself. Baseline 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 opening sentence states a specific verb and resource: 'Compare outreach performance grouped by strategy, ICP, campaign or account', and enumerates the concrete metrics returned. It also names sibling tools (li_outcome_summary, li_experiment_assign) so an agent can place it relative to neighbours without opening schemas.

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

Usage Guidelines4/5

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

It explicitly routes the agent elsewhere for the authoritative verdict ('Judge a strategy with li_outcome_summary... never quote replyRate on its own') and explains the arm/experimentId pairing for the arm grouping. It does not, however, define when to prefer this over other analytics-ish siblings (e.g. li_account_activity, li_bookings), so guidance is strong but not exhaustive.

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

All PoliteReach toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources