MCP Server for LinkedIn

免責事項: これは独立したコミュニティプロジェクトです。LinkedIn Corporation や Microsoft と提携しておらず、承認、推奨、スポンサーは一切受けていません。「LinkedIn」は LinkedIn Corporation の登録商標であり、このソフトウェアが相互運用する第三者のサービスを識別するという説明目的でのみ使用されています。

Claude のような AI アシスタントが、あなた自身のログイン済みブラウザセッションを通じて LinkedIn のデータを読み取れるようにする MCP サーバーです。プロフィールや企業へのアクセス、求人検索、求人詳細の取得ができます。

スポンサー

この MCP サーバーは無料かつオープンソースであり、Unipile のサポートを受けています。ローカル環境で、あなた自身のブラウザセッションを使用して動作します。Unipile はフルマネージドのクラウド代替サービスで、Classic、Sales Navigator、Recruiter 向けのホスト型 LinkedIn API を提供し、認証、セッション、インフラストラクチャをすべて処理します。7日間無料でお試しください →

Related MCP server: MCP LinkedIn Sales Navigator

Installation Methods - 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: Web ベースの 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 ブラウザをポート 6080 のトークン保護付き URL で表示します（認証 を参照）

• --login-inline-wait SECONDS - ツール呼び出しがログイン完了を待ってからモデルに再試行を指示するまでの時間（デフォルト: 25、最大 45、0 = 即座に返す）

• --browser-wait SECONDS - 別のサーバープロセスが共有ブラウザを引き渡すのを待つ時間（デフォルト: 25、最大 45、0 = 即座にビジーを報告）。複数の MCP クライアントを同時に実行している場合にのみ関係します。

• --browser-min-hold SECONDS - このプロセスが共有ブラウザを引き渡す前に保持する最短時間（デフォルト: 20）。--browser-wait より 3 秒短くクランプされるため、それと一緒に引き上げてください。値を大きくするとブラウザの再起動は減りますが、他のクライアントの待ち時間は長くなります。

• --browser-idle-timeout SECONDS - ツール呼び出しがないままこの時間が経過すると、アイドル状態のブラウザを閉じてプロファイルを解放します（デフォルト: 600、0 = 開いたままにする）

• --auto-import / --no-auto-import - 最初のツール呼び出しで、手動ログインにフォールバックする前に、サインイン済みのローカルブラウザからセッションをインポートします（デフォルト: オン）。Docker、プロキシ経由、非ループバック HTTP バインドではスキップされます。macOS ではキーチェーンが一度プロンプトを表示する場合があります。

• --user-data-dir PATH - ブラウザプロファイルディレクトリ（デフォルト: ~/.linkedin-mcp/profile）。セッションのローテーションまたはクリアでは、このディレクトリ とその親ディレクトリ（保存された Cookie と派生プロファイルを保持）が削除されます。

• --claim-profile-root - サーバーが単独では取得しないプロファイルディレクトリ（親ディレクトリに他のファイルがすでにあるものなど）を取得します。ディレクトリごとに 1 回必要です。

• --chrome-path PATH - Chrome/Chromium 実行ファイルへのパス

• --proxy-server URL - scheme://host:port としてブラウザトラフィックをプロキシ経由でルーティングします。パスワードは PROXY_PASSWORD で設定します。これによりプロセスリストからパスワードが除外されます。

日常使用のブラウザからセッションをインポート:

Chrome、Chromium、Brave、Edge、Arc、Vivaldi、Helium、Yandex、または Naver Whale で LinkedIn にすでにサインインしている場合、手動の --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 Cookie が読み取られ、フィードに対して検証され、--login が書き込むのと同じ場所である ~/.linkedin-mcp/profile/ に保存されます。注意点:

• 複数のサインイン済みブラウザがある場合、最も最近使用されたライブ LinkedIn セッションが最初に試行されます。LinkedIn がそれを拒否した場合（失効またはリモートログアウト）、次に最近のものが自動的に試行され、サーバーが受け入れた最初のものがインポートされます。選択プロンプトはありません。特定のブラウザを対象にするにはブラウザ名を渡してください。

