[BUG] connect_with_person returns connect_unavailable ("did not expose a usable Connect action") on profiles where Connect is clearly the primary CTA — v4.13.0

[PasSivam]

[BUG] connect_with_person returns connect_unavailable ("did not expose a usable Connect action") on profiles where Connect is clearly the primary CTA — v4.13.0

Summary

On linkedin-scraper-mcp v4.13.0, connect_with_person consistently returns:

{
  "status": "connect_unavailable",
  "message": "LinkedIn did not expose a usable Connect action for this profile.",
  "note_sent": false
}

on profiles whose own profile DOM (returned by the same tool call) explicitly contains a Connect button as the primary CTA, right alongside Save in Sales Navigator and More. The tool is seeing Connect but refusing to act on it.

The error string "did not expose a usable Connect action" does not appear in any open or closed issue today, so this looks like an unreported variant — possibly distinct from #407 (which is about restricted-invite profiles where the dialog opens but the Send button is disabled, with error wording "did not open a usable invite dialog").

Environment

• Package: linkedin-scraper-mcp v4.13.0 (installed via uvx, latest on PyPI as of 2026-05-18)
• Client: Claude Code (MCP stdio transport)
• Platform: macOS 25.4.0 (darwin, aarch64)
• uvx: 0.11.14
• Cache state: Bug persists after uvx --refresh linkedin-scraper-mcp (full reinstall from PyPI)
• Session: --status reports Session is valid (persistent profile at ~/.linkedin-mcp/profile)
• Invocation: stdio, no custom args (uvx linkedin-scraper-mcp)

Reproduction

Three profiles attempted back-to-back, all returned the same status. No interleaving with send_message (rules out #432). No note= parameter (rules out the noted-invite path).

#	Profile (anonymized)	Followers	Connection degree	Profile DOM shows Connect?	Result
1	Profile A — high-follower account in "creator" or follow-first display mode	~2.3K	2nd	No — DOM shows Follow / Save in Sales Navigator / View my services / More	connect_unavailable (plausibly correct — Connect is genuinely not exposed)
2	Profile B — standard professional account	500+ connections	2nd	Yes — DOM shows Connect / Save in Sales Navigator / More	connect_unavailable (unexpected)
3	Profile C — standard professional account, has a mutual 1st-degree	~1.5K	2nd	Yes — DOM shows Connect / Save in Sales Navigator / More	connect_unavailable (unexpected)

The first profile is plausibly a correct rejection (Connect is genuinely buried/gated). The other two are not — the scraper's own profile read shows Connect as the visible primary button, yet connect_unavailable is returned without (apparently) ever attempting the click flow.

Profile B DOM excerpt (redacted)

The profile field in the tool response for Profile B includes (names/titles/employer redacted):

<Name>
2nd degree connection
2nd
<Title> | Partner <Firm>
<Firm>
<Region>  Contact info
500+ connections
Connect
Save in Sales Navigator
More

Connect appears as the primary action above the fold, before Save in Sales Navigator and More.

Profile C DOM excerpt (redacted)

<Name>
2nd degree connection
2nd
<Title> <Firm>
…
500+ connections
<Mutual> is a mutual connection
Connect
Save in Sales Navigator
More

Same pattern — Connect is the primary action.

Steps

# Pseudocode for the MCP calls
connect_with_person(linkedin_username="<profile-a>")  # → connect_unavailable
connect_with_person(linkedin_username="<profile-b>")  # → connect_unavailable (unexpected)
connect_with_person(linkedin_username="<profile-c>")  # → connect_unavailable (unexpected)

No note= argument was passed on any call.

Expected behaviour

For Profiles B and C, the scraper should locate the visible Connect button (it has already done so to render it in the returned profile field), click it, handle the invite dialog, and return status: "invitation_sent" (or whatever the success status is in 4.x).

Hypothesis

The detection step that populates the profile text and the click step that decides connect_unavailable may be using different selectors and disagreeing about whether Connect is reachable. Distinct from:

• [BUG] connect_with_person fails on restricted-invite profiles even after dialog opens #407 — restricted-invite profiles where the dialog does open but Send is disabled (different error wording, different flow stage)
• connect_with_person fails on profiles where Connect is buried under More menu #406 / PR fix(connect): locale-independent state detection and More-menu retry #409 — Connect buried under "More" (closed, in v4.9.5; my profiles have Connect as a top-level button, not buried)
• [BUG] connect_with_person with note: dialog locator collides with message composer overlay (Emoji button) #432 — composer overlay collision with noted invites (only fires with note= set, my calls were blank)

It looks like a new "Connect button visible but click path bails out before attempting" failure mode introduced somewhere between v4.9.5 and v4.13.0.

Workaround

None found. Restarting the MCP, wiping the uvx cache, and reinstalling did not help. The persistent browser profile reports as valid.

Happy to provide privately

Profile names/handles are redacted here for the named individuals' privacy. I can DM/email the maintainer:

• The three actual handles so you can reproduce against the real profiles
• --no-headless recording of the flow
• Raw connect_with_person response (full profile payload)
• Patchright/Playwright version info
• Test against a profile of your choosing to confirm the pattern

[stickerdaniel]

Hey, thanks for the detailed report! I can't reproduce this on the latest version, connect works across ~20 profiles wherever Connect is the actual CTA. Could you share the three handles here so I can repro against the exact profiles and get the fix in? Thanks!