mcp-server-linkedin

Overview Schema Source Related Servers Discussions Admin

Send Message

send_message

Destructive

Send a new LinkedIn message to a recipient from their profile when direct messaging is available; use for initial outreach, not replying to existing threads.

Instructions

Compose and send a new message to a LinkedIn user.

Profile-based targeting opens LinkedIn's compose flow. It is not a safe reply path for an existing recruiter/InMail or messaging thread: it may create a separate DM even after you inspect that thread with get_conversation or search_conversations. Those tools only read an existing thread; they do not send a reply. Until a thread-targeted send path is available, do not treat profile-based send_message as a reply.

The recipient must be directly messageable from the profile page. If LinkedIn does not expose a normal Message action, use connect_with_person first, then retry send_message only after the connection request is accepted. A status of enter_to_send_enabled means the account has LinkedIn's "Press Enter to Send" preference on, which hides the Send button; relay the returned instructions to the user, who switches it to "Click Send to send" before retrying. The dry run (confirm_send False) reports it too. Recipient authorization comes from validating one recipient-specific Message action carrying the target URN, then following its browser navigation and pinning the exact final route. Visible profile links or recipient URNs in the composer are optional corroboration; any contradiction fails closed. No Voyager or other private API is used. This is a write operation when confirm_send is True.

Input Schema

TableJSON Schema

Name	Required	Description
`message`	Yes	Single-line message text to send. C0 control characters and DEL are rejected, including CR, LF, and tab.
`profile_urn`	No	Optional profile URN (e.g. ACoAAB...) to verify against the URN exposed by the loaded profile before opening its Message action. It never bypasses recipient verification. Obtain via get_person_profile. Note: inbox may not always show all messages; use search_conversations as a fallback.
`confirm_send`	Yes	Must be True to send the message
`linkedin_username`	Yes	LinkedIn username of the recipient; a full profile URL is accepted too

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.26.2Oct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only give openWorldHint and destructiveHint, but the description discloses far more: it is a write only when confirm_send is True, the dry-run behavior of confirm_send False, the enter_to_send_enabled account-preference failure mode and its remedy, and the recipient-authorization validation with fail-closed contradiction handling. This is unusually rich behavioral context that goes well beyond 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.

Conciseness4/5

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

The purpose is front-loaded and the later paragraphs are dense with actionable detail, so most sentences earn their place. It is, however, on the long side and repeats the read-only nature of the conversation tools, which could be tightened.

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?

An output schema exists, so return structure needn't be explained, and the annotations cover the safety profile. The description still completes the picture with authorization checks, failure-mode handling, prerequisite steps, and API-usage disclosure, leaving nothing an agent needs to call it correctly unstated.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it clarifies that confirm_send False is a dry run that reports the send-readiness status, and that profile_urn never bypasses recipient verification. These are behavioral nuances the schema descriptions do not capture.

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?

States a specific verb+resource ('Compose and send a new message to a LinkedIn user') and immediately scopes it as profile-based targeting rather than a thread reply. It names the siblings it is not (get_conversation, search_conversations) and the alternative path (connect_with_person), so an agent can distinguish it without opening other schemas.

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?

Explicitly states when not to use it ('not a safe reply path for an existing recruiter/InMail or messaging thread') and names the read-only alternatives, plus the prerequisite flow: use connect_with_person first and retry only after the request is accepted. It also gives conditional retry guidance tied to the enter_to_send_enabled status.

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