• macOS では、OS のキーチェーンがブラウザの Safe Storage へのアクセス許可を求める場合があります。最も確実に読み取るには、最初にソースブラウザを閉じてください。

• Chrome 127+ のアプリバウンド暗号化（v20）で保護された Cookie は、OS の昇格なしでは復号できません。その場合は代わりに --login を使用してください。

• インポートされた Cookie は、実際のログインのディスク上のセットと一致します。ローカルサーバーは保存されたプロファイルからそれらを完全に読み戻します。Docker ブリッジは、通常のセッションで使用するのと同じ最小限の認証サブセットに絞り込みます。

基本的な使用例:

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

HTTP モードの例（Web ベースの MCP クライアント向け）:

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

ランタイムサーバーログは FastMCP/Uvicorn によって出力されます。

ツール呼び出しは、共有 LinkedIn ブラウザセッションを保護するために、単一のサーバープロセス内と複数のプロセス間の両方で直列化されます。複数の MCP クライアントを同時に実行する場合、各クライアントが独自のサーバープロセスを開始し、一度にブラウザを使用するのはそのうちの 1 つだけです。他のクライアントは短時間待機し、呼び出しが完了するとすぐに引き継ぎます。待ち時間が長すぎるクライアントは「ブラウザはビジーです」というメッセージを受け取り、単純に再試行できます。待機/取得/解放のログを確認するには --log-level DEBUG を使用してください。

これは同じマシン上および同じランタイム内のプロセスを対象としています。同じ ~/.linkedin-mcp ディレクトリを共有するホストと Docker コンテナ間には拡張されないため、コンテナの実行中にホスト上で --login または --logout を実行しないでください。

mcp inspector でテスト:

1. mcp inspector をインストールして実行します bunx @modelcontextprotocol/inspector

2. 事前入力されたトークン URL をクリックして、ブラウザでインスペクタを開きます

3. Transport Type として Streamable HTTP を選択します

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 依存関係をダウンロードします。低速接続では、uv のデフォルトの 30 秒 HTTP タイムアウトが短すぎる場合があります。上記の推奨設定では、これを回避するためにすでに UV_HTTP_TIMEOUT=300（秒）が設定されています。

• Windows で DLL load failed while importing _greenlet が発生する場合: greenlet 3.5.5 以降に移行してください。公開されている Windows ホイールには C++ ランタイムが拡張機能内に再び含まれています。新しい uvx 実行で自動的に解決されます。依存関係を固定する環境では uv lock --upgrade-package greenlet が必要です。MSVCP140.dll が必要なのは greenlet 3.3.1 から 3.5.4 のみで、python.org インストーラも uv 管理ビルドもこれを提供しておらず、ソースからビルドされた greenlet はどのバージョンでも必要になる可能性があります。バージョンを変更できない場合は、Microsoft Visual C++ 再頒布可能パッケージ がその DLL を提供します。greenlet#525 として報告され、greenlet#526 で修正されました。

セッションの問題:

• ブラウザプロファイルは ~/.linkedin-mcp/profile/ に保存されます

• 管理されたブラウザのダウンロードは ~/.linkedin-mcp/patchright-browsers/ にキャッシュされます

• ブラウザキャッシュが増え続ける場合: サーバーのアップグレードで新しい Chromium リビジョンが導入されることがあり、Patchright はインストールされているバージョンがまだ参照している限り古いものを保持します。uvx は実行したことのあるバージョンごとに 1 つのアーカイブを保持するため、それぞれがそのような参照を保持し、古いリビジョンは残り続けます。サーバーは保持しているリビジョンとその容量を警告としてログに記録します。領域を回復するには、すべての LinkedIn MCP Server インスタンスを停止し、~/.linkedin-mcp/patchright-browsers/ を削除して、次の起動で現在のブラウザをダウンロードさせてください。

