Add people to a LinkedIn GROUP thread (a conversation with is_group true). Each target is what a user would paste: a linkedin.com/in/ link, a Sales Navigator or Recruiter link, a bare slug or a raw URN; it resolves like resolve_conversation_counterpart but down to a profile URN, which is how gtm-api addresses a group member, so a playtables person known by member id alone sends the ladder on to the sender profile's connections, the corpus and the lite profile.

result.added lists the participants the thread gained (role group_member, in target order); result.skipped names each target left out with a reason: unresolvable (no rung knows the profile, or it has no URN), already_member. Nothing is refused for that. 409 not_a_group on a one-to-one thread: LinkedIn opens a NEW group for that, so start one with send_message {new_thread: {attendees: [...]}} and the counterpart among them. 409 thread_not_dispatched while the group's opening message is still queued (no gtm thread yet). 422 channel_not_connected when no live sender profile carries the thread's account. A target the resolve could not ask about refuses the whole call and adds nobody, never a skip as unresolvable: 429 (gtm_busy, or bucket_saturated with retry_after), 403 (gtm_access_lost, gtm_scope_missing), 503 (gtm_unavailable, gtm_bridge_unavailable, playtables_unavailable): try again later. gtm-api's 409 linkedin_refused on the add itself passes through.

Contract:

• MCP tool add_conversation_participants, registry package mcp.unibox/conversations, mount unibox.threads.
• Operation action, response envelope action.
• Flags: none.