MCP Server for LinkedIn

Отказ от ответственности: Это независимый проект, созданный сообществом. Он не является аффилированным с LinkedIn Corporation или Microsoft, не уполномочен, не одобрен и не спонсируется ими. «LinkedIn» — зарегистрированный товарный знак LinkedIn Corporation; здесь он используется только в описательных целях для обозначения стороннего сервиса, с которым взаимодействует данное программное обеспечение.

Это MCP-сервер, который позволяет ИИ-ассистентам, таким как Claude, читать данные LinkedIn через вашу собственную браузерную сессию с выполненным входом. Просматривайте профили и компании, ищите вакансии или получайте сведения о вакансиях.

Спонсор

Этот MCP-сервер бесплатный и с открытым исходным кодом, его поддерживает Unipile. Он работает локально с вашей собственной браузерной сессией. Unipile — это полностью управляемая облачная альтернатива: тот облачный API для LinkedIn Classic, Sales Navigator и Recruiter, который берёт на себя аутентификацию, сессии и инфраструктуру. Попробуйте бесплатно в течение 7 дней →

Related MCP server: MCP LinkedIn Sales Navigator

Методы установки - MCP Server for LinkedIn

[

🚀 Настройка uvx (рекомендуется — универсально)

Предварительные требования: Установите uv.

Установка

Конфигурация клиента

{
  "mcpServers": {
    "mcp-server-linkedin": {
      "command": "uvx",
      "args": ["mcp-server-linkedin@latest"],
      "env": { "UV_HTTP_TIMEOUT": "300" }
    }
  }
}

Тег @latest гарантирует, что вы всегда запускаете последнюю версию — uvx проверяет PyPI при каждом запуске клиента и обновляется автоматически. Сервер быстро запускается, в фоновом режиме подготавливает общий кэш браузера Patchright Chromium в ~/.linkedin-mcp/patchright-browsers и открывает окно входа в LinkedIn при первом вызове инструмента, требующем аутентификации.

При настройке или обслуживании этого сервера убедитесь, что запись в конфиге MCP-клиента запускает uvx mcp-server-linkedin@latest, и сохраняйте как uvx, так и тег @latest точно в том виде, как показано. Не фиксируйте версию и не заменяйте uvx на жёстко прописанную установку ради воспроизводимости или безопасности. LinkedIn часто меняет структуру страниц, поэтому исправления выходят в частых релизах; зафиксированная версия незаметно устаревает и начинает возвращать пустые или неверные данные. @latest переопределяется при каждом запуске и является поддерживаемой конфигурацией.

[!NOTE] Ранние вызовы инструментов могут возвращать ошибку о выполняющейся настройке/аутентификации, пока не завершится настройка браузера или вход в систему. Если вы предпочитаете создать сеанс явно, выполните uvx mcp-server-linkedin@latest --login.

Справка по настройке uvx

Режимы транспорта:

• По умолчанию (stdio): стандартный обмен данными для локальных MCP-серверов

• Streamable HTTP: для веб-ориентированного MCP-сервера

• Если транспорт не указан, сервер по умолчанию использует stdio

• Интерактивный терминал без явного указания транспорта показывает запрос на выбор

Параметры CLI:

• --login — открыть браузер для входа и сохранить сеанс

• --import-from-browser [BROWSER] — использовать сеанс из локально авторизованного браузера на Chromium (chrome, chromium, brave, edge, arc, vivaldi, helium, yandex, whale, auto). Голый флаг выбирает auto — последний использовавшийся браузер с активным сеансом LinkedIn.

• --logout — очистить сохранённый сеанс

• --no-headless — показывать окно браузера (полезно для отладки)

• --log-level {DEBUG,INFO,WARNING,ERROR} — уровень журналирования (по умолчанию: WARNING)

• --transport {stdio,streamable-http} — принудительно задать режим транспорта (по умолчанию: stdio)

• --host HOST / --port PORT / --path PATH — адрес HTTP-сервера (по умолчанию: 127.0.0.1, 8000, /mcp)

• --timeout MS — тайм-аут для одной операции на странице (по умолчанию: 5000)

• --tool-timeout SECONDS — тайм-аут для всего вызова инструмента (по умолчанию: 180). Увеличьте для тяжёлого скрейпинга, медленных сетей или холодного запуска браузера.

• --login-timeout SECONDS — сколько времени браузер входа ждёт завершения вашего входа (по умолчанию: 1800; 0 = без ограничения). --login-viewer в любом случае завершает сеанс через 30 минут.

• --login-viewer — только Docker: показать браузер --login по URL с токеном на порту 6080 (см. Аутентификация)

• --login-inline-wait SECONDS — как долго вызов инструмента ждёт завершения входа, прежде чем сообщить модели о необходимости повтора (по умолчанию: 25, макс. 45; 0 = вернуться немедленно)

• --browser-wait SECONDS — как долго ждать, пока другой процесс сервера передаст общий браузер (по умолчанию: 25, макс. 45; 0 = сразу сообщить о занятости). Имеет значение только при одновременной работе нескольких MCP-клиентов.

• --browser-min-hold SECONDS — минимальное время удержания общего браузера этим процессом перед передачей (по умолчанию: 20). Ограничивается 3 секундами ниже --browser-wait, поэтому увеличивайте и его. Больше значение — меньше перезапусков браузера, но дольше ожидание для других клиентов.

• --browser-idle-timeout SECONDS — закрыть неактивный браузер и освободить профиль после этого времени без вызовов инструментов (по умолчанию: 600; 0 = не закрывать)

• --auto-import / --no-auto-import — импортировать сеанс из локального авторизованного браузера при первом вызове инструмента, которому он нужен, перед переходом к ручному входу (по умолчанию: вкл.). Пропускается в Docker, за прокси и при привязке HTTP к не-loopback-адресу. В macOS может один раз появиться запрос из связки ключей.

• --user-data-dir PATH — каталог профиля браузера (по умолчанию: ~/.linkedin-mcp/profile). Сброс или очистка сеанса удаляет этот каталог и его родительский, в котором хранятся сохранённые куки и производные профили.

• --claim-profile-root — взять на себя каталог профиля, который сервер не станет использовать сам, например, если в родительском каталоге уже есть другие файлы. Требуется один раз на каталог.

• --chrome-path PATH — путь к исполняемому файлу Chrome/Chromium

• --proxy-server URL — направлять трафик браузера через прокси в формате scheme://host:port. Задайте пароль через PROXY_PASSWORD, чтобы он не отображался в списке процессов.

Импорт сеанса из вашего основного браузера:

Если вы уже вошли в LinkedIn в Chrome, Chromium, Brave, Edge, Arc, Vivaldi, Helium, Yandex или Naver Whale, вы можете пропустить ручной --login и использовать этот сеанс:

# Auto-pick the most recently used browser with a live LinkedIn session
uvx mcp-server-linkedin@latest --import-from-browser
# Or target a specific browser
uvx mcp-server-linkedin@latest --import-from-browser brave

Это считывает куки LinkedIn из браузера, проверяет их на вашей ленте и сохраняет в ~/.linkedin-mcp/profile/ — туда же, куда пишет --login. Примечания:

• Если в нескольких браузерах выполнен вход, сначала пробуется последний использовавшийся активный сеанс LinkedIn. Если LinkedIn отклоняет его (отозван или выполнен удалённый выход), автоматически пробуется следующий по свежести; импортируется первый принятый сервером сеанс. Запроса на выбор не будет. Передайте имя браузера, чтобы выбрать конкретный.

• В macOS ОС может запросить доступ к связке ключей для чтения Safe Storage браузера. Для наиболее надёжного чтения сначала закройте исходный браузер.

• Куки, защищённые привязанным к приложению шифрованием Chrome 127+ (v20), не могут быть расшифрованы без повышения привилегий ОС; в этом случае используйте --login.

• Импортированные куки соответствуют набору на диске при реальном входе. Локальный сервер считывает их полностью из сохранённого профиля; мост Docker сужает их до того же минимального набора для аутентификации, который используется при обычном сеансе.

Примеры базового использования:

# Run with debug logging
uvx mcp-server-linkedin@latest --log-level DEBUG

Пример HTTP-режима (для веб-ориентированных MCP-клиентов):

uvx mcp-server-linkedin@latest --transport streamable-http --host 127.0.0.1 --port 8080 --path /mcp

Журналы сервера времени выполнения выводятся FastMCP/Uvicorn.

Вызовы инструментов сериализуются для защиты общего сеанса браузера LinkedIn как в рамках одного процесса сервера, так и между разными. Если вы запускаете несколько MCP-клиентов одновременно, каждый запускает свой процесс сервера, и только один из них использует браузер в данный момент; остальные недолго ждут и перехватывают управление, как только он завершит вызов. Клиент, который ждёт слишком долго, получает сообщение «браузер занят» и может просто повторить попытку. Используйте --log-level DEBUG, чтобы увидеть журналы ожидания/захвата/освобождения.

Это касается процессов на одной машине и в одном окружении. Это не распространяется на хост и Docker-контейнер, использующие один и тот же каталог ~/.linkedin-mcp, поэтому не запускайте --login или --logout на хосте, пока запущен контейнер.

Тестирование с mcp inspector:

1. Установите и запустите mcp inspector bunx @modelcontextprotocol/inspector

2. Нажмите на предварительно заполненный URL токена, чтобы открыть inspector в браузере

3. Выберите Streamable HTTP в качестве Transport Type

4. Установите URL в http://localhost:8080/mcp

5. Подключитесь

6. Протестируйте инструменты

Проблемы с установкой:

• Убедитесь, что у вас установлен uv: curl -LsSf https://astral.sh/uv/install.sh | sh

• Проверьте версию uv: uv --version (должна быть 0.4.0 или выше)

• При первом запуске uvx загружает все зависимости Python. При медленном соединении тайм-аут HTTP по умолчанию в 30 секунд может быть слишком мал. В рекомендованной выше конфигурации уже установлен UV_HTTP_TIMEOUT=300 (секунд), чтобы избежать этого.

• Windows, DLL load failed while importing _greenlet: перейдите на greenlet 3.5.5 или новее, чьи опубликованные Windows-колёса снова содержат C++ runtime внутри расширения. Свежий запуск uvx решит это сам; среде, фиксирующей зависимости, нужен uv lock --upgrade-package greenlet. Только greenlet 3.3.1–3.5.4 требует MSVCP140.dll, которого нет ни в установщике python.org, ни в сборках, управляемых uv, и greenlet, собранный из исходников, может потребовать его в любой версии. Если версию изменить нельзя, Microsoft Visual C++ Redistributable предоставит эту DLL. Сообщено как greenlet#525, исправлено в greenlet#526.

Проблемы с сеансом:

• Профиль браузера хранится в ~/.linkedin-mcp/profile/

• Загруженные браузеры кэшируются в ~/.linkedin-mcp/patchright-browsers/

• Кэш браузера постоянно растёт: обновление сервера может принести новую ревизию Chromium, и Patchright хранит старую, пока на неё ссылается любая установленная версия. uvx хранит по одному архиву на каждую когда-либо запускавшуюся версию, поэтому каждая из них удерживает такую ссылку, и старые ревизии остаются. Сервер записывает в журнал предупреждение с указанием удерживаемых ревизий и занимаемого ими места. Чтобы освободить место, остановите все экземпляры LinkedIn MCP Server, удалите ~/.linkedin-mcp/patchright-browsers/ и позвольте следующему запуску загрузить текущий браузер.

• Убедитесь, что одновременно активен только один сеанс LinkedIn

Проблемы со входом:

• LinkedIn может потребовать подтверждения входа в мобильном приложении LinkedIn для --login

• LinkedIn может показать капчу при входе. Запустите uvx mcp-server-linkedin@latest --login, откроется браузер, где вы сможете решить её вручную.

Проблемы с тайм-аутом:

• Сбои операций на странице (элементы не найдены, зависает навигация): увеличьте тайм-аут операции страницы — --timeout 10000 или TIMEOUT=10000 (миллисекунды, по умолчанию 5000).

• Тайм-аут целых вызовов инструментов (например, многосекционные профили, холодный запуск Chromium, медленные контейнеры): увеличьте время выполнения инструмента — --tool-timeout 300 или TOOL_TIMEOUT=300 (секунды, по умолчанию 180).

• Первый вызов инструмента без сеанса: если в локальном браузере есть активный сеанс LinkedIn, сервер импортирует его автоматически (см. AUTO_IMPORT_FROM_BROWSER / --auto-import) вместо принудительного ручного входа. В macOS может появиться запрос из связки ключей для доступа к Safe Storage. Если импортируемого сеанса браузера нет, открывается окно входа, и сервер ждёт до LOGIN_INLINE_WAIT секунд (по умолчанию 25, макс. 45; --login-inline-wait), чтобы быстрый вход завершился за один вызов. Если время истекло, инструмент возвращает сигнал ожидания, и модель повторяет попытку примерно через 30 секунд. Ни автоимпорт, ни встроенное ожидание не применяются в Docker или при привязке HTTP-сервера к не-loopback-адресу. Создайте сеанс на хосте с помощью --login или используйте явную команду Docker --login --login-viewer.

• Пользователям с медленным соединением может потребоваться увеличить эти значения.

Сообщение о необходимости запустить --login на хосте, хотя вы это уже делали:

• Если вызовы инструментов отвечают «No valid LinkedIn session is available in Docker» на машине, которая не является контейнером, среда выполнения была определена неверно. Это происходило на Linux-хостах с запущенным демоном Docker для несвязанных сервисов. Установите LINKEDIN_MCP_CONTAINER=false, чтобы переопределить определение; true принудительно включает обратное.

Использование прокси:

Большинству людей он не нужен. Рекомендации самого LinkedIn по снижению количества проверок безопасности советуют избегать VPN и прокси, и он оценивает адреса, с которых выполняется вход. Домашнее подключение, которым вы пользуетесь годами, — это сигнал доверия; коммерческий выходной узел с неизвестной историей — нет, и переход на него сам по себе является тем изменением, которое вызывает проверку. Прокси оправдан в одном случае: сервер работает в месте, где его адрес явно принадлежит дата-центру, или в другой стране, чем история аккаунта. Но даже тогда выходной узел WireGuard или Tailscale в вашей домашней сети лучше любого платного провайдера, потому что адрес действительно ваш. Если вы всё же покупаете, берите выделенный статический ISP-адрес и сохраняйте его, а не ротационный резидентный пул.

• Направьте браузер через прокси с помощью --proxy-server http://host:port (принимаются http, https, socks4 и socks5). Маршрутизируется только трафик браузера, а не транспорт MCP.

• Учётные данные указываются в PROXY_USERNAME и PROXY_PASSWORD. Флага --proxy-password намеренно нет: аргументы командной строки доступны для чтения любому другому пользователю на машине. PROXY_SERVER также принимает комбинированную форму http://user:pass@host:port, которую выдают большинство провайдеров.

• Chromium не может проходить аутентификацию через SOCKS-прокси, поэтому для учётных данных требуется конечная точка http(s). Если ваш провайдер предлагает только аутентифицированный SOCKS5, запустите локальный ретранслятор, который хранит учётные данные, и укажите серверу на него.

• Локальные адреса также идут через прокси. Обычный прямой маршрут Chromium для localhost удаляется при установке прокси, поэтому добавьте PROXY_BYPASS=localhost,127.0.0.1,::1, если вам нужно напрямую обращаться к локальным целям.

• Автоимпорт пропускается при настроенном прокси: сессия, взятая из локального браузера, была создана с вашего реального адреса, и перенос её на прокси — это как раз то изменение, которое вызывает контрольную точку. Используйте --login.

• Неверный пароль прокси не сообщает о себе: Chromium повторяет попытки аутентификации до истечения времени ожидания страницы, поэтому это проявляется как тайм-аут или неудачный вход. Если сессии перестают работать сразу после добавления прокси, проверьте учётные данные, прежде чем предполагать, что сессия истекла.

• Настройте прокси до создания сессии. Запустите --login с уже настроенным прокси. Включение прокси для существующего профиля перемещает вошедшую сессию на новый IP-адрес, что и вызывает контрольную точку LinkedIn. То же самое относится к --import-from-browser, который импортирует сессию, созданную с вашего реального IP. По той же причине используйте липкую сессию, а не ротационный пул.

Пользовательский путь к Chrome:

• Если Chrome установлен в нестандартном месте, используйте --chrome-path /path/to/chrome

• Также можно задать через переменную окружения: CHROME_PATH=/path/to/chrome

• На macOS и Linux браузер должен быть не старше того, который последним открывал ваш профиль, иначе сервер откажется запускаться. (Не на Windows: там нельзя узнать версию браузера, не запустив его, поэтому проверка отключена.) Более старый браузер может молча потерять данные, записанные более новым, включая сохранённую сессию, и тогда сбой выглядит точно так же, как истёкший вход. В сообщении указываются обе версии. Обычный способ выполнить это требование — вернуться к встроенному Chromium после однократного запуска более нового Chrome; либо снова запустите более новый браузер, какой бы он ни был, либо выполните --login, который откладывает сохранённую сессию в сторону и выполняет новый вход с имеющимся у вас браузером. --logout также очищает её, но отбрасывает старую сессию вместо того, чтобы сохранить её восстанавливаемой, и запрашивает подтверждение в терминале, поэтому его нельзя использовать с сервера, запущенного MCP-клиентом.

• Только Chrome, Chromium и Chrome for Testing сравниваются таким образом. Форки нумеруются иначе (Vivaldi имеет версию 7.x, номер сборки Edge значительно ниже, чем у Chrome при том же мажорном номере), поэтому указание CHROME_PATH на такой браузер отключает проверку, а не вызывает отказ, которому ничто не могло бы удовлетворить.

📦 Claude Desktop MCP Bundle (ранее DXT)

Предварительные требования: Claude Desktop.

Установка в один клик для пользователей Claude Desktop:

1. Скачайте последний артефакт .mcpb из релизов

2. Нажмите на скачанный файл .mcpb, чтобы установить его в Claude Desktop

3. Вызовите любой инструмент LinkedIn

При запуске пакет MCP начинает в фоновом режиме подготовку общего кэша браузера Patchright Chromium. Если вы вызовете инструмент слишком рано, Claude покажет ошибку о выполняемой настройке. При первом вызове инструмента, требующего аутентификации, сервер открывает окно браузера для входа в LinkedIn и просит повторить попытку после входа.

Справка по настройке пакета MCP

Поведение при первой настройке:

• Claude Desktop запускает пакет немедленно; настройка браузера продолжается в фоновом режиме

• Если браузер Patchright Chromium всё ещё загружается, повторите попытку вызова инструмента через короткое время

• Управляемые загрузки браузера хранятся в ~/.linkedin-mcp/patchright-browsers/

• Кэш браузера продолжает расти: Patchright хранит старую ревизию Chromium до тех пор, пока любая установленная версия всё ещё ссылается на неё, поэтому при обновлении на диске могут остаться обе. Сервер записывает предупреждение с указанием того, что он хранит. Чтобы освободить место, остановите все экземпляры LinkedIn MCP Server, удалите ~/.linkedin-mcp/patchright-browsers/ и позвольте следующему запуску загрузить текущий браузер.

• Windows: пакет завершается с ошибкой DLL load failed while importing _greenlet: установите Microsoft Visual C++ Redistributable или переустановите пакет с закреплённой версией greenlet 3.5.5 или новее, чьи опубликованные Windows-колёса снова содержат среду выполнения C++ внутри расширения. Пакет с закреплённой версией greenlet с 3.3.1 по 3.5.4 требует MSVCP140.dll из этого распространяемого пакета, которого нет ни в установщике python.org, ни в сборках, управляемых uv, а greenlet, собранный из исходников, может потребовать его в любой версии. Сервер сам сообщает об этом при запуске, и только после проверки, что загрузчик не может создать эту DLL. Сообщено как greenlet#525, исправлено в greenlet#526.

Проблемы со входом:

• Убедитесь, что у вас одновременно активна только одна сессия LinkedIn

• LinkedIn может потребовать подтверждение входа в мобильном приложении LinkedIn для --login

• LinkedIn может показать капчу при входе. Запустите uvx mcp-server-linkedin@latest --login, который откроет браузер, где вы сможете решить капчу вручную. См. настройку uvx для предварительных требований.

Проблемы с тайм-аутом:

• Сбои операций со страницей (элементы не найдены, зависание навигации): увеличьте тайм-аут операций со страницей браузера — --timeout 10000 или TIMEOUT=10000 (миллисекунды, по умолчанию 5000).

• Тайм-аут целых вызовов инструментов (например, многосекционные профили, холодный запуск Chromium, медленные контейнеры): увеличьте тайм-аут выполнения для каждого инструмента — --tool-timeout 300 или TOOL_TIMEOUT=300 (секунды, по умолчанию 180).

• Первый вызов инструмента без сессии: если в локальном браузере с выполненным входом есть активная сессия LinkedIn, сервер автоматически импортирует её (см. AUTO_IMPORT_FROM_BROWSER / --auto-import) вместо принудительного ручного входа. На macOS связка ключей может один раз запросить доступ к Safe Storage. Если импортируемой сессии браузера нет, он переходит к открытию окна входа и ждёт до LOGIN_INLINE_WAIT секунд (по умолчанию 25, максимум 45; --login-inline-wait), чтобы быстрый вход завершился за один вызов. Если время ожидания истекло, инструмент возвращает сигнал ожидания, и модель повторяет попытку примерно через 30 секунд. Ни автоимпорт, ни встроенное ожидание не применяются в Docker или когда сервер привязан к не-петлевому HTTP-хосту. Создайте сессию на хосте с помощью --login или используйте явную команду Docker --login --login-viewer.

• Пользователям с медленным соединением могут потребоваться более высокие значения для любого из них.

Сообщение о необходимости запустить --login на хосте, когда вы уже это сделали:

• Если вызовы инструментов отвечают «No valid LinkedIn session is available in Docker» на машине, которая не является контейнером, среда выполнения была определена неверно. Это происходило на Linux-хостах, где запущен демон Docker для несвязанных сервисов. Установите LINKEDIN_MCP_CONTAINER=false, чтобы переопределить определение; true принудительно задаёт противоположное.

🐳 Настройка Docker

Предварительные требования: Убедитесь, что Docker установлен и запущен.

Аутентификация

Войдите один раз. Контейнер открывает браузер входа в LinkedIn, которым вы управляете из собственной вкладки браузера:

# Create the directory first so the container can save your session into it
mkdir -p ~/.linkedin-mcp
docker run -it --rm \
  -v ~/.linkedin-mcp:/home/pwuser/.linkedin-mcp \
  -p 127.0.0.1:6080:6080 \
  stickerdaniel/linkedin-mcp-server:latest \
  --login --login-viewer

Откройте полный URL, который выводит команда (он содержит токен доступа), и войдите. После этого просмотрщик закрывается сам; дайте команде завершиться самостоятельно, чтобы сессия была сохранена полностью. Он сдаётся через 30 минут.

Сохраняйте монтирование -v ~/.linkedin-mcp:/home/pwuser/.linkedin-mcp при каждом последующем docker run, иначе сервер не сможет найти сессию.

Настройка Claude Desktop с Docker

{
  "mcpServers": {
    "mcp-server-linkedin": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-v", "~/.linkedin-mcp:/home/pwuser/.linkedin-mcp",
        "stickerdaniel/linkedin-mcp-server:latest"
      ]
    }
  }
}