• 同時にアクティブな LinkedIn セッションは 1 つだけにしてください

ログインの問題:

• LinkedIn は --login の際に LinkedIn モバイルアプリでのログイン確認を要求する場合があります

• 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）待機して、迅速なサインインが 1 回の呼び出しで解決されるようにします。待機時間が経過すると、ツールは保留シグナルを返し、モデルは約 30 秒後に再試行します。自動インポートもインライン待機も、Docker 下またはサーバーが非ループバック HTTP ホストにバインドされている場合には適用されません。ホスト上で --login を使用してセッションを作成するか、明示的な Docker コマンド --login --login-viewer を使用してください。

• 低速接続のユーザーは、いずれかの値を高くする必要がある場合があります。

すでに実行したのにホスト上で --login を実行するよう指示された場合:

• コンテナではないマシンでツール呼び出しが「Docker で有効な LinkedIn セッションがありません」と応答する場合、ランタイムが誤検出されています。これは、無関係なサービス用に Docker デーモンを実行している Linux ホストで発生しました。LINKEDIN_MCP_CONTAINER=false を設定して検出を上書きしてください。true は逆を強制します。

プロキシの使用:

ほとんどの人は使用すべきではありません。 セキュリティチャレンジを減らすための LinkedIn 自身のガイダンスは、VPN やプロキシを避けることであり、セッションがサインインするアドレスをスコアリングします。何年も使用してきた自宅の接続は信頼シグナルです。履歴が見えない商用の出口ノードはそうではなく、それに切り替えること自体がチェックポイントをトリガーする種類の変更です。プロキシが価値があるのは 1 つのケースです。サーバーがアドレスが明らかにデータセンターである場所、またはアカウントの履歴とは異なる国で実行されている場合です。それでも、自宅のネットワーク上の 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 のみを提供している場合は、認証情報を保持するローカルリレーを実行し、サーバーをそのリレーに向けてください。

• ローカルアドレスもプロキシ経由になります。プロキシ設定時は localhost への通常の直接ルートが削除されるため、ローカルターゲットに直接到達する必要がある場合は PROXY_BYPASS=localhost,127.0.0.1,::1 を追加してください。

• プロキシ設定中は自動インポートはスキップされます。ローカルブラウザから取得したセッションは実際のアドレスで作成されたものであり、それをプロキシに移すことがチェックポイントを誘発するまさにその変更となるためです。--login を使用してください。

• プロキシパスワードの誤りはエラーとして報告されません。Chromium はページがタイムアウトするまで認証チャレンジを再試行するため、タイムアウトまたはサインイン失敗として表面化します。プロキシを追加した直後にセッションが機能しなくなった場合は、セッションの期限切れを疑う前に認証情報を確認してください。

• セッションを作成する前にプロキシを設定してください。 プロキシを設定した状態で --login を実行してください。既存のプロファイルにプロキシを有効にすると、ログイン済みセッションが新しい IP に移動され、これが LinkedIn のチェックポイントを誘発します。同じ理由で、実際の IP で作成されたセッションをインポートする --import-from-browser にも同じことが当てはまります。ローテーション方式のプールではなく、スティッキーセッションを使用してください。

カスタム Chrome パス:

• Chrome が標準以外の場所にインストールされている場合は、--chrome-path /path/to/chrome を使用します。

• 環境変数 CHROME_PATH=/path/to/chrome でも設定できます。

• macOS と Linux では、ブラウザはプロファイルを最後に開いたブラウザと同じかそれより新しいバージョンである必要があり、そうでない場合、サーバーは起動を拒否します。（Windows では該当しません。Windows では起動せずにブラウザのバージョンを確認できないため、このチェックは無効になっています）。古いブラウザは、新しいブラウザが書き込んだストア（保存済みセッションを含む）を静かに削除する可能性があり、その場合、障害はログイン期限切れとまったく同じように見えます。メッセージには両方のバージョンが表示されます。新しい Chrome を一度実行した後にバンドル版の Chromium に戻すと、この問題が発生することがよくあります。どちらのブラウザでもよいので新しい方を再度実行するか、--login を実行してください。これにより、保存済みセッションが退避され、現在のブラウザで新規にサインインします。--logout もセッションをクリアしますが、回復可能な形で保持するのではなく破棄し、ターミナルで確認を求めるため、MCP クライアントが起動したサーバーからは使用できません。

