Leadpoet

Get outreach summary

getOutreachAnalytics

Read-onlyIdempotent

Rolling 90-day email and LinkedIn summary: messages_sent, linkedin_invitations_sent, sent (both), prospects reached, replies and outcomes (prospects; never add outcomes; meeting_requested is only an ask), plus the last 24 hours and the current queue and review. replied includes replies to invitations and older sends, so replied over reached_prospects is no rate; the only rate is qualified_positive_replies_per_1000, not a percent. delivered is no delivery rate, awaiting_delivery no backlog. no_send_reasons counts decisions, never contacts. live.awaiting_review counts every held draft, including ones Review does not show yet; getReviewSummary counts the drafts Review shows.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "getOutreachAnalytics"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare it read-only, idempotent, non-destructive, so safety is covered. The description goes well beyond that, disclosing interpretation rules the agent would otherwise get wrong: outcomes must never be summed, replied includes invitation replies and older sends so replied/reached_prospects is not a rate, delivered is not a delivery rate, and no_send_reasons counts decisions not contacts.

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?

Every claim is substantive, but the delivery is a wall of comma-spliced clauses and shorthand ('no_send_reasons counts decisions, never contacts. live.awaiting_review…'). Front-loading is fine; readability and structure are not, which hurts scanning by an agent.

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 carries the burden of explaining return values, and it does so thoroughly, including which fields are rates vs. raw counts and the getReviewSummary boundary. Pagination or timezone/date-boundary questions are unaddressed, but for a fixed-summary tool this is close to complete.

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

Parameters4/5

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

The tool takes zero parameters, so there is no schema semantics to add; baseline is 4. The description instead spends its budget on output interpretation, which is a reasonable trade.

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

Purpose4/5

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

The description states a specific verb+resource ('Rolling 90-day email and LinkedIn summary') and enumerates the metrics returned (messages_sent, linkedin_invitations_sent, prospects reached, replies). It's identifiable against siblings like getAnalyticsReport or getReviewSummary, though the opening clause is terse and the metric list is packed into a run-on.

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

Usage Guidelines3/5

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

Usage is implied by the 'rolling 90-day' scope and the explicit carve-out that getReviewSummary counts the drafts Review shows while this tool's live.awaiting_review counts all held drafts. There's no explicit when-to-use/when-not framing against the many other analytics siblings (getAnalyticsReport, getAudienceFunnel, getPipeline).

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

All Leadpoet tools Inspect

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

Need Help?