HeyLead

by D4umak

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

send_message

Destructive

Send LinkedIn follow-ups, replies, or InMail to prospects, and delete recently sent messages within 60 minutes.

Instructions

Send follow-ups, replies, or InMail to prospects.

Args:
    action: What to do:
        "followup" — Send a follow-up DM after connection accepted
        "reply"    — Reply to a prospect who has messaged you
        "delete"   — Delete a recently sent message (within 60 min on LinkedIn)
        "inmail"   — Send an InMail to a NON-connection. Preconditions
                     (each fails closed with no send): prospect has a
                     provider_id; they are NOT a 1st-degree connection
                     (use followup/DM for those); no InMail already sent
                     on this outreach; InMail credits remaining > 0.
                     A pending invitation to the same person is allowed
                     — that is the escalation path. Requires outreach_id.
    campaign_id: Which campaign to send from. Uses active if empty.
    outreach_id: Specific outreach to target. Required for inmail.
    format: 'text'. For followup/reply.
    text: For followup/reply on a hosted account: the message to send,
        required; the cloud sends it as is in the outreach's LinkedIn
        chat (the same route as answer_inbox reply). Without a backend
        the message is generated. For delete: optionally pass a Unipile
        message_id directly.

Input Schema

Name	Required	Default
`text`	No
`action`	No	followup
`format`	No	text
`campaign_id`	No
`outreach_id`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.375Sep 18, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare destructive=true and openWorld=true, but the description goes well beyond them: the 60-minute LinkedIn delete window, InMail credit gating, the no-duplicate-InMail rule, the allowed pending-invitation escalation path, and that text is sent as-is on a hosted account or generated without a backend. This is precisely the extra behavioral context annotations cannot express.

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

Conciseness4/5

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

Front-loaded with the one-line purpose, then a clean Args block grouped per parameter; the indented action list is scannable. It runs long, and the inmail precondition paragraph is dense, but nearly every sentence carries non-redundant operational meaning, so the size is largely earned.

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?

For a 5-parameter mutation tool with four modes, one of which has a four-clause precondition chain, this description covers what an agent needs to choose and invoke correctly. An output schema exists, so return-value details are correctly left out rather than duplicated.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden, and it does: action values are enumerated with semantics, outreach_id's requirement is scoped to inmail, campaign_id's fallback is stated, format is constrained to 'text', and text's dual role (message body vs. optional Unipile message_id for delete) is explained. No parameter is left undocumented.

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?

Opens with a specific verb+resource ('Send follow-ups, replies, or InMail to prospects') and immediately decomposes it into four distinct actions (followup, reply, delete, inmail) with the scenario each serves. This lets an agent distinguish this tool from siblings like answer_inbox and inbox 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.

Usage Guidelines5/5

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

Explicit when-to-use guidance per action, plus a route-away rule: use followup/DM for 1st-degree connections rather than inmail. InMail preconditions are enumerated and their failure mode stated ('each fails closed with no send'), and campaign_id's default behavior ('uses active if empty') is spelled out.

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