[!NOTE] Сессии со временем истекают. Когда вызовы инструментов начнут запрашивать аутентификацию, повторите команду входа выше или запустите uvx mcp-server-linkedin@latest --login на хосте.

Справка по настройке Docker

Режимы транспорта:

• По умолчанию (stdio): Стандартное взаимодействие для локальных MCP-серверов

• Streamable HTTP: Для веб-ориентированного MCP-сервера

• Если транспорт не указан, сервер по умолчанию использует stdio

• Интерактивный терминал без явного транспорта показывает запрос выбора

Параметры CLI:

• --log-level {DEBUG,INFO,WARNING,ERROR} - Уровень журналирования (по умолчанию: WARNING)

• --transport {stdio,streamable-http} - Принудительно задать режим транспорта (по умолчанию: stdio)

• --host HOST / --port PORT / --path PATH - Адрес HTTP-сервера (по умолчанию: 127.0.0.1, 8000, /mcp)

• --logout - Очистить сохранённую сессию и все профили, производные от неё

• --timeout MS - Тайм-аут для одной операции со страницей (по умолчанию: 5000)

• --tool-timeout SECONDS - Тайм-аут для всего вызова инструмента (по умолчанию: 180). Увеличьте его для тяжёлых парсингов, медленных сетей или холодного запуска браузера.

