LinkedIn MCP Server

• デフォルト（stdio）：ローカル MCP サーバー向けの標準的な通信方式
• Streamable HTTP：ウェブベースの MCP サーバー向け
• トランスポートを指定しない場合、サーバーはデフォルトで stdio を使用します
• 対話型ターミナルでトランスポートを明示しない場合は、選択メニューが表示されます

セッション：

トランスポート:

• --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-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 = 開いたままにする）

ブラウザー:

• --no-headless - ブラウザーウィンドウを表示します（デバッグに便利です）
• --chrome-path PATH - Chrome/Chromium 実行ファイルへのパス
• --proxy-server URL - ブラウザーのトラフィックをプロキシ経由でルーティングします（scheme://host:port 形式）。--login の前に設定してください。プロキシの使用を参照してください。

その他:

• --log-level {DEBUG,INFO,WARNING,ERROR} - ログレベル（デフォルト: WARNING）

Chrome、Chromium、Brave、Edge、Arc、Vivaldi、Helium、Yandex、Naver Whale、Cốc Cốc、Opera、Opera GX のいずれかで 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 は、実際のログイン時にディスク上に保存される Cookie セットと一致します。ローカルサーバーは、保存済みのプロファイルから 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 つのクライアントだけで、ほかのクライアントは短時間待機し、呼び出しが完了するとすぐに使用を引き継ぎます。待機時間が長すぎるクライアントには「browser is busy」メッセージが表示されますが、そのまま再試行できます。待機／取得／解放のログを確認するには、--log-level DEBUG を使用してください。

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

mcp inspector でテストする：

1. mcp inspector bunx @modelcontextprotocol/inspector をインストールして実行します
2. 入力済みのトークン URL をクリックして、ブラウザーで inspector を開きます
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 までのバージョンのみです。この DLL は python.org のインストーラーにも uv 管理のビルドにも含まれていません。また、ソースからビルドした greenlet では、どのバージョンでも必要になることがあります。バージョンを変更できない場合は、Microsoft Visual C++ 再頒布可能パッケージ からその DLL を入手できます。greenlet#525 で報告され、greenlet#526 で修正されました。

• 同時にアクティブな LinkedIn セッションを 1 つだけにしてください
• LinkedIn は --login のために LinkedIn モバイルアプリでのログイン確認を要求する場合があります
• LinkedIn はログイン中に captcha チャレンジを表示する場合があります。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 コマンドを使用してください。
• 低速な接続のユーザーは、いずれについてもより高い値が必要になる場合があります。

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

• 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 のアクティブなセッションが一度に 1 つだけであることを確認してください
• --login の際、LinkedIn モバイルアプリでログイン確認を求められる場合があります
• ログイン中に LinkedIn から CAPTCHA チャレンジが表示される場合があります。ブラウザーを開いて CAPTCHA を手動で解決できる 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 コマンドを使用してください。
• 接続が遅い場合は、どちらかの値を大きくする必要がある場合があります。

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

セッション：

• --login - ブラウザーを開いてサインインし、セッションを保存します
• --import-from-browser [BROWSER] - ローカルでサインイン済みの Chromium ブラウザー（chrome、chromium、brave、edge、arc、vivaldi、helium、yandex、whale、coccoc、opera、opera_gx、auto）からセッションを再利用します。引数なしで指定すると auto が選択され、LinkedIn の有効なセッションがあるブラウザーのうち、最後に使用したものを選びます。
• --auto-import / --no-auto-import - セッションが必要な最初のツール呼び出し時に、手動ログインにフォールバックする前に、サインイン済みのローカルブラウザーからセッションをインポートします（デフォルト：オン）。Docker 内、プロキシ経由、およびループバック以外の HTTP バインドではスキップされます。macOS ではキーチェーンから一度だけ確認を求められる場合があります。
• --status - 保存されたセッションが有効かどうかを確認して終了します
• --logout - 保存されたセッションを消去します
• --user-data-dir PATH - ブラウザープロファイルのディレクトリ（デフォルト：~/.linkedin-mcp/profile）。セッションをローテーションまたは消去すると、このディレクトリとその親ディレクトリが削除されます。親ディレクトリには、保存された Cookie と派生プロファイルが格納されています。
• --claim-profile-root - サーバーが自動では取得しないプロファイルディレクトリ（親にほかのファイルがあるディレクトリなど）を取得します。ディレクトリごとに一度だけ必要です。

トランスポート：

• --transport {stdio,streamable-http} - トランスポートモードを強制します（デフォルト：stdio）
• --host HOST / --port PORT / --path PATH - HTTP サーバーのアドレス（デフォルト：127.0.0.1、8000、/mcp）

タイムアウト：

