mcp-server-linkedin

Overview Schema Source Related Servers Discussions Admin

Send Message

send_message

Destructive

Compose and send a new direct LinkedIn message to a recipient from their profile page; requires confirmation before sending and does not reply 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.

thread_id is present only on sent: the conversation the confirmed message was observed in, or null when the page stayed on the compose route. retry_safe stays the authority for whether a retry is safe.

Input Schema

Name	Required	Description
`message`	Yes	Message text. LF, CRLF and CR all end a line; an empty line separates paragraphs and is kept. Whitespace-only lines count as empty, and leading and trailing whitespace of the whole message is removed, as LinkedIn does when sending. Tab, other control characters, DEL, U+0085, U+2028 and U+2029 are refused.
`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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.28.0Nov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only supply openWorldHint and destructiveHint; the description goes well beyond them by disclosing the dry-run mode (confirm_send False), the enter_to_send_enabled status and required user remediation, the fail-closed recipient verification behavior, and that no private API is used. It also explains that thread_id is present only on 'sent' and that retry_safe is the authority for retrying, which an agent cannot infer 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.

Conciseness4/5

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

Purpose and the reply-path warning are front-loaded, which is the right ordering for a destructive send tool. A few sentences, notably the detailed walkthrough of how recipient authorization is validated (Message action, browser navigation, route pinning), are internal mechanics that add length without changing how an agent calls the tool.

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 destructive, open-world write tool with three required parameters, the definition covers the safety profile, the prerequisite (messageable recipient or prior connection), the failure mode (enter_to_send_enabled), and the retry contract. An output schema exists, so return-value explanation is optional, yet the description still disambiguates thread_id and retry_safe.

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; the description adds real meaning on top by framing confirm_send False as a dry run and by clarifying that profile_urn is corroboration only and 'never bypasses recipient verification.' It does not, however, add anything about linkedin_username beyond what the schema already documents.

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: 'Compose and send a new message to a LinkedIn user.' It immediately distinguishes itself from get_conversation and search_conversations by stating those only read an existing thread and do not send a reply, so an agent can route correctly without opening the sibling 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?

Gives explicit when-to-use and when-not-to-use guidance: it is a profile-based compose flow, explicitly not a safe reply path for an existing recruiter/InMail thread. It also prescribes the fallback sequence — use connect_with_person first, then retry only after the request is accepted — and names the sibling read tools as alternatives for inspection.

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