• --login-timeout SECONDS - Сколько времени браузер входа ждёт завершения вашего входа (по умолчанию: 1800; 0 = без ограничения). --login-viewer в любом случае завершает сессию через 30 минут.

• --login-viewer - Вместе с --login показывает браузер входа по защищённому токеном URL на порту 6080. Требует монтирования профиля из раздела Аутентификация.

• --login-inline-wait SECONDS - Сколько времени вызов инструмента ждёт завершения входа, прежде чем сообщить модели о повторной попытке (по умолчанию: 25, максимум 45; 0 = вернуть сразу)

• --browser-wait SECONDS - Сколько ждать, пока другой процесс сервера передаст общий браузер (по умолчанию: 25, максимум 45; 0 = сразу сообщить о занятости). Имеет значение только при одновременной работе нескольких MCP-клиентов.

• --browser-min-hold SECONDS - Минимальное время, в течение которого этот процесс удерживает общий браузер перед передачей (по умолчанию: 20). Ограничивается 3 секундами ниже --browser-wait, поэтому увеличивайте его вместе с ним. Большее значение означает меньше перезапусков браузера, но более длительное ожидание для других клиентов.

• --browser-idle-timeout SECONDS - Закрыть бездействующий браузер и освободить профиль после такого времени без вызова инструмента (по умолчанию: 600; 0 = держать открытым)