• --timeout MS - 1 回のページ操作のタイムアウト（デフォルト：5000）
• --tool-timeout SECONDS - ツール呼び出し全体のタイムアウト（デフォルト：180）。多数のページを読み込む呼び出し、ネットワークが遅い場合、またはブラウザーのコールドスタート時は値を大きくしてください。
• --login-timeout SECONDS - サインインを完了するまでログインブラウザーが待機する時間（デフォルト：1800、0 = 無制限）。--login-viewer を使うと、いずれの場合も 30 分後にセッションが終了します。
• --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 = 開いたままにする）

ブラウザー：

• --no-headless - ブラウザーウィンドウを表示します（デバッグに便利です）
• --slow-mo MS - ブラウザー操作間の遅延（デフォルト: 0、デバッグに便利です）
• --viewport WxH - ビューポートサイズ（デフォルト: 1280x720）。ウィンドウなしモードにのみ適用されます。ヘッド付き起動では実際のウィンドウサイズが使用されます。
• --chrome-path PATH - Chrome/Chromium 実行ファイルへのパス
• --installer-temp-dir PATH - ブラウザーインストールの一時ファイル用の既存ディレクトリ（環境変数: INSTALLER_TEMP_DIR）。
• --proxy-server URL - ブラウザーのトラフィックをプロキシ経由でルーティングします。形式は scheme://host:port です。--login の前に設定してください。詳しくはプロキシの使用を参照してください。

その他:

• --log-level {DEBUG,INFO,WARNING,ERROR} - ログレベル（デフォルト: WARNING）
• --help - ヘルプを表示します

Note: ほとんどの 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 つだけアクティブにしてください
• --login では、LinkedIn モバイルアプリでのログイン確認が必要になる場合があります
• ログイン時に LinkedIn が captcha チャレンジを表示することがあります。--login コマンドはブラウザーを開くので、そこで手動で解決できます。

• ツールが誤ったデータや欠落したデータを返す場合は、--no-headless を使用してブラウザーを確認してください
• --log-level DEBUG を追加すると、より詳細なログを確認できます

• ブラウザープロファイルは ~/.linkedin-mcp/profile/ に保存されます
• 管理対象ブラウザーのダウンロードは ~/.linkedin-mcp/patchright-browsers/ にキャッシュされ、uvx および MCP Bundle のインストールと共有されます
• ブラウザーキャッシュが増え続ける: Patchright は、インストールされているいずれかのバージョンが参照している限り、古い Chromium リビジョンを保持します。uv アーカイブや 2 つ目のワークツリーもそのような参照です。サーバーは、保持しているものを特定する警告をログに記録します。領域を解放するには、すべての LinkedIn MCP サーバーインスタンスを停止し、~/.linkedin-mcp/patchright-browsers/ を削除して、次回の起動で現在のブラウザーをダウンロードさせてください。
• --logout を使用すると、プロファイルを消去して新たに開始できます

• Python のバージョンを確認してください: python --version（3.12.4 以降である必要があります）
• 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 コマンドを使用してください。
• 低速な接続のユーザーは、いずれかにより大きな値が必要になる場合があります。

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

• Chrome が標準以外の場所にインストールされている場合は、--chrome-path /path/to/chrome を使用してください。
• 環境変数で設定することもできます：CHROME_PATH=/path/to/chrome
• macOS と Linux では、ブラウザーはプロファイルを最後に開いたブラウザーと同じか、それより新しいバージョンである必要があります。そうでない場合、サーバーは起動を拒否します。（Windows では該当しません。ブラウザーを起動せずにバージョンを確認できないため、このチェックは無効です。）古いブラウザーでは、新しいブラウザーが書き込んだデータが保存セッションも含めて気付かないうちに削除されることがあり、その場合のエラーはログインの期限切れとまったく同じように見えます。メッセージには両方のバージョンが表示されます。新しい Chrome を一度実行した後に同梱の Chromium に戻した場合は、通常この状況になります。新しい方のブラウザーをもう一度実行するか、--login を実行してください。保存されたセッションを別の場所に移動し、現在使用中のブラウザーで新たにサインインします。--logout でもセッションを消去できますが、古いセッションは復元可能な状態で保持されず、ターミナルで確認を求められるため、MCP クライアントが起動したサーバーからは使用できません。
• この方法で比較するのは Chrome、Chromium、Chrome for Testing のみです。派生ブラウザーではバージョン番号の付け方が異なります（Vivaldi は 7.x で、Edge のビルド番号は同じメジャーバージョンでも Chrome よりかなり小さいためです）。そのため、CHROME_PATH に派生ブラウザーを指定すると、満たせないバージョン条件で起動を拒否するのではなく、チェックが無効になります。