• この比較が行われるのは Chrome、Chromium、Chrome for Testing のみです。フォークはバージョン番号の付け方が異なるため（Vivaldi は 7.x、Edge のビルド番号は同じメジャーでも Chrome よりはるかに低い）、CHROME_PATH をフォークに向けると、拒否が発生するのではなくチェックが無効になります。

📦 Claude Desktop MCP バンドル (旧 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 サーバーインスタンスを停止し、~/.linkedin-mcp/patchright-browsers/ を削除して、次回起動時に現在のブラウザをダウンロードさせてください。

• Windows で、バンドルが DLL load failed while importing _greenlet で終了する場合: Microsoft Visual C++ 再頒布可能パッケージ をインストールするか、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 セッションが 1 つだけであることを確認してください。

• LinkedIn は --login の際に LinkedIn モバイルアプリでのログイン確認を要求する場合があります。

• ログイン中に 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）待機してから、すばやいサインインで 1 回の呼び出しで解決できるようにします。待機時間が経過すると、ツールは保留シグナルを返し、モデルは約 30 秒後に再試行します。自動インポートとインライン待機の両方とも、Docker 内またはサーバーがループバック以外の HTTP ホストにバインドされている場合は適用されません。ホスト上で --login を使用してセッションを作成するか、明示的な Docker の --login --login-viewer コマンドを使用してください。

• 低速な接続のユーザーは、どちらの場合もより高い値が必要になる場合があります。

すでに実行したのにホストで --login を実行するように言われた場合:

• コンテナではないマシンでツール呼び出しが「No valid LinkedIn session is available in Docker」と応答する場合、ランタイムが誤検出されています。これは、無関係なサービス用の Docker デーモンが実行されている Linux ホストで発生しました。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 分でタイムアウトします。

後続のすべての docker run で -v ~/.linkedin-mcp:/home/pwuser/.linkedin-mcp マウントを維持してください。そうしないと、サーバーはセッションを見つけることができません。

Docker で Claude Desktop を設定する

{
  "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 サーバー用の標準通信

• ストリーミング可能な HTTP: Web ベースの 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 と一緒に使用すると、ポート 6080 のトークン保護された URL でログインブラウザを表示します。認証 のプロファイルマウントが必要です。

• --login-inline-wait SECONDS - モデルに再試行を指示する前に、ツール呼び出しがログインの完了を待機する時間（デフォルト: 25、最大 45、0 = すぐに返す）

• --browser-wait SECONDS - 共有ブラウザの引き継ぎを別のサーバープロセスが行うのを待機する時間（デフォルト: 25、最大 45、0 = すぐにビジーを報告）。複数の MCP クライアントを同時に実行している場合にのみ関係します。

• --browser-min-hold SECONDS - このプロセスが共有ブラウザを引き継ぐ前に保持する最小時間（デフォルト: 20）。--browser-wait の 3 秒下にクランプされるため、一緒に引き上げてください。値が大きいほどブラウザの再起動は少なくなりますが、他のクライアントの待ち時間は長くなります。

• --browser-idle-timeout SECONDS - ツール呼び出しがないままこの時間が経過すると、アイドル状態のブラウザを閉じてプロファイルを解放します（デフォルト: 600、0 = 開いたままにする）

• --auto-import / --no-auto-import - 手動ログインにフォールバックする前に、最初のツール呼び出しでサインイン済みのローカルブラウザからセッションをインポートします（Docker では無視されます）。macOS ではキーチェーンが一度だけプロンプトを表示する場合があります。

• --user-data-dir PATH - ブラウザのプロファイルディレクトリ（デフォルト: ~/.linkedin-mcp/profile）。セッションのローテーションまたはクリアにより、このディレクトリとその親ディレクトリ（保存された Cookie と派生プロファイルを保持）が削除されます。

• --claim-profile-root - サーバーが単独では取得しないプロファイルディレクトリ（親に他のファイルがすでにあるディレクトリなど）を引き継ぎます。ディレクトリごとに 1 回必要です。

• --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 モードの例（Web ベースの 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 にバインドされたプロセスは、公開ポート経由ではまったく到達できないからです。-p の前にある 127.0.0.1: は、外部をこのマシンに限定するためのものです。このプレフィックスを外すと、Docker はすべてのインターフェースで公開し、認証のないエンドポイントがネットワーク上にさらされます。サーバーはこの2つを区別できないため、どちらの場合でも警告を出します。

ループバック公開は、これをコンテナではなくマシンに限定します。同じホスト上の他のコンテナは、host.docker.internal が解決される場所であれば、そこを通じて到達できます。これは Docker Desktop と OrbStack ではデフォルトですが、ネイティブの Linux Docker ではそうではありません。

ランタイムサーバーログは FastMCP/Uvicorn によって出力されます。

HTTP サーバーは localhost またはバインド先のアドレス宛のリクエストに応答し、それ以外は 421 で拒否します。これにより、あなたが訪れただけの Web サイトが、このサーバーにドメインを向けて、あなた自身のブラウザ経由で LinkedIn セッションを利用することを防ぎます。

他の名前でサーバーに到達しようとすると拒否されます。ネットワーク上のマシン名や、リバースプロキシの前にある公開名も含みます。プロキシが上流の Host をバックエンドアドレスに書き換えるか、配信するホスト名を指定してください:

FASTMCP_HTTP_ALLOWED_HOSTS='["mcp.example"]'

これにより、その名前だけが許可され、それ以外はすべて拒否され続けます。エンドポイントには依然として認証がないため、自分のマシン以外から到達可能なものはすべて、認証を提供する何かの背後に置く必要があります。

mcp inspector でテストする:

1. mcp inspector をインストールして実行する bunx @modelcontextprotocol/inspector

2. 事前入力されたトークン URL をクリックして、ブラウザで inspector を開く

3. Transport Type として Streamable HTTP を選択する

4. URL を http://localhost:8080/mcp に設定する

5. 接続する

6. ツールをテストする

Docker の問題:

• Docker がインストールされていることを確認する

• Docker が実行中か確認する: docker ps

• ~/.linkedin-mcp の権限エラー: 古い rootful Docker 実行でディレクトリが root として作成された可能性があります。sudo chown -R "$(id -u):$(id -g)" ~/.linkedin-mcp で修正してください。

ログインの問題:

• 同時にアクティブな LinkedIn セッションが1つだけであることを確認する

• LinkedIn は --login の際に LinkedIn モバイルアプリでのログイン確認を要求する場合があります

• 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) 待機して、素早いサインインが1回の呼び出しで解決できるようにします。待機時間が経過すると、ツールは保留シグナルを返し、モデルは約30秒後に再試行します。自動インポートもインライン待機も、Docker 環境下やサーバーが非ループバックの HTTP ホストにバインドされている場合は適用されません。ホスト上で --login を使用してセッションを作成するか、明示的な Docker コマンド --login --login-viewer を使用してください。

• 遅い接続のユーザーは、どちらもより高い値が必要な場合があります。

すでに実行したのにホストで --login を実行するよう指示された場合:

• コンテナではないマシンでツール呼び出しが「No valid LinkedIn session is available in Docker」と応答する場合、ランタイムが誤検出されています。これは、無関係なサービス用に Docker デーモンが実行されている Linux ホストで発生しました。LINKEDIN_MCP_CONTAINER=false を設定して検出を上書きしてください。true は逆を強制します。

プロキシを使用する場合:

ほとんどの人は使用すべきではありません。 セキュリティチャレンジを減らすための LinkedIn 自身のガイダンスは、VPN やプロキシを避けることです。また、セッションがサインインするアドレスをスコアリングします。何年も使用してきた自宅の接続は信頼シグナルです。履歴が見えない商用の出口ノードはそうではなく、そこに切り替えること自体がチェックポイントを引き起こす種類の変更です。 プロキシが価値があるのは1つのケースです。サーバーが明らかにデータセンターのアドレスを持つ場所、またはアカウントの履歴とは異なる国で実行されている場合です。それでも、自宅のネットワーク上の 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 のみを提供している場合は、認証情報を保持するローカルリレーを実行し、サーバーをそこに向けてください。

• ローカルアドレスもプロキシ経由になります。プロキシが設定されると、localhost に対する Chromium の通常の直接ルートが削除されるため、ローカルターゲットに直接到達する必要がある場合は PROXY_BYPASS=localhost,127.0.0.1,::1 を追加してください。

• プロキシが設定されている間は自動インポートがスキップされます。ローカルブラウザから取得したセッションは実際のアドレスで作成されたものであり、それをプロキシに移すことはチェックポイントを引き起こすまさにその変更だからです。--login を使用してください。

• プロキシパスワードの誤りは自己報告されません。Chromium はページがタイムアウトするまで認証チャレンジを再試行するため、タイムアウトまたはサインイン失敗として表面化します。プロキシを追加した直後にセッションが機能しなくなった場合は、セッションの期限切れを想定する前に認証情報を確認してください。

• セッションを作成する前にプロキシを設定してください。 プロキシがすでに設定された状態で --login を実行してください。既存のプロファイルにプロキシをオンにすると、ログイン済みセッションが新しい IP に移動し、それが LinkedIn のチェックポイントを引き起こします。同じ理由で、実際の IP で作成されたセッションをインポートする --import-from-browser にも同じことが当てはまります。同じ理由で、ローテーションプールではなくスティッキーセッションを使用してください。

カスタム Chrome パス:

• Chrome が標準以外の場所にインストールされている場合は、--chrome-path /path/to/chrome を使用してください

• 環境変数でも設定できます: CHROME_PATH=/path/to/chrome

• macOS と Linux では、ブラウザはプロファイルを最後に開いたブラウザと少なくとも同じくらい新しいバージョンである必要があり、そうでない場合サーバーは起動を拒否します。(Windows では該当しません。Windows のブラウザは起動せずにバージョンを尋ねることができないため、チェックはオフになっています。) 古いブラウザは、新しいブラウザが書き込んだストア (保存されたセッションを含む) を黙って破棄する可能性があり、その失敗は期限切れのログインとまったく同じように見えます。メッセージは両方のバージョンを明示します。新しい Chrome を一度実行した後にバンドルされた Chromium に戻るのが、これを満たす通常の方法です。どちらであれ、新しい方のブラウザを再度実行するか、--login を実行してください。--login は保存されたセッションを脇に移動し、手元のブラウザで新しくサインインします。--logout もセッションをクリアしますが、回復可能な状態で保持するのではなく古いセッションを破棄し、ターミナルで確認を求めるため、MCP クライアントが起動したサーバーからは使用できません。

• この比較が行われるのは Chrome、Chromium、Chrome for Testing のみです。フォークはバージョン番号の付け方が異なるため (Vivaldi は 7.x、Edge のビルド番号は同じメジャーで Chrome よりはるかに低い)、CHROME_PATH をフォークに向けると、満たすことのできない拒否を生成するのではなく、チェックがオフになります。

• ドキュメント化された Docker セットアップでは、このチェックは適用されません。コンテナは --login で作成したプロファイルを開くことはなく、クッキーから独自のプロファイルを導出し、デフォルトでは起動のたびにゼロから再構築するため、古いイメージがダウングレードするものは何もありません。EXPERIMENTAL_PERSIST_DERIVED_RUNTIME を使用すると導出プロファイルが保持され、後方に移動するイメージタグはそれを破棄して再導出します。これもあなたが何かする必要はありません。このチェックが重要になるのはホスト上で、サーバーがそのプロファイルを直接開く場合です。--login 自体の間は該当しません。--login はブラウザを起動する前に古いプロファイルを脇に移動するため、決してトリップしません。

🐍 ローカルセットアップ (開発 & コントリビュート)

コントリビュートを歓迎します! アーキテクチャのガイドラインとチェックリストについては CONTRIBUTING.md を参照してください。PR を送信する前に、まず issue を開いて 機能やバグ修正について話し合ってください。

前提条件: 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 - サーバーが単独では取得しないプロファイルディレクトリ (親に他のファイルがすでにあるものなど) を引き継ぐ。ディレクトリごとに1回必要です。

• --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 モードの例 (Web ベースの 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セッションを1つだけにしてください

• LinkedInはモバイルアプリでのログイン確認を要求する場合があります。--login コマンドは手動で解決できるブラウザを開きます。

• LinkedInはログイン中にCAPTCHAチャレンジを表示する場合があります。--login コマンドは手動で解決できるブラウザを開きます。

スクレイピングの問題：

• --no-headless を使用してブラウザの動作を確認し、スクレイピングの問題をデバッグします

• --log-level DEBUG を追加して、より詳細なログを表示します

セッションの問題：

• ブラウザプロファイルは ~/.linkedin-mcp/profile/ に保存されます

• 管理されたブラウザのダウンロードは ~/.linkedin-mcp/patchright-browsers/ にキャッシュされ、uvx およびMCPバンドルインストールと共有されます

• ブラウザキャッシュが増え続ける場合：Patchrightは、インストールされているバージョンがまだ参照している限り、古いChromiumリビジョンを保持します。uv アーカイブやセカンドワークツリーもそのような参照になります。サーバーは保持しているものを示す警告をログに記録します。スペースを解放するには、すべてのLinkedIn MCPサーバーインスタンスを停止し、~/.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）待機して、クイックサインインを1回の呼び出しで解決します。待機が経過すると、ツールは保留シグナルを返し、モデルは約30秒後に再試行します。自動インポートもインライン待機も、Docker環境やサーバーが非ループバックHTTPホストにバインドされている場合には適用されません。ホスト上で --login を使用してセッションを作成するか、明示的なDocker --login --login-viewer コマンドを使用してください。

• 遅い接続のユーザーは、どちらの値も増やす必要がある場合があります。

--login を既に実行したのにホスト上で実行するように指示された場合：

• ツール呼び出しが「Dockerで有効なLinkedInセッションがありません」と応答するが、マシンがコンテナではない場合、ランタイムが誤検出されています。これは、無関係なサービス用のDockerデーモンが動作しているLinuxホストで発生しました。LINKEDIN_MCP_CONTAINER=false を設定して検出を上書きします。true は逆を強制します。

プロキシの使用：

ほとんどの人はプロキシを使うべきではありません。 LinkedIn自身のガイダンスでは、セキュリティチャレンジを減らすためにVPNやプロキシを避けることを推奨しており、セッションのサインイン元アドレスを評価します。長年使用している自宅の接続は信頼シグナルです。履歴が見えない商用の出口ノードはそうではなく、切り替え自体がチェックポイントをトリガーする種類の変更です。 プロキシが価値があるのは1つのケースです：サーバーが明らかにデータセンターのアドレスで実行されている場合、またはアカウントの履歴と異なる国で実行されている場合です。その場合でも、自宅ネットワーク上のWireGuardやTailscaleの出口ノードが、どの有料プロバイダーよりも優れています。購入する場合は、ローテーションする住宅用プールではなく、専用の静的ISPアドレスを選んで維持してください。

• --proxy 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のみを提供する場合は、認証情報を保持するローカルリレーを実行し、サーバーをそのリレーに向けてください。

• ローカルアドレスもプロキシを経由します。プロキシが設定されると、localhost へのChromiumの通常の直接ルートが削除されるため、ローカルターゲットに直接到達する必要がある場合は PROXY_BYPASS=localhost,127.0.0.1,::1 を追加してください。

• プロキシが設定されている間は自動インポートはスキップされます：ローカルブラウザから取得したセッションは実際のアドレスで作成されたものであり、それをプロキシに移動することはチェックポイントをトリガーするまさにその変更だからです。--login を使用してください。

• プロキシのパスワードが間違っていても自己報告されません：Chromiumはページがタイムアウトするまで認証チャレンジを再試行し続けるため、タイムアウトやサインイン失敗として表面化します。プロキシを追加した直後にセッションが動作しなくなった場合は、セッションが期限切れになったと決めつける前に、まず認証情報を確認してください。

• セッションを作成する前にプロキシを設定してください。 既存のプロファイルでプロキシをオンにすると、ログイン済みセッションが新しいIPに移動され、それがLinkedInのチェックポイントをトリガーします。--import-from-browser で実際のIPで作成されたセッションをインポートする場合も同様です。ローテーションするプールではなく、スティッキーセッションを使用してください。

カスタムChromeパス：

• Chromeが非標準の場所にインストールされている場合は、--chrome-path /path/to/chrome を使用します

• 環境変数でも設定可能：CHROME_PATH=/path/to/chrome

• macOSとLinuxでは、ブラウザはプロファイルを最後に開いたものと同じかそれ以上に新しいバージョンである必要があります。そうでない場合、サーバーは起動を拒否します。（Windowsでは該当しません：そこではバージョンを起動せずに確認する方法がないため、チェックはオフになっています。）古いブラウザは、新しいブラウザが書き込んだ保存セッションをサイレントにドロップする可能性があり、失敗は期限切れのログインとまったく同じように見えます。メッセージは両方のバージョンを明示します。新しいChromeを一度実行した後にバンドルされたChromiumに戻るのは、この問題を解決する通常の方法です。新しいブラウザを再度実行するか、--login を実行してください。--login は保存されたセッションを脇に移動し、現在のブラウザで新しくサインインします。--logout も同様にクリアしますが、回復可能な状態で保持するのではなく破棄し、ターミナルで確認を求めるため、MCPクライアントが開始したサーバーからは使用できません。

• 比較されるのはChrome、Chromium、Chrome for Testingのみです。フォークは異なるバージョン番号を持ちます（Vivaldiは7.x、Edgeのビルド番号は同じメジャーでChromeよりはるかに低い）ため、CHROME_PATH をフォークに向けると、チェックがオフになり、満たせない拒否を生成する代わりになります。

[!IMPORTANT] FAQ

これは安全に使えますか？アカウントが停止されますか？ このツールは実際のブラウザセッションを制御します。未公開のAPIを悪用したり、認証を回避したりするものではありません。LinkedInの利用規約は自動化されたアクセスを禁止しており、自動化ツールを使用するアカウントは制限や停止の対象となる可能性があります。自己責任で使用してください。アカウントの安全性は保証されません。問題が発生した場合は、Discussions でお知らせください。

エージェントが多すぎるアクションを実行したらどうなりますか？ ツール呼び出しはキューを通じて順次実行されます。実行する自動化の量に対する責任はあなたにあります。控えめに使用し、エージェントに責任あるプロンプトを与えてください。

謝辞

FastMCP と Patchright で構築されています。

LinkedInの利用規約 に従って使用してください。自動化されたアクセスはLinkedInの規約に違反する可能性があり、アカウント制限につながる恐れがあります。このツールは個人使用のみを目的としており、いかなる種類の保証もありません。

ライセンス

このプロジェクトはApache 2.0ライセンスの下でライセンスされています。