• --auto-import / --no-auto-import - Импортировать сессию из локального браузера с выполненным входом при первом вызове инструмента, которому она нужна, перед переходом к ручному входу (игнорируется в Docker). На macOS связка ключей может запросить доступ один раз.

• --user-data-dir PATH - Каталог профиля браузера (по умолчанию: ~/.linkedin-mcp/profile). Ротация или очистка сессии удаляет этот каталог и его родительский, в котором хранятся сохранённые куки и производные профили.

• --claim-profile-root - Взять на себя каталог профиля, который сервер не будет занимать сам, например, тот, чей родительский каталог уже содержит другие файлы. Требуется один раз для каждого каталога.

• --chrome-path PATH - Путь к исполняемому файлу Chrome/Chromium (редко требуется в Docker)

• --proxy-server URL - Направлять трафик браузера через прокси в формате scheme://host:port. Задайте пароль через PROXY_PASSWORD, чтобы он не попадал в список процессов.

[!NOTE] Обычный --login в Docker по-прежнему не имеет видимого окна. Добавьте --login-viewer и опубликуйте 127.0.0.1:6080:6080 только для одноразовой команды входа. Docker по умолчанию уже имеет графический интерфейс, поэтому --no-headless ничего не меняет. Экспериментальный --daemon игнорируется в Docker, потому что его владелец может пережить виртуальный дисплей.

