[DOCS] Clarify that profile-based send_message is compose-oriented, not reply-safe

[jingyi-zhao-01]

Summary

The current send_message tool contract is still easy for MCP clients to misread as a safe "reply to the conversation I just read," even though profile-based sending can open a separate DM thread. README issue links help, but tool-facing metadata and docs still do not make that limitation explicit enough for agent callers.

Context

I hit this from Codex while replying to a real recruiter conversation. I first read the existing conversation by thread_id, then used send_message with the participant identity. The tool returned sent: true, but LinkedIn created a separate DM instead of replying in the original recruiter thread.

I know the core bug is already tracked in #483, and I also saw the open PR #451 to add thread_id support. This issue is narrower: even with those linked issues, the user-facing/tool-facing contract still encourages unsafe assumptions in MCP clients.

Observed behavior

• A caller can read an existing recruiter/InMail thread and then call send_message expecting to reply to that thread.
• The tool can instead navigate to a compose flow and create a separate DM.
• The tool still returns success (sent: true) and a compose-style URL, which can look like a valid reply if the client is not thread-aware.
• In my Codex session, the exposed tool schema also did not make this risk obvious at call time.

Expected behavior

The tool contract should make one of these paths explicit:

1. send_message is a generic "compose/send to this person" tool and is not safe for replying to an existing thread unless a thread-targeted parameter is used; or
2. the preferred reply path is documented directly in the tool metadata once thread_id support is available.

Evidence

• Reproduction:
  1. Read an existing LinkedIn recruiter/InMail conversation by thread_id.
  2. Call send_message using participant identity instead of a thread-targeted send path.
  3. Observe LinkedIn open/target a compose flow and create a separate DM.
• Related PRs/issues:
  • [BUG] send_message can create separate DM instead of replying to existing InMail thread #483
  • feat: add thread_id support to send_message for replying to InMails #451
  • [DOCS] Sync README tool status with open issues #506
• Environment:
  • MCP client: Codex CLI
  • Real-world recruiter thread on LinkedIn
  • Profile-based send path produced a new DM instead of a reply in the original thread

Impact radius

This mainly affects MCP/agent clients that rely on tool descriptions or generated schemas more than on the README. For those clients, "Send a message to a LinkedIn user" is easy to interpret as reply-safe when the current behavior is actually compose-oriented.

Hypothesis

My current hypothesis is that the repo-level README is not the main source of truth for many MCP callers; the tool description/docstring/schema is. So even though #483 is linked from the README table, callers can still make the wrong assumption at the exact point of tool use.

Non-goals

• Not reopening the core separate-DM bug already tracked in [BUG] send_message can create separate DM instead of replying to existing InMail thread #483.
• Not asking for a rewrite of the messaging implementation.
• Not blocking the thread_id work in feat: add thread_id support to send_message for replying to InMails #451 on a bigger design discussion.

Minimal ask

Please consider clarifying the tool contract in the smallest possible places that MCP callers actually see:

• the send_message tool description/docstring,
• any generated manifest/schema/help text,
• and the README usage examples.

A minimal wording improvement would be something like:

send_message composes/sends to a LinkedIn user. When using profile-based targeting, it may create a separate DM instead of replying to an existing recruiter/InMail thread. Use thread_id when available for replies to an existing conversation.

If thread_id is not yet released, a temporary warning in the tool description would still help prevent false assumptions.

Offer to help

Happy to validate wording or test the released behavior once thread_id support lands.