LinkBridge MCP

Send Message

send_message

Destructive

Compose and send a new LinkedIn direct message to a recipient from their profile. Use it only when starting a fresh conversation, not for 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. To answer an existing thread, including an InMail from someone who is not a connection, use reply_to_conversation with the thread's id instead.

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.29.0Nov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description is fully consistent, explicitly scoping the write behavior to confirm_send=True. Beyond the annotations it discloses failure modes not visible in structured fields: the enter_to_send_enabled status and what to tell the user, the fail-closed recipient authorization rule, the absence of any private/Voyager API, and retry_safe as the authority for retrying.

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 purpose and the reply-alternative routing, then the connection-prerequisite, then status/failure handling — a sensible priority order. It loses a point for the dense implementation aside about validating a Message action, following browser navigation and pinning the final route, and for a return-value paragraph (thread_id, retry_safe) that partly duplicates the output schema.

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 four parameters, this covers purpose, alternatives, prerequisites, authorization behavior, dry-run behavior and the one non-obvious account setting that blocks sending. Nothing an agent needs in order to decide or retry is missing.

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 real meaning the schema lacks: confirm_send=False is framed as a dry run that still reports the Enter-to-Send status, and profile_urn is characterized as corroboration only that never bypasses recipient verification. The message-formatting details are left entirely to the schema, which is fine given the coverage.

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+scope ("Compose and send a new message to a LinkedIn user") and immediately distinguishes itself from reply_to_conversation by naming the sibling and the exact situation each covers. An agent can route between send_message and reply_to_conversation without opening either 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?

Gives explicit when-to-use and when-not-to-use rules: existing recruiter/InMail threads go to reply_to_conversation with the thread id, and non-messageable recipients require connect_with_person first with a retry only after acceptance. It also documents the dry-run path (confirm_send False) as the pre-flight check, which is exactly the decision support an agent needs.

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