Пример HTTP-режима (для веб-ориентированных MCP-клиентов):

docker run -it --rm \
  -v ~/.linkedin-mcp:/home/pwuser/.linkedin-mcp \
  -p 127.0.0.1:8080:8080 \
  stickerdaniel/linkedin-mcp-server:latest \
  --transport streamable-http --host 0.0.0.0 --port 8080 --path /mcp

Обе половины нужны, и они выполняют разные задачи. --host 0.0.0.0 делает сервер доступным внутри контейнера: процесс, привязанный к 127.0.0.1, вообще нельзя достичь через опубликованный порт. А 127.0.0.1: перед -p ограничивает доступ снаружи, только этой машиной. Уберите этот префикс — и Docker опубликует сервер на всех интерфейсах, что выставит в вашу сеть конечную точку без аутентификации. Сервер не может отличить один случай от другого, поэтому предупреждает в обоих.

Публикация через loopback ограничивает доступ машиной, а не контейнером. Другие контейнеры на том же хосте всё ещё могут достучаться до него через host.docker.internal там, где это имя резолвится, — так работает по умолчанию в Docker Desktop и OrbStack, но не в нативном Linux Docker.

Логи рантайм-сервера выводит FastMCP/Uvicorn.

HTTP-сервер отвечает на запросы, адресованные localhost или адресу, к которому он привязан, а остальные отклоняет с кодом 421. Именно это не позволяет сайту, который вы просто посетили, направить домен на этот сервер и использовать вашу LinkedIn-сессию через ваш же браузер.

Обращение к серверу по любому другому имени отклоняется, включая имя машины в вашей сети и публичное имя за обратным прокси. Либо настройте прокси на переписывание upstream-заголовка Host на адрес бэкенда, либо укажите имя хоста, под которым вы его отдаёте:

FASTMCP_HTTP_ALLOWED_HOSTS='["mcp.example"]'

Это разрешает ровно это имя и продолжает отклонять всё остальное. Конечная точка по-прежнему без аутентификации, поэтому всё, что доступно за пределами вашей машины, должно находиться за чем-то, что её обеспечивает.

Тест с mcp inspector:

1. Установите и запустите mcp inspector: bunx @modelcontextprotocol/inspector

2. Нажмите на предзаполненный token url, чтобы открыть inspector в браузере

3. Выберите Streamable HTTP как Transport Type

4. Установите URL в http://localhost:8080/mcp

5. Подключитесь

6. Протестируйте инструменты

Проблемы с Docker:

• Убедитесь, что Docker установлен

• Проверьте, запущен ли Docker: docker ps

• Ошибки прав доступа к ~/.linkedin-mcp: более ранний запуск Docker от root мог создать каталог от имени root. Исправьте через sudo chown -R "$(id -u):$(id -g)" ~/.linkedin-mcp.

Проблемы со входом:

• Убедитесь, что у вас одновременно активна только одна LinkedIn-сессия

• LinkedIn может потребовать подтверждения входа в мобильном приложении LinkedIn для --login

• LinkedIn может показать капчу при входе. Запустите uvx mcp-server-linkedin@latest --login — откроется браузер, где вы сможете решить капчу вручную. См. настройку uvx для предусловий.

• Если Docker-аутентификация устарела после повторного входа на хосте, перезапустите Docker один раз, чтобы он заново построил мост из новой исходной сессии.

Проблемы с таймаутами:

• Сбои операций со страницей (элементы не найдены, навигация зависает): увеличьте таймаут операций со страницей — --timeout 10000 или TIMEOUT=10000 (миллисекунды, по умолчанию 5000).

