feat: add 22 new tools — profile read/edit, job apply, connections, notifications

[Gabrcodes]

Summary

Extends the LinkedIn MCP server from 13 to 35 tools with full profile management, job application workflow, connections export, and notification scraping. Also cherry-picks improvements from community PRs and fixes reported bugs.

• 4 account/profile reading tools — view own profile, read all sections at once, list saved jobs and applications
• 13 profile editing tools — edit intro, about, experience, education, skills, certifications, volunteer, projects, publications, courses, languages, honors
• 2 job action tools — Easy Apply automation with multi-step form handling, job bookmarking
• 3 connections tools — bulk connections export (cherry-picked from feat: bulk connections export tools #170), batch contact enrichment, search connections at a specific company
• 1 notifications tool — scrape the notifications page
• 8 new readable profile sections — skills, certifications, volunteer, projects, publications, courses, recommendations, organizations

Bug Fixes

• Closes [BUG] connect_with_person fails when Connect button is behind More menu (sticky navbar viewport issue) #304: connect_with_person fails when Connect button is behind More menu due to sticky navbar — added scroll_into_view_if_needed and force=True fallback
• Closes [BUG] get_conversation fails when user has multiple threads with the same person #307: get_conversation fails when user has multiple threads with same person — now tries both display name and URL slug, with clear error suggesting thread_id

Feature Requests Addressed

• Closes [FEATURE] What connections do I have at <company>? #248: "What connections do I have at <company>?" — new get_connections_at_company tool
• Closes feat: Add get_notifications tool to scrape LinkedIn notifications #211: get_notifications tool to scrape LinkedIn notifications

Cherry-picked Community Improvements

• PR Aspectrr/linkedin connect new #302 (@aspectrr): multi-selector fallback for More menu button (4 selectors instead of 1)
• PR feat: bulk connections export tools #170 (@Desperado): bulk connections export with chunked rate-limit handling and structured contact parser; network degree filter for search_people

New Tools Reference

Tool	Category	Description
get_my_profile	Account	Scrape own profile via /in/me/
get_my_profile_full	Account	Scrape ALL profile sections at once
get_saved_jobs	Account	List saved/bookmarked jobs
get_my_applications	Account	List jobs applied to
edit_profile_intro	Edit	Edit name, headline, location, industry
edit_profile_about	Edit	Edit About/Summary section
add_experience	Edit	Add work experience
add_education	Edit	Add education entry
add_skill	Edit	Add skill (with typeahead)
add_certification	Edit	Add certification
add_volunteer_experience	Edit	Add volunteer work
add_project	Edit	Add project
add_publication	Edit	Add publication
add_course	Edit	Add course
add_language	Edit	Add language
add_honor	Edit	Add honor/award
apply_to_job	Job	Easy Apply automation
save_job	Job	Bookmark a job
get_my_connections	Connections	Bulk export connections
extract_contact_details	Connections	Batch enrich with contact info
get_connections_at_company	Connections	Find connections at a company
get_notifications	Notifications	Scrape notifications page

Test plan

• 357 passed, 5 skipped (Windows POSIX-only), 0 failures
• Updated test_fields.py for new profile sections
• Updated test_tools.py for network parameter on search_people
• All files compile cleanly (py_compile)
• ruff check and ruff format pass
• Live test profile editing tools
• Live test Easy Apply flow
• Live test connections export
• Live test notifications scraping

[greptile-apps]

Greptile Summary

This PR significantly expands the LinkedIn MCP server from 13 to 35 tools, adding profile read/edit, Easy Apply job automation, connections bulk export, and notification scraping. It also addresses previously reported bugs: the connect_with_person sticky-navbar issue (#304), get_conversation multi-thread ambiguity (#307), overly broad "already applied" detection, and the <select> native setter problem in _fill_field_by_label.

The architecture is consistent with the existing codebase — new tools delegate to new extractor methods, maintain the same tool shape ({url, sections, references}), and follow the established error-handling and progress-reporting patterns. The previous review's concerns have all been addressed.

Key remaining observations:

• apply_to_job breaks out of its step loop and returns apply_failed in the same code path whether the dialog was dismissed by the user or closed because the form auto-submitted — there is no page-state check at that point, so a successful single-page application could be misreported.
• _open_edit_form was introduced but is never called; all edit methods use inline navigation instead, making it dead code.
• get_my_profile (extractor) still contains an inline version of _resolve_my_username() rather than calling the helper added in this same PR.

Confidence Score: 4/5

Safe to merge after the apply_to_job dialog-close ambiguity is addressed; all other findings are style/cleanup (P2).

One P1 logic defect remains: when the Easy Apply dialog closes unexpectedly mid-loop (after Next/Review/Continue), the code returns apply_failed without checking whether the application was actually submitted. A caller acting on that status could re-submit the application. The two P2 findings (dead _open_edit_form method and inline _resolve_my_username() duplication in get_my_profile) do not block merge. Previous review concerns have all been resolved.

linkedin_mcp_server/scraping/extractor.py — specifically the apply_to_job step loop (lines 2637-2639) and the unused _open_edit_form helper (line 1896).

Important Files Changed

Filename	Overview
linkedin_mcp_server/scraping/extractor.py	~1,450 lines added — new profile-edit, Easy Apply, save-job, connections, and notifications methods. Key concerns: apply_to_job loop treats dialog-closes-after-Next as apply_failed without a post-close page check; _open_edit_form helper is defined but never called.
linkedin_mcp_server/tools/profile_edit.py	New 738-line file registering 13 profile-editing tools; all follow the established tool registration pattern with proper destructiveHint annotations, auth-error handling, and progress reporting.
linkedin_mcp_server/tools/connections.py	New file adding 4 tools (get_my_connections, extract_contact_details, get_connections_at_company, get_notifications); pattern is consistent and chunk_delay default is sensible.
linkedin_mcp_server/tools/account.py	New file with 4 account tools (get_my_profile, get_my_profile_full, get_saved_jobs, get_my_applications); clean implementation with consistent error handling.
linkedin_mcp_server/tools/job.py	Added apply_to_job and save_job tools with proper destructiveHint annotations; tool layer is correct and delegates to extractor methods.
linkedin_mcp_server/tools/person.py	Added network filter parameter to search_people and updated section documentation; straightforward additive change.
linkedin_mcp_server/scraping/fields.py	Added 8 new section entries to PERSON_SECTIONS and exported ALL_PERSON_SECTION_NAMES; tests updated accordingly.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[apply_to_job] --> B[Navigate to job page]
    B --> C{Easy Apply button?}
    C -->|No| D{Applied indicator?}
    D -->|Yes| E[return already_applied]
    D -->|No| F[return not_easy_apply]
    C -->|Yes| G{confirm_apply?}
    G -->|No| H[return confirmation_required]
    G -->|Yes| I[Click Easy Apply]
    I --> J[Wait for dialog]
    J --> K[Step loop max 15]
    K --> L{dialog open?}
    L -->|No| M[⚠️ break → falls through to apply_failed]
    L -->|Yes| N{Submit button?}
    N -->|Yes| O[Click Submit]
    O --> P{Page text confirms?}
    P -->|Yes| Q[return applied]
    P -->|No| R[return applied_unconfirmed]
    N -->|No| S{Review button?}
    S -->|Yes| T[Click Review → continue]
    S -->|No| U{Next button?}
    U -->|Yes| V[Click Next → continue]
    U -->|No| W{Required empty fields?}
    W -->|Yes| X[return requires_input]
    W -->|No| Y{Continue button?}
    Y -->|Yes| Z[Click Continue → continue]
    Y -->|No| AA[return apply_failed stuck]
    K -->|exhausted| AB[return apply_failed max_steps]
    T --> K
    V --> K
    Z --> K

Loading

Comments Outside Diff (1)

1. linkedin_mcp_server/scraping/extractor.py, line 2637-2639 (link)

   Dialog close after Next/Review/Continue falls through to apply_failed

   When the dialog closes at this check — which the comment acknowledges could mean "submitted" — the break exits the for-loop and falls through to the apply_failed return at lines 2733–2738. If a single-page Easy Apply form closes the modal after the first "Next" click (instead of showing a separate "Submit application" step), the application is actually submitted but the tool reports status: "apply_failed". A caller receiving that status may retry the application, causing a duplicate submission.

   A minimal fix is to check the page text immediately after the unexpected close, consistent with how the Submit path already works:

   if not await self._dialog_is_open(timeout=3000):
       # Dialog closed — verify whether the application was submitted
       page_text = await self.get_page_text()
       if re.search(r"application.*sent|applied|submitted", page_text, re.IGNORECASE):
           return {
               "url": url,
               "status": "applied_unconfirmed",
               "message": "Application dialog closed unexpectedly; page text suggests it may have been submitted. Check your applications to confirm.",
               "job_id": job_id,
           }
       break

Prompt To Fix All With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 2637-2639

Comment:
**Dialog close after Next/Review/Continue falls through to `apply_failed`**

When the dialog closes at this check — which the comment acknowledges could mean "submitted" — the `break` exits the for-loop and falls through to the `apply_failed` return at lines 2733–2738. If a single-page Easy Apply form closes the modal after the first "Next" click (instead of showing a separate "Submit application" step), the application is actually submitted but the tool reports `status: "apply_failed"`. A caller receiving that status may retry the application, causing a duplicate submission.

A minimal fix is to check the page text immediately after the unexpected close, consistent with how the Submit path already works:

```python
if not await self._dialog_is_open(timeout=3000):
    # Dialog closed — verify whether the application was submitted
    page_text = await self.get_page_text()
    if re.search(r"application.*sent|applied|submitted", page_text, re.IGNORECASE):
        return {
            "url": url,
            "status": "applied_unconfirmed",
            "message": "Application dialog closed unexpectedly; page text suggests it may have been submitted. Check your applications to confirm.",
            "job_id": job_id,
        }
    break
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 1896-1908

Comment:
**`_open_edit_form` is dead code**

This helper is defined here but is never called anywhere in the codebase — every edit method (`edit_profile_intro`, `edit_profile_about`, `_edit_profile_section_entry`, `add_skill`, etc.) performs its own inline navigation. Either wire the calls through this helper to reduce duplication, or remove it to keep the class surface clean.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 2422-2436

Comment:
**`get_my_profile` inlines `_resolve_my_username()` and navigates to `/in/me/` twice**

This method navigates to `/in/me/` (which redirects to the real profile URL), reads `self._page.url` to extract the username, then immediately calls `scrape_person(my_username, ...)` — which navigates to `https://www.linkedin.com/in/{username}/` as its first step. That's two navigations to the same page.

`_resolve_my_username()` was introduced in this same PR to consolidate exactly this pattern. Using it here would avoid the redundant navigation and keep the extraction logic in one place:

```python
async def get_my_profile(self, sections, callbacks=None):
    my_username = await self._resolve_my_username()
    result = await self.scrape_person(my_username, sections, callbacks=callbacks)
    result["my_username"] = my_username
    return result
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (5): Last reviewed commit: "fix: address Greptile round 3 findings" | Re-trigger Greptile}

[stickerdaniel]

Hey, thanks for your PR but this is really hard to review. Could you split the features in to smaller issues and prs?

[greptile-apps]

Too many files changed for review. (117 files found, 100 file limit)

[Gabrcodes]

Thanks for the feedback! You're right — this is too much for one PR. I'll close this and split it into smaller, focused PRs:

1. Bug fixes — [BUG] connect_with_person fails when Connect button is behind More menu (sticky navbar viewport issue) #304 sticky navbar + [BUG] get_conversation fails when user has multiple threads with the same person #307 multi-thread conversation
2. New readable profile sections — 8 new sections in fields.py
3. Account tools — get_my_profile, get_my_profile_full, get_saved_jobs, get_my_applications
4. Job action tools — apply_to_job, save_job
5. Profile editing tools — 13 add/edit tools
6. Connections tools — get_my_connections, extract_contact_details, get_connections_at_company (cherry-picked from feat: bulk connections export tools #170)
7. Notifications + network filter — get_notifications, search_people network param

Each PR will be self-contained and independently reviewable.