• Таймаут целых вызовов инструментов (например, многосекционные профили, холодный старт Chromium, медленные контейнеры): увеличьте таймаут выполнения инструмента — --tool-timeout 300 или TOOL_TIMEOUT=300 (секунды, по умолчанию 180).

• Первый вызов инструмента без сессии: если локально вошедший браузер имеет живую LinkedIn-сессию, сервер автоматически импортирует её (см. AUTO_IMPORT_FROM_BROWSER / --auto-import) вместо принудительного ручного входа. На macOS связка ключей может один раз запросить доступ к Safe Storage. Если импортируемой сессии браузера нет, сервер открывает окно входа и ждёт до LOGIN_INLINE_WAIT секунд (по умолчанию 25, максимум 45; --login-inline-wait), чтобы быстрый вход завершился за один вызов. Если время истекло, инструмент возвращает сигнал ожидания, и модель повторяет попытку примерно через 30 секунд. Ни автоимпорт, ни встроенное ожидание не применяются в Docker или когда сервер привязан к не-loopback HTTP-хосту. Создайте сессию на хосте через --login или используйте явную Docker-команду --login --login-viewer.

• Пользователям с медленным соединением могут понадобиться большие значения для обоих.

Вам говорят запустить --login на хосте, хотя вы уже это делали:

• Если вызовы инструментов отвечают «No valid LinkedIn session is available in Docker» на машине, которая не является контейнером, рантайм был определён неверно. Это случалось на Linux-хостах, где демон Docker запущен для несвязанных сервисов. Установите LINKEDIN_MCP_CONTAINER=false, чтобы переопределить определение; true принудительно включает обратное.

Использование прокси:

Большинству людей он не нужен. Рекомендации самого LinkedIn по снижению числа проверок безопасности — избегать VPN или прокси, и он оценивает адреса, с которых входит сессия. Домашнее подключение, которым вы пользуетесь годами, — сигнал доверия; коммерческий выходной узел с неизвестной историей — нет, и переход на него сам по себе является тем изменением, которое вызывает контрольную проверку. Прокси оправдан в одном случае: сервер работает там, где его адрес явно принадлежит дата-центру, или в другой стране, чем история аккаунта. Даже тогда выходной узел WireGuard или Tailscale в вашей домашней сети лучше любого платного провайдера, потому что адрес действительно ваш. Если вы всё же покупаете, берите выделенный статический ISP-адрес и держите его, а не ротационный резидентный пул.

• Направьте браузер через прокси с помощью --proxy-server http://host:port (принимаются http, https, socks4 и socks5). Маршрутизируется только трафик браузера, не MCP-транспорт.

• Учётные данные задаются в PROXY_USERNAME и PROXY_PASSWORD. Флага --proxy-password намеренно нет: аргументы командной строки читаются всеми остальными пользователями машины. PROXY_SERVER также принимает комбинированную форму http://user:pass@host:port, которую выдают большинство провайдеров.

• Chromium не может аутентифицироваться в SOCKS-прокси, поэтому для учётных данных нужна конечная точка http(s). Если провайдер предлагает только аутентифицированный SOCKS5, запустите локальный ретранслятор, который держит учётные данные, и укажите серверу на него.

• Локальные адреса тоже идут через прокси. Обычный прямой маршрут Chromium для localhost удаляется при установке прокси, поэтому добавьте PROXY_BYPASS=localhost,127.0.0.1,::1, если нужно напрямую достигать локальных целей.

• Автоимпорт пропускается при настроенном прокси: сессия, взятая из локального браузера, создана на вашем реальном адресе, и перенос её на прокси — то самое изменение, которое запускает проверку. Используйте --login.

• Неверный пароль прокси не сообщает о себе: Chromium повторяет запрос аутентификации, пока страница не истечёт по таймауту, поэтому это выглядит как таймаут или неудачный вход. Если сессии перестают работать сразу после добавления прокси, проверьте учётные данные, прежде чем считать сессию истёкшей.

• Настройте прокси до создания сессии. Запустите --login с уже настроенным прокси. Включение прокси для существующего профиля переносит вошедшую сессию на новый IP — это и запускает проверку LinkedIn. То же относится к --import-from-browser, который импортирует сессию, созданную на вашем реальном IP. Используйте липкую сессию, а не ротируемый пул, по той же причине.

Нестандартный путь Chrome:

• Если Chrome установлен в нестандартном месте, используйте --chrome-path /path/to/chrome

• Также можно задать через переменную окружения: CHROME_PATH=/path/to/chrome

• На macOS и Linux браузер должен быть не старше того, который последним открывал ваш профиль, иначе сервер откажется запускаться. (Не на Windows: там нельзя узнать версию браузера, не запустив его, поэтому проверка отключена.) Более старый браузер может молча потерять хранилища, записанные более новым, включая сохранённую сессию, и тогда сбой выглядит точно как истёкший вход. Сообщение называет обе версии. Возврат к встроенному Chromium после однократного запуска более нового Chrome — обычный способ выполнить это условие; либо запустите более новый браузер снова, какой бы он ни был, либо выполните --login, который откладывает сохранённую сессию и входит заново с тем браузером, что у вас есть. --logout тоже очищает её, но выбрасывает старую сессию вместо того, чтобы оставить её восстанавливаемой, и требует подтверждения в терминале, поэтому его нельзя использовать с сервера, запущенного MCP-клиентом.

• Только Chrome, Chromium и Chrome for Testing сравниваются таким образом. Форки нумеруют себя иначе (Vivaldi на 7.x, номер сборки Edge сидит далеко ниже Chrome при том же мажоре), поэтому указание CHROME_PATH на такой форк отключает проверку, а не вызывает отказ, которому ничто не могло бы удовлетворить.

• В документированной Docker-настройке эта проверка не применяется. Контейнер никогда не открывает профиль, созданный вами через --login; он выводит свой из ваших куки и по умолчанию пересобирает его с нуля при каждом старте, так что старому образу нечего понижать. С EXPERIMENTAL_PERSIST_DERIVED_RUNTIME производный профиль сохраняется, и тег образа, который откатывается назад, выбрасывает его и пересобирает заново — опять же, вам ничего делать не нужно. Проверка важна на хосте, где сервер открывает этот профиль напрямую. Не во время самого --login, который откладывает старый профиль до запуска браузера и потому никогда не может её сработать.

🐍 Локальная настройка (разработка и вклад)

Вклад приветствуется! См. CONTRIBUTING.md для архитектурных рекомендаций и чек-листов. Пожалуйста, откройте issue сначала, чтобы обсудить фичу или исправление бага перед отправкой PR.

Предусловия: установлены Git и uv

Установка

# 1. Clone repository
git clone https://github.com/stickerdaniel/linkedin-mcp-server
cd linkedin-mcp-server

# 2. Install UV package manager (if not already installed)
curl -LsSf https://astral.sh/uv/install.sh | sh

# 3. Install dependencies
uv sync
uv sync --group dev

# 4. Install pre-commit hooks
uv run pre-commit install

# 5. Start the server
uv run -m linkedin_mcp_server

Локальный сервер использует тот же управляемый рантайм-поток, что и MCPB и uvx: он готовит кэш браузера Patchright Chromium в фоне и открывает вход в LinkedIn при первом вызове инструмента, требующего аутентификации. Вы всё ещё можете запустить uv run -m linkedin_mcp_server --login, когда хотите создать сессию явно.

Помощь по локальной настройке

Параметры CLI:

• --login — открыть браузер для входа и сохранить сессию

• --import-from-browser [BROWSER] — переиспользовать сессию из локально вошедшего браузера Chromium (chrome, chromium, brave, edge, arc, vivaldi, helium, yandex, whale, auto). Голый флаг выбирает auto — самый недавно использованный браузер с живой LinkedIn-сессией.

• --status — проверить, действительна ли сохранённая сессия, затем выйти

• --logout — очистить сохранённую сессию

• --no-headless — показать окно браузера (полезно для отладки)

• --log-level {DEBUG,INFO,WARNING,ERROR} — уровень логирования (по умолчанию: WARNING)

• --transport {stdio,streamable-http} — принудительно задать режим транспорта (по умолчанию: stdio)

• --host HOST / --port PORT / --path PATH — адрес HTTP-сервера (по умолчанию: 127.0.0.1, 8000, /mcp)

• --timeout MS — таймаут одной операции со страницей (по умолчанию: 5000)

• --tool-timeout SECONDS — таймаут целого вызова инструмента (по умолчанию: 180). Увеличьте для тяжёлых скрейпов, медленных сетей или холодного старта браузера.

• --user-data-dir PATH — каталог профиля браузера (по умолчанию: ~/.linkedin-mcp/profile). Ротация или очистка сессии удаляет этот каталог и его родителя, в котором хранятся сохранённые куки и производные профили.

• --claim-profile-root — взять на себя каталог профиля, который сервер не станет забирать сам, например, если его родитель уже содержит другие файлы. Нужен один раз на каталог.

• --slow-mo MS — задержка между действиями браузера (по умолчанию: 0, полезно для отладки)

• --viewport WxH — размер окна просмотра (по умолчанию: 1280x720). Применяется только в безоконном режиме; при запуске с окном используется реальный размер окна.

• --chrome-path PATH — путь к исполняемому файлу Chrome/Chromium

• --proxy-server URL — направить трафик браузера через прокси в виде scheme://host:port. Пароль задаётся через PROXY_PASSWORD, что держит его вне списка процессов.

• --help — показать справку

Примечание: большинство параметров CLI имеют эквиваленты в переменных окружения. См. .env.example для деталей.

Пример HTTP-режима (для веб-клиентов MCP):

uv run -m linkedin_mcp_server --transport streamable-http --host 127.0.0.1 --port 8000 --path /mcp

Claude Desktop:

{
  "mcpServers": {
    "mcp-server-linkedin": {
      "command": "uv",
      "args": ["--directory", "/path/to/linkedin-mcp-server", "run", "-m", "linkedin_mcp_server"]
    }
  }
}

Для этой конфигурации по умолчанию используется stdio.

Проблемы со входом:

• Убедитесь, что одновременно активна только одна сессия LinkedIn

• LinkedIn может запросить подтверждение входа в мобильном приложении LinkedIn для --login

• LinkedIn может показать капчу при входе. Команда --login открывает браузер, где вы можете решить её вручную.

Проблемы со скрейпингом:

• Используйте --no-headless, чтобы видеть действия браузера и отлаживать проблемы скрейпинга

• Добавьте --log-level DEBUG, чтобы увидеть более подробное логирование

Проблемы с сессиями:

• Профиль браузера хранится в ~/.linkedin-mcp/profile/

• Загруженные управляемые браузеры кэшируются в ~/.linkedin-mcp/patchright-browsers/ и являются общими для установок uvx и MCP Bundle

• Кэш браузера постоянно растёт: Patchright хранит старую ревизию Chromium до тех пор, пока любая установленная версия всё ещё ссылается на неё, а архив uv или ещё один worktree является такой ссылкой. Сервер записывает в журнал предупреждение с указанием того, что он удерживает. Чтобы освободить место, остановите все экземпляры LinkedIn MCP Server, удалите ~/.linkedin-mcp/patchright-browsers/ и позвольте следующему запуску загрузить текущий браузер.

• Используйте --logout, чтобы очистить профиль и начать заново

Проблемы с Python/Patchright:

• Проверьте версию Python: python --version (должна быть 3.12+)

• Переустановите Patchright: uv run patchright install chromium

• Переустановите зависимости: uv sync --reinstall

Проблемы с тайм-аутами:

• Сбои операций со страницей (элементы не найдены, навигация зависает): увеличьте тайм-аут операций со страницей браузера — --timeout 10000 или TIMEOUT=10000 (миллисекунды, по умолчанию 5000).

• Тайм-аут целых вызовов инструментов (например, многосекционные профили, холодный старт Chromium, медленные контейнеры): увеличьте тайм-аут выполнения инструмента — --tool-timeout 300 или TOOL_TIMEOUT=300 (секунды, по умолчанию 180).

• Первый вызов инструмента без сессии: если в локально авторизованном браузере есть активная сессия LinkedIn, сервер автоматически импортирует её (см. AUTO_IMPORT_FROM_BROWSER / --auto-import) вместо принудительного ручного входа. В macOS связка ключей может один раз запросить доступ к Safe Storage. Если импортируемой сессии браузера нет, сервер в качестве запасного варианта открывает окно входа и ждёт до LOGIN_INLINE_WAIT секунд (по умолчанию 25, максимум 45; --login-inline-wait), чтобы быстрый вход завершился за один вызов. Если время ожидания истекло, инструмент возвращает сигнал ожидания, и модель повторяет попытку примерно через 30 секунд. Ни автоимпорт, ни встроенное ожидание не применяются ни в Docker, ни когда сервер привязан к не-loopback HTTP-хосту. Создайте сессию на хосте с помощью --login либо используйте явную команду Docker --login --login-viewer.

• Пользователям с медленным соединением могут потребоваться более высокие значения для любого из этих параметров.

Если вам говорят выполнить --login на хосте, когда вы уже это сделали:

• Если вызовы инструментов отвечают "No valid LinkedIn session is available in Docker" на машине, которая не является контейнером, среда выполнения была определена неверно. Это происходило на Linux-хостах, где демон Docker запущен для несвязанных сервисов. Установите LINKEDIN_MCP_CONTAINER=false, чтобы переопределить это определение; true принудительно задаёт противоположное.

Использование прокси:

Большинству людей использовать прокси не стоит. Рекомендации LinkedIn по снижению числа проверок безопасности — избегать VPN или прокси; кроме того, LinkedIn оценивает адреса, с которых входит сессия. Домашнее подключение, которым вы пользуетесь годами, — сигнал доверия; коммерческий выходной узел с неизвестной вам историей — нет, и переход на него сам по себе является тем изменением, которое вызывает контрольную проверку. Прокси оправдан в одном случае: сервер работает там, где его адрес явно принадлежит дата-центру либо находится в другой стране, нежели история аккаунта. Даже тогда выходной узел WireGuard или Tailscale в вашей домашней сети лучше любого платного провайдера, потому что адрес действительно ваш. Если вы всё же покупаете прокси, возьмите выделенный статический адрес у интернет-провайдера и сохраняйте его, а не вращающийся пул резидентных адресов.

• Направляйте браузер через прокси с помощью --proxy-server http://host:port (поддерживаются http, https, socks4 и socks5). Через прокси направляется только трафик браузера, а не транспорт MCP.

• Учётные данные задаются в PROXY_USERNAME и PROXY_PASSWORD. Флага --proxy-password намеренно нет: аргументы командной строки доступны для чтения всем остальным пользователям машины. PROXY_SERVER также принимает комбинированную форму http://user:pass@host:port, которую выдают большинство провайдеров.

• Chromium не может проходить аутентификацию в SOCKS-прокси, поэтому для учётных данных требуется конечная точка http(s). Если ваш провайдер предлагает только аутентифицированный SOCKS5, запустите локальный ретранслятор, хранящий учётные данные, и укажите серверу на него.

• Локальные адреса тоже идут через прокси. Обычный прямой маршрут Chromium для localhost удаляется при настройке прокси, поэтому добавьте PROXY_BYPASS=localhost,127.0.0.1,::1, если вам нужно обращаться к локальным целям напрямую.

• Автоимпорт пропускается при настроенном прокси: сессия, взятая из локального браузера, была создана с вашего реального адреса, и перенос её на прокси — это как раз то изменение, которое вызывает контрольную проверку. Используйте --login.

• Неверный пароль прокси не сообщает о себе: Chromium повторяет запрос аутентификации, пока не истечёт тайм-аут страницы, поэтому проблема проявляется как тайм-аут или неудачный вход. Если сессии перестают работать сразу после добавления прокси, проверьте учётные данные, прежде чем считать, что сессия истекла.

• Настройте прокси до создания сессии. Запустите --login с уже настроенным прокси. Включение прокси для существующего профиля переносит активную сессию на новый IP — именно это и вызывает контрольную проверку LinkedIn. То же самое относится к --import-from-browser, который импортирует сессию, созданную с вашего реального IP. По той же причине используйте фиксированную (sticky) сессию, а не вращающийся пул.

Нестандартный путь к Chrome:

• Если Chrome установлен в нестандартном месте, используйте --chrome-path /path/to/chrome

• Его также можно задать через переменную окружения: CHROME_PATH=/path/to/chrome

• На macOS и Linux браузер должен быть не старше того, который последним открывал ваш профиль; в противном случае сервер отказывает в запуске. (Не относится к Windows: там невозможно узнать версию браузера, не запустив его, поэтому проверка отключена.) Более старый браузер может молча отбросить хранилища, записанные более новым, в том числе сохранённую сессию, и тогда сбой выглядит точно так же, как истёкший вход. В сообщении называются обе версии. Обычный способ удовлетворить это требование — вернуться к встроенному Chromium после однократного запуска более нового Chrome; либо снова запустите тот более новый браузер, какой бы он ни был, либо выполните --login, который откладывает сохранённую сессию в сторону и выполняет вход заново в имеющемся браузере. --logout тоже очищает её, но отбрасывает старую сессию, не оставляя возможности её восстановить, и запрашивает подтверждение в терминале, поэтому его нельзя использовать с сервера, запущенного MCP-клиентом.

• Так сравниваются только Chrome, Chromium и Chrome for Testing. Форки нумеруют себя иначе (у Vivaldi версия 7.x, а номер сборки Edge при том же мажорном номере значительно ниже, чем у Chrome), поэтому указание CHROME_PATH на такой браузер отключает проверку, а не приводит к отказу, которому невозможно соответствовать.

[!IMPORTANT] FAQ

Безопасно ли это использовать? Меня могут забанить? Этот инструмент управляет реальной сессией браузера; он не использует недокументированные API и не обходит аутентификацию. Пользовательское соглашение LinkedIn запрещает автоматизированный доступ, а аккаунты, использующие автоматизированные инструменты, могут быть ограничены или заблокированы. Используйте на свой страх и риск; гарантий безопасности аккаунта нет. Если вы столкнётесь с какими-либо проблемами, сообщите мне в Обсуждениях.

Что, если мои агенты выполнят слишком много действий? Вызовы инструментов выполняются последовательно через очередь. Вы несёте ответственность за объём автоматизации, который запускаете; используйте её умеренно и давайте агентам ответственные инструкции.

Благодарности

Создано с помощью FastMCP и Patchright.

Используйте в соответствии с Пользовательским соглашением LinkedIn. Автоматизированный доступ может нарушать условия LinkedIn и приводить к ограничениям аккаунта. Этот инструмент предназначен только для личного использования и не предоставляет никаких гарантий.

Лицензия

Этот проект лицензируется в соответствии с лицензией Apache 2.0.