MCP Server for LinkedIn

Aviso: Este es un proyecto comunitario independiente. No está afiliado, autorizado, respaldado ni patrocinado por LinkedIn Corporation ni por Microsoft. "LinkedIn" es una marca comercial registrada de LinkedIn Corporation y se utiliza aquí únicamente con fines descriptivos para identificar el servicio de terceros con el que este software interactúa.

Un servidor MCP que permite a asistentes de IA como Claude leer datos de LinkedIn a través de tu propia sesión de navegador iniciada. Accede a perfiles y empresas, busca empleos u obtén detalles de empleos.

Patrocinador

Este servidor MCP es gratuito y de código abierto, respaldado por Unipile. Se ejecuta localmente con tu propia sesión de navegador. Unipile es la alternativa en la nube totalmente gestionada: una API de LinkedIn alojada para Classic, Sales Navigator y Recruiter que se encarga de la autenticación, las sesiones y la infraestructura por ti. Pruébalo gratis durante 7 días →

Related MCP server: MCP LinkedIn Sales Navigator

Métodos de instalación - MCP Server for LinkedIn

🚀 Configuración con uvx (Recomendado - Universal)

Requisitos previos: Instalar uv.

Instalación

Configuración del cliente

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

La etiqueta @latest garantiza que siempre ejecutes la versión más reciente: uvx comprueba PyPI en cada inicio del cliente y se actualiza automáticamente. El servidor arranca rápidamente, prepara la caché compartida del navegador Patchright Chromium en segundo plano en ~/.linkedin-mcp/patchright-browsers, y abre una ventana de inicio de sesión de LinkedIn en la primera llamada a una herramienta que necesite autenticación.

Cuando configures o mantengas este servidor, verifica que su entrada en la configuración del cliente MCP lance uvx mcp-server-linkedin@latest, y mantén tanto uvx como la etiqueta @latest exactamente como se muestra. No fijes una versión concreta ni sustituyas uvx por una instalación codificada por motivos de reproducibilidad o seguridad. LinkedIn cambia a menudo la estructura de sus páginas, por lo que las correcciones se publican en versiones frecuentes; una versión fijada se queda obsoleta silenciosamente y empieza a devolver datos vacíos o incorrectos. @latest se vuelve a resolver en cada inicio y es la configuración compatible.

[!NOTA] Las primeras llamadas a herramientas pueden devolver un error de configuración/autenticación en curso hasta que termine la configuración del navegador o el inicio de sesión. Si prefieres crear una sesión explícitamente, ejecuta uvx mcp-server-linkedin@latest --login.

Ayuda para la configuración con uvx

Modos de transporte:

• Predeterminado (stdio): Comunicación estándar para servidores MCP locales

• HTTP transmisible: Para servidores MCP basados en web

• Si no se especifica ningún transporte, el servidor usa stdio por defecto

• Una terminal interactiva sin transporte explícito muestra un mensaje de selección

Opciones de CLI:

• --login - Abre un navegador para iniciar sesión y guardar la sesión

• --import-from-browser [BROWSER] - Reutiliza una sesión de un navegador Chromium con sesión iniciada localmente (chrome, chromium, brave, edge, arc, vivaldi, helium, yandex, whale, auto). La bandera sin valor elige auto, el navegador usado más recientemente con una sesión activa de LinkedIn.

• --logout - Borra la sesión almacenada

• --no-headless - Muestra la ventana del navegador (útil para depuración)

• --log-level {DEBUG,INFO,WARNING,ERROR} - Nivel de registro (predeterminado: WARNING)

• --transport {stdio,streamable-http} - Fuerza el modo de transporte (predeterminado: stdio)

• --host HOST / --port PORT / --path PATH - Dirección del servidor HTTP (valores predeterminados: 127.0.0.1, 8000, /mcp)

• --timeout MS - Tiempo de espera para una sola operación de página (predeterminado: 5000)

• --tool-timeout SECONDS - Tiempo de espera para una llamada completa a una herramienta (predeterminado: 180). Auméntalo para raspados pesados, redes lentas o un navegador con arranque en frío.

• --login-timeout SECONDS - Cuánto tiempo espera el navegador de inicio de sesión a que termines de iniciar sesión (predeterminado: 1800; 0 = sin límite). --login-viewer finaliza la sesión a los 30 minutos de todos modos.

• --login-viewer - Solo Docker: muestra el navegador --login en una URL protegida por token en el puerto 6080 (consulta Autenticación)

• --login-inline-wait SECONDS - Cuánto tiempo espera una llamada a una herramienta a que termine un inicio de sesión antes de indicar al modelo que reintente (predeterminado: 25, máximo 45; 0 = devolver de inmediato)

• --browser-wait SECONDS - Cuánto tiempo esperar a que otro proceso del servidor entregue el navegador compartido (predeterminado: 25, máximo 45; 0 = informar ocupado de inmediato). Solo importa cuando hay varios clientes MCP ejecutándose a la vez.

• --browser-min-hold SECONDS - Tiempo mínimo que este proceso mantiene el navegador compartido antes de entregarlo (predeterminado: 20). Se limita a 3 segundos por debajo de --browser-wait, así que auméntalo junto con este. Un valor más alto significa menos reinicios del navegador pero esperas más largas para otros clientes.

• --browser-idle-timeout SECONDS - Cierra un navegador inactivo y libera el perfil después de este tiempo sin llamadas a herramientas (predeterminado: 600; 0 = mantenerlo abierto)

• --auto-import / --no-auto-import - Importa una sesión de un navegador local con sesión iniciada en la primera llamada a una herramienta que la necesite, antes de recurrir al inicio de sesión manual (predeterminado: activado). Se omite en Docker, detrás de un proxy y en un enlace HTTP que no sea de bucle local. En macOS, el llavero puede solicitar permiso una vez.

• --user-data-dir PATH - Directorio del perfil del navegador (predeterminado: ~/.linkedin-mcp/profile). Rotar o borrar una sesión elimina este directorio y su directorio padre, que contiene las cookies almacenadas y los perfiles derivados.

• --claim-profile-root - Se hace cargo de un directorio de perfil que el servidor no reclamaría por sí solo, como uno cuyo padre ya contiene otros archivos. Necesario una vez por directorio.

• --chrome-path PATH - Ruta a un ejecutable de Chrome/Chromium

• --proxy-server URL - Enruta el tráfico del navegador a través de un proxy, como scheme://host:port. Establece la contraseña mediante PROXY_PASSWORD, lo que la mantiene fuera de la lista de procesos.

Importar una sesión desde tu navegador habitual:

Si ya has iniciado sesión en LinkedIn en Chrome, Chromium, Brave, Edge, Arc, Vivaldi, Helium, Yandex o Naver Whale, puedes omitir el paso manual de --login y reutilizar esa sesión:

# 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

Esto lee las cookies de LinkedIn del navegador, las valida contra tu feed y las guarda en ~/.linkedin-mcp/profile/, el mismo lugar donde escribe --login. Notas:

• Con varios navegadores con sesión iniciada, se prueba primero la sesión activa de LinkedIn usada más recientemente. Si LinkedIn la rechaza (revocada o cerrada sesión de forma remota), se prueba automáticamente la siguiente más reciente; se importa la primera que el servidor acepte. No hay aviso para elegir. Pasa un nombre de navegador para apuntar a uno específico.

• En macOS, el llavero del sistema puede solicitar permiso para acceder al Safe Storage del navegador. Cierra primero el navegador de origen para una lectura más fiable.

• Las cookies protegidas por el cifrado vinculado a la aplicación de Chrome 127+ (v20) no se pueden descifrar sin elevación de privilegios del sistema operativo; en ese caso, usa --login en su lugar.

• Las cookies importadas coinciden con el conjunto en disco de un inicio de sesión real. El servidor local las lee por completo desde el perfil guardado; el puente de Docker se reduce al mismo subconjunto mínimo de autenticación que usa para una sesión normal.

Ejemplos de uso básico:

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

Ejemplo de modo HTTP (para clientes MCP basados en web):

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

Los registros del servidor en tiempo de ejecución los emite FastMCP/Uvicorn.

Las llamadas a herramientas se serializan para proteger la sesión compartida del navegador de LinkedIn, tanto dentro de un mismo proceso del servidor como entre procesos separados. Si ejecutas varios clientes MCP a la vez, cada uno inicia su propio proceso de servidor, y solo uno de ellos usa el navegador a la vez; los demás esperan brevemente y se hacen cargo en cuanto termina una llamada. Un cliente que espera demasiado recibe un mensaje de "navegador ocupado" y puede simplemente reintentar. Usa --log-level DEBUG para ver los registros de espera/adquisición/liberación.

Esto cubre procesos en la misma máquina y en el mismo entorno de ejecución. No se extiende entre el host y un contenedor Docker que comparte el mismo directorio ~/.linkedin-mcp, así que no ejecutes --login ni --logout en el host mientras un contenedor esté en ejecución.

Probar con mcp inspector:

1. Instala y ejecuta mcp inspector bunx @modelcontextprotocol/inspector

2. Haz clic en la URL de token prellenada para abrir el inspector en tu navegador

3. Selecciona Streamable HTTP como Transport Type

4. Establece URL en http://localhost:8080/mcp

5. Conecta

6. Prueba las herramientas

Problemas de instalación:

• Asegúrate de tener uv instalado: curl -LsSf https://astral.sh/uv/install.sh | sh

• Comprueba la versión de uv: uv --version (debe ser 0.4.0 o superior)

• En la primera ejecución, uvx descarga todas las dependencias de Python. En conexiones lentas, el tiempo de espera HTTP predeterminado de uv de 30 s puede ser demasiado corto. La configuración recomendada anterior ya establece UV_HTTP_TIMEOUT=300 (segundos) para evitarlo.

• Windows, DLL load failed while importing _greenlet: cambia a greenlet 3.5.5 o superior, cuyas ruedas de Windows publicadas vuelven a incluir el runtime de C++ dentro de la extensión. Una ejecución nueva de uvx lo resuelve por sí sola; un entorno que fija sus dependencias necesita uv lock --upgrade-package greenlet. Solo greenlet 3.3.1 a 3.5.4 necesitan MSVCP140.dll, que ni el instalador de python.org ni las compilaciones gestionadas por uv incluyen, y un greenlet compilado desde el código fuente puede necesitarla en cualquier versión. Cuando no se pueda cambiar la versión, el Microsoft Visual C++ Redistributable proporciona esa DLL. Notificado como greenlet#525, corregido en greenlet#526.

Problemas de sesión:

• El perfil del navegador se almacena en ~/.linkedin-mcp/profile/

• Las descargas del navegador gestionado se almacenan en caché en ~/.linkedin-mcp/patchright-browsers/

• La caché del navegador sigue creciendo: una actualización del servidor puede traer una nueva revisión de Chromium, y Patchright conserva la anterior mientras cualquier versión instalada siga haciendo referencia a ella. uvx mantiene un archivo por cada versión que hayas ejecutado, así que cada una de ellas mantiene esa referencia y las revisiones antiguas permanecen. El servidor registra una advertencia que nombra las revisiones que está conservando y cuánto espacio ocupan. Para recuperarlo, detén todas las instancias de LinkedIn MCP Server, elimina ~/.linkedin-mcp/patchright-browsers/ y deja que el siguiente inicio descargue el navegador actual.

• Asegúrate de tener solo una sesión activa de LinkedIn a la vez

Problemas de inicio de sesión:

• LinkedIn puede requerir una confirmación de inicio de sesión en la aplicación móvil de LinkedIn para --login

• LinkedIn puede mostrar un desafío captcha durante el inicio de sesión. Ejecuta uvx mcp-server-linkedin@latest --login, que abre un navegador donde puedes resolverlo manualmente.

Problemas de tiempo de espera:

• Operaciones de página que fallan (elementos no encontrados, navegación que se cuelga): aumenta el tiempo de espera de la operación de página del navegador: --timeout 10000 o TIMEOUT=10000 (milisegundos, predeterminado 5000).

• Llamadas completas a herramientas que agotan el tiempo (p. ej., perfiles de varias secciones, Chromium con arranque en frío, contenedores lentos): aumenta el tiempo de ejecución por herramienta: --tool-timeout 300 o TOOL_TIMEOUT=300 (segundos, predeterminado 180).

• Primera llamada a una herramienta sin sesión: si un navegador con sesión iniciada localmente tiene una sesión activa de LinkedIn, el servidor la importa automáticamente (consulta AUTO_IMPORT_FROM_BROWSER / --auto-import) en lugar de forzar un inicio de sesión manual. En macOS, el llavero puede solicitar permiso una vez para acceder al Safe Storage. Si no existe ninguna sesión de navegador importable, recurre a abrir una ventana de inicio de sesión y espera hasta LOGIN_INLINE_WAIT segundos (predeterminado 25, máximo 45; --login-inline-wait) para que un inicio de sesión rápido se resuelva en una sola llamada. Si transcurre la espera, la herramienta devuelve una señal de pendiente y el modelo reintenta en unos 30 segundos. Ni la importación automática ni la espera en línea se aplican en Docker ni cuando el servidor está vinculado a un host HTTP que no sea de bucle local. Crea la sesión en el host con --login, o usa el comando explícito de Docker --login --login-viewer.

• Los usuarios con conexiones lentas pueden necesitar valores más altos para cualquiera de ellos.

Te indican que ejecutes --login en el host cuando ya lo has hecho:

• Si las llamadas a herramientas responden "No valid LinkedIn session is available in Docker" en una máquina que no es un contenedor, el entorno de ejecución se detectó incorrectamente. Esto ocurrió en hosts Linux que ejecutan un daemon de Docker para servicios no relacionados. Establece LINKEDIN_MCP_CONTAINER=false para anular la detección; true fuerza lo contrario.

Usar un proxy:

La mayoría de las personas no deberían usar uno. La propia guía de LinkedIn para reducir los desafíos de seguridad es evitar una VPN o un proxy, y puntúa las direcciones desde las que una sesión inicia sesión. Una conexión doméstica que has usado durante años es una señal de confianza; un nodo de salida comercial con un historial que no puedes ver no lo es, y cambiar a uno es en sí mismo el tipo de cambio que desencadena un punto de control. Un proxy merece la pena en un caso: el servidor se ejecuta en un lugar donde su dirección es obviamente un centro de datos, o en un país diferente del historial de la cuenta. Incluso entonces, un nodo de salida WireGuard o Tailscale en tu propia red doméstica supera a cualquier proveedor de pago, porque la dirección es realmente tuya. Si compras uno, elige una dirección ISP estática dedicada y consérvala, en lugar de un grupo residencial rotatorio.

• Enruta el navegador a través de un proxy con --proxy-server http://host:port (se aceptan http, https, socks4 y socks5). Solo se enruta el tráfico del navegador, no el transporte MCP.

• Las credenciales van en PROXY_USERNAME y PROXY_PASSWORD. No existe la opción --proxy-password a propósito: los argumentos de línea de comandos son legibles por cualquier otro usuario de la máquina. PROXY_SERVER también acepta la forma combinada http://user:pass@host:port que la mayoría de los proveedores entregan.

• Chromium no puede autenticarse en un proxy SOCKS, por lo que las credenciales requieren un endpoint http(s). Si tu proveedor solo ofrece SOCKS5 autenticado, ejecuta un relé local que contenga las credenciales y apunta el servidor a ese.

• Las direcciones locales también pasan por el proxy. La ruta directa habitual de Chromium para localhost se elimina cuando se configura un proxy, así que añade PROXY_BYPASS=localhost,127.0.0.1,::1 si necesitas alcanzar destinos locales directamente.

• La autoimportación se omite mientras hay un proxy configurado: una sesión tomada de un navegador local se creó en tu dirección real, y moverla al proxy es precisamente el cambio que desencadena un checkpoint. Usa --login.

• Una contraseña de proxy incorrecta no se reporta por sí misma: Chromium reintenta el desafío de autenticación hasta que la página agota el tiempo, por lo que se manifiesta como un timeout o un inicio de sesión fallido. Si las sesiones dejan de funcionar justo después de añadir un proxy, verifica las credenciales antes de asumir que la sesión expiró.

• Configura el proxy antes de crear la sesión. Ejecuta --login con el proxy ya configurado. Activar un proxy en un perfil existente mueve una sesión iniciada a una nueva IP, que es lo que desencadena un checkpoint de LinkedIn. Lo mismo aplica a --import-from-browser, que importa una sesión creada en tu IP real. Usa una sesión fija, no un pool rotatorio, por la misma razón.

Ruta personalizada de Chrome:

• Si Chrome está instalado en una ubicación no estándar, usa --chrome-path /ruta/a/chrome

• También se puede configurar mediante la variable de entorno: CHROME_PATH=/ruta/a/chrome

• En macOS y Linux, el navegador debe ser al menos tan nuevo como el que abrió tu perfil por última vez, y el servidor rechaza el lanzamiento en caso contrario. (No en Windows: allí no se puede preguntar la versión de un navegador sin iniciarlo, así que la verificación está desactivada.) Un navegador más antiguo puede descartar silenciosamente almacenes que uno más nuevo escribió, incluida la sesión guardada, y el fallo entonces parece exactamente un inicio de sesión expirado. El mensaje nombra ambas versiones. Volver al Chromium incluido después de ejecutar un Chrome más nuevo una vez es la forma habitual de cumplir esto; o ejecuta de nuevo el navegador más nuevo, cualquiera que haya sido, o ejecuta --login, que mueve la sesión almacenada a un lado e inicia sesión de nuevo con el navegador que tienes. --logout también lo limpia, pero descarta la sesión antigua en lugar de mantenerla recuperable, y pide confirmación en la terminal, por lo que no es utilizable desde un servidor que un cliente MCP inició.

• Solo Chrome, Chromium y Chrome for Testing se comparan de esta manera. Los forks se numeran de forma diferente (Vivaldi está en 7.x, el número de compilación de Edge está muy por debajo del de Chrome bajo el mismo major), así que apuntar CHROME_PATH a uno desactiva la verificación en lugar de producir un rechazo que nada podría satisfacer.

📦 Paquete MCP de Claude Desktop (antes DXT)

Requisitos previos: Claude Desktop.

Instalación con un clic para usuarios de Claude Desktop:

1. Descarga el último artefacto .mcpb desde releases

2. Haz clic en el archivo .mcpb descargado para instalarlo en Claude Desktop

3. Llama a cualquier herramienta de LinkedIn

Al iniciarse, el Paquete MCP comienza a preparar la caché compartida del navegador Patchright Chromium en segundo plano. Si llamas a una herramienta demasiado pronto, Claude mostrará un error de configuración en curso. En la primera llamada a una herramienta que necesite autenticación, el servidor abre una ventana de inicio de sesión del navegador de LinkedIn y te pide que reintentes después de iniciar sesión.

Ayuda de configuración del Paquete MCP

Comportamiento de la primera configuración:

• Claude Desktop inicia el paquete de inmediato; la configuración del navegador continúa en segundo plano

• Si el navegador Patchright Chromium aún se está descargando, reintenta la herramienta después de una breve espera

• Las descargas de navegadores gestionados se comparten en ~/.linkedin-mcp/patchright-browsers/

• La caché del navegador sigue creciendo: Patchright mantiene una revisión antigua de Chromium mientras cualquier versión instalada aún la referencie, por lo que una actualización puede dejar ambas en disco. El servidor registra una advertencia nombrando lo que contiene. Para recuperar el espacio, detén cada instancia del Servidor MCP de LinkedIn, elimina ~/.linkedin-mcp/patchright-browsers/, y deja que el próximo lanzamiento descargue el navegador actual.

• Windows, el paquete sale con DLL load failed while importing _greenlet: instala el Microsoft Visual C++ Redistributable, o reinstala un paquete que fije greenlet 3.5.5 o más reciente, cuyas ruedas publicadas para Windows llevan el runtime de C++ dentro de la extensión de nuevo. Un paquete que fije greenlet 3.3.1 hasta 3.5.4 necesita MSVCP140.dll de ese redistributable, que ni el instalador de python.org ni las compilaciones gestionadas por uv incluyen, y un greenlet compilado desde el código fuente puede necesitarlo en cualquier versión. El servidor lo nombra por sí mismo al iniciarse, y solo después de verificar que el cargador no puede producir ese DLL. Reportado como greenlet#525, corregido en greenlet#526.

Problemas de inicio de sesión:

• Asegúrate de tener solo una sesión activa de LinkedIn a la vez

• LinkedIn puede requerir una confirmación de inicio de sesión en la aplicación móvil de LinkedIn para --login

• LinkedIn puede mostrar un desafío captcha durante el inicio de sesión. Ejecuta uvx mcp-server-linkedin@latest --login, que abre un navegador donde puedes resolver captchas manualmente. Consulta la configuración de uvx para los requisitos previos.

Problemas de timeout:

• Operaciones de página fallidas (elementos no encontrados, navegación colgada): aumenta el timeout de operación de página del navegador — --timeout 10000 o TIMEOUT=10000 (milisegundos, predeterminado 5000).

• Llamadas completas a herramientas con timeout (p. ej., perfiles de varias secciones, Chromium en arranque en frío, contenedores lentos): aumenta el timeout de ejecución por herramienta — --tool-timeout 300 o TOOL_TIMEOUT=300 (segundos, predeterminado 180).

• Primera llamada a una herramienta sin sesión: si un navegador con inicio de sesión local tiene una sesión activa de LinkedIn, el servidor la autoimporta (consulta AUTO_IMPORT_FROM_BROWSER / --auto-import) en lugar de forzar un inicio de sesión manual. En macOS, el llavero puede solicitar una vez acceso a Safe Storage. Si no existe una sesión de navegador importable, recurre a abrir una ventana de inicio de sesión y espera hasta LOGIN_INLINE_WAIT segundos (predeterminado 25, máximo 45; --login-inline-wait) para que un inicio de sesión rápido se resuelva en una llamada. Si la espera transcurre, la herramienta devuelve una señal pendiente y el modelo reintenta en unos 30 segundos. Ni la autoimportación ni la espera en línea se aplican bajo Docker o cuando el servidor está vinculado a un host HTTP que no sea de bucle local. Crea la sesión en el host con --login, o usa el comando explícito de Docker --login --login-viewer.

• Los usuarios con conexiones lentas pueden necesitar valores más altos para cualquiera de estos.

Se te dice que ejecutes --login en el host cuando ya lo hiciste:

• Si las llamadas a herramientas responden "No valid LinkedIn session is available in Docker" en una máquina que no es un contenedor, el runtime se detectó incorrectamente. Esto ocurrió en hosts Linux que ejecutan un daemon de Docker para servicios no relacionados. Configura LINKEDIN_MCP_CONTAINER=false para anular la detección; true fuerza lo contrario.

🐳 Configuración de Docker

Requisitos previos: Asegúrate de que Docker esté instalado y en ejecución.

Autenticación

Inicia sesión una vez. El contenedor abre un navegador de inicio de sesión de LinkedIn que controlas desde tu propia pestaña del navegador:

# 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

Abre la URL completa que imprime el comando (lleva el token de acceso) e inicia sesión. El visor se cierra solo después; deja que el comando salga por sí solo para que la sesión se almacene por completo. Se rinde después de 30 minutos.

Mantén el montaje -v ~/.linkedin-mcp:/home/pwuser/.linkedin-mcp en cada docker run posterior, de lo contrario el servidor no puede encontrar la sesión.

Configura Claude Desktop con Docker

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

[!NOTE] Las sesiones expiran con el tiempo. Cuando las llamadas a herramientas comiencen a solicitar autenticación, repite el comando de inicio de sesión anterior, o ejecuta uvx mcp-server-linkedin@latest --login en el host.

Ayuda de configuración de Docker

Modos de transporte:

• Predeterminado (stdio): Comunicación estándar para servidores MCP locales

• Streamable HTTP: Para un servidor MCP basado en web

• Si no se especifica un transporte, el servidor usa stdio por defecto

• Una terminal interactiva sin transporte explícito muestra un mensaje de selección

Opciones de CLI:

• --log-level {DEBUG,INFO,WARNING,ERROR} - Nivel de registro (predeterminado: WARNING)

• --transport {stdio,streamable-http} - Forzar el modo de transporte (predeterminado: stdio)

• --host HOST / --port PORT / --path PATH - Dirección del servidor HTTP (predeterminados: 127.0.0.1, 8000, /mcp)

• --logout - Limpiar la sesión almacenada y cada perfil derivado de ella

• --timeout MS - Timeout para una sola operación de página (predeterminado: 5000)

• --tool-timeout SECONDS - Timeout para una llamada completa a una herramienta (predeterminado: 180). Auméntalo para raspados pesados, redes lentas o un navegador en arranque en frío.

• --login-timeout SECONDS - Cuánto tiempo espera el navegador de inicio de sesión a que termines de iniciar sesión (predeterminado: 1800; 0 = sin límite). --login-viewer termina la sesión después de 30 minutos de cualquier manera.

• --login-viewer - Con --login, muestra el navegador de inicio de sesión en una URL protegida por token en el puerto 6080. Necesita el montaje de perfil de Autenticación.

• --login-inline-wait SECONDS - Cuánto tiempo espera una llamada a una herramienta a que un inicio de sesión termine antes de decirle al modelo que reintente (predeterminado: 25, máximo 45; 0 = devolver de inmediato)

• --browser-wait SECONDS - Cuánto tiempo esperar a que otro proceso del servidor entregue el navegador compartido (predeterminado: 25, máximo 45; 0 = reportar ocupado de inmediato). Solo importa con varios clientes MCP ejecutándose a la vez.

• --browser-min-hold SECONDS - Tiempo más corto que este proceso mantiene el navegador compartido antes de entregarlo (predeterminado: 20). Limitado a 3 segundos por debajo de --browser-wait, así que auméntalo junto con ese. Más alto significa menos reinicios del navegador pero esperas más largas para otros clientes.

• --browser-idle-timeout SECONDS - Cerrar un navegador inactivo y liberar el perfil después de este tiempo sin una llamada a una herramienta (predeterminado: 600; 0 = mantenerlo abierto)

• --auto-import / --no-auto-import - Importar una sesión de un navegador local con inicio de sesión en la primera llamada a una herramienta que la necesite, antes de recurrir al inicio de sesión manual (ignorado en Docker). En macOS, el llavero puede solicitar una vez.

• --user-data-dir PATH - Directorio del perfil del navegador (predeterminado: ~/.linkedin-mcp/profile). Rotar o limpiar una sesión elimina este directorio y su padre, que contiene las cookies almacenadas y los perfiles derivados.

• --claim-profile-root - Tomar posesión de un directorio de perfil que el servidor no reclamará por sí solo, como uno cuyo padre ya contiene otros archivos. Necesario una vez por directorio.

• --chrome-path PATH - Ruta a un ejecutable de Chrome/Chromium (rara vez necesario en Docker)

• --proxy-server URL - Enrutar el tráfico del navegador a través de un proxy, como scheme://host:port. Configura la contraseña mediante PROXY_PASSWORD, que la mantiene fuera de la lista de procesos.

[!NOTE] El --login simple aún no tiene ventana visible en Docker. Añade --login-viewer y publica 127.0.0.1:6080:6080 solo para el comando de inicio de sesión de una sola vez. Docker ya tiene encabezado por defecto, así que --no-headless no cambia nada. El --daemon experimental se ignora en Docker porque su propietario puede sobrevivir a la pantalla virtual.

Ejemplo de modo HTTP (para clientes MCP basados en web):

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

Ambas mitades son necesarias y hacen trabajos distintos. --host 0.0.0.0 hace que el servidor sea accesible dentro del contenedor: un proceso vinculado a 127.0.0.1 allí no puede ser alcanzado a través de un puerto publicado en absoluto. El 127.0.0.1: delante de -p es lo que lo limita fuera, a esta máquina. Si eliminas ese prefijo, Docker publica en todas las interfaces, lo que pone un endpoint sin autenticación en tu red. El servidor no puede distinguir entre ambos, así que avisa en cualquier caso.

La publicación en bucle local limita esto a la máquina, no al contenedor. Otros contenedores en el mismo host aún pueden alcanzarlo a través de host.docker.internal dondequiera que ese nombre se resuelva, que es el valor predeterminado en Docker Desktop y OrbStack, pero no en Docker Linux nativo.

Los registros del servidor en tiempo de ejecución son emitidos por FastMCP/Uvicorn.

El servidor HTTP responde a solicitudes dirigidas a localhost o a la dirección a la que está vinculado, y rechaza otras con 421. Eso es lo que impide que un sitio web que simplemente visitas apunte un dominio a este servidor y use tu sesión de LinkedIn a través de tu propio navegador.

Alcanzar el servidor por cualquier otro nombre es rechazado, incluido un nombre de máquina en tu red y el nombre público delante de un proxy inverso. O bien haz que el proxy reescriba el Host ascendente a la dirección del backend, o nombra el host bajo el que lo sirves:

FASTMCP_HTTP_ALLOWED_HOSTS='["mcp.example"]'

Eso permite exactamente ese nombre y sigue rechazando todo lo demás. El endpoint aún no tiene autenticación, por lo que cualquier cosa accesible más allá de tu propia máquina debe estar detrás de algo que la proporcione.

Prueba con mcp inspector:

1. Instala y ejecuta mcp inspector bunx @modelcontextprotocol/inspector

2. Haz clic en la URL de token prellenada para abrir el inspector en tu navegador

3. Selecciona Streamable HTTP como Transport Type

4. Establece URL a http://localhost:8080/mcp

5. Conecta

6. Prueba las herramientas

Problemas con Docker:

• Asegúrate de que Docker esté instalado

• Comprueba si Docker está en ejecución: docker ps

• Errores de permisos en ~/.linkedin-mcp: una ejecución anterior de Docker con root puede haber creado el directorio como root. Arrégialo con sudo chown -R "$(id -u):$(id -g)" ~/.linkedin-mcp.

Problemas de inicio de sesión:

• Asegúrate de tener solo una sesión activa de LinkedIn a la vez

• LinkedIn puede requerir una confirmación de inicio de sesión en la aplicación móvil de LinkedIn para --login

• LinkedIn puede mostrar un desafío de captcha durante el inicio de sesión. Ejecuta uvx mcp-server-linkedin@latest --login, que abre un navegador donde puedes resolver captchas manualmente. Consulta la configuración de uvx para los requisitos previos.

• Si la autenticación de Docker se vuelve obsoleta después de volver a iniciar sesión en el host, reinicia Docker una vez para que pueda hacer un nuevo puente desde la nueva generación de sesión de origen.

Problemas de tiempo de espera:

• Operaciones de página que fallan (elementos no encontrados, navegación que se cuelga): aumenta el tiempo de espera de operación de página del navegador — --timeout 10000 o TIMEOUT=10000 (milisegundos, predeterminado 5000).

• Llamadas de herramienta completas que agotan el tiempo (por ejemplo, perfiles de varias secciones, Chromium en arranque en frío, contenedores lentos): aumenta el tiempo de espera de ejecución por herramienta — --tool-timeout 300 o TOOL_TIMEOUT=300 (segundos, predeterminado 180).

• Primera llamada de herramienta sin sesión: si un navegador con inicio de sesión local tiene una sesión activa de LinkedIn, el servidor la importa automáticamente (ver AUTO_IMPORT_FROM_BROWSER / --auto-import) en lugar de forzar un inicio de sesión manual. En macOS, el llavero puede solicitar una vez acceso a Safe Storage. Si no existe una sesión de navegador importable, se recurre a abrir una ventana de inicio de sesión y espera hasta LOGIN_INLINE_WAIT segundos (predeterminado 25, máximo 45; --login-inline-wait) para que un inicio de sesión rápido se resuelva en una llamada. Si el tiempo transcurre, la herramienta devuelve una señal pendiente y el modelo reintenta en unos 30 segundos. Ni la importación automática ni la espera en línea se aplican bajo Docker o cuando el servidor está vinculado a un host HTTP que no sea de bucle local. Crea la sesión en el host con --login, o usa el comando explícito de Docker --login --login-viewer.

• Los usuarios con conexiones lentas pueden necesitar valores más altos para cualquiera de ellos.

Se te dice que ejecutes --login en el host cuando ya lo hiciste:

• Si las llamadas de herramienta responden "No hay una sesión válida de LinkedIn disponible en Docker" en una máquina que no es un contenedor, el tiempo de ejecución fue mal detectado. Esto ocurrió en hosts Linux que ejecutan un daemon de Docker para servicios no relacionados. Establece LINKEDIN_MCP_CONTAINER=false para anular la detección; true fuerza lo contrario.

Usando un proxy:

La mayoría de las personas no deberían usar uno. La propia guía de LinkedIn para reducir los desafíos de seguridad es evitar una VPN o un proxy, y puntúa las direcciones desde las que una sesión inicia sesión. Una conexión doméstica que has usado durante años es una señal de confianza; un nodo de salida comercial con un historial que no puedes ver no lo es, y cambiar a uno es en sí mismo el tipo de cambio que desencadena un punto de control. Un proxy vale la pena en un caso: el servidor se ejecuta en algún lugar donde su dirección es obviamente un centro de datos, o en un país diferente del historial de la cuenta. Incluso entonces, un nodo de salida WireGuard o Tailscale en tu propia red doméstica supera a cualquier proveedor de pago, porque la dirección realmente es tuya. Si compras uno, toma una dirección ISP estática dedicada y consérvala, en lugar de un grupo residencial rotatorio.

• Enruta el navegador a través de un proxy con --proxy-server http://host:port (se aceptan http, https, socks4 y socks5). Solo se enruta el tráfico del navegador, no el transporte MCP.

• Las credenciales van en PROXY_USERNAME y PROXY_PASSWORD. No hay una bandera --proxy-password a propósito: los argumentos de línea de comandos son legibles por cualquier otro usuario en la máquina. PROXY_SERVER también acepta la forma combinada http://user:pass@host:port que la mayoría de los proveedores entregan.

• Chromium no puede autenticarse a un proxy SOCKS, por lo que las credenciales requieren un endpoint http(s). Si tu proveedor solo ofrece SOCKS5 autenticado, ejecuta un relé local que contenga las credenciales y apunta el servidor a ese.

• Las direcciones locales también pasan por el proxy. La ruta directa habitual de Chromium para localhost se elimina cuando se establece un proxy, así que agrega PROXY_BYPASS=localhost,127.0.0.1,::1 si necesitas que los objetivos locales se alcancen directamente.

• La importación automática se omite mientras hay un proxy configurado: una sesión tomada de un navegador local se creó en tu dirección real, y moverla al proxy es exactamente el cambio que desencadena un punto de control. Usa --login.

• Una contraseña de proxy incorrecta no se informa a sí misma: Chromium reintenta el desafío de autenticación hasta que la página agota el tiempo, por lo que se manifiesta como un tiempo de espera o un inicio de sesión fallido. Si las sesiones dejan de funcionar justo después de agregar un proxy, verifica las credenciales antes de asumir que la sesión expiró.

• Configura el proxy antes de crear la sesión. Ejecuta --login con el proxy ya configurado. Activar un proxy para un perfil existente mueve una sesión iniciada a una nueva IP, que es lo que desencadena un punto de control de LinkedIn. Lo mismo se aplica a --import-from-browser, que importa una sesión creada en tu IP real. Usa una sesión fija, no un grupo rotatorio, por la misma razón.

Ruta personalizada de Chrome:

• Si Chrome está instalado en una ubicación no estándar, usa --chrome-path /path/to/chrome

• También se puede establecer mediante variable de entorno: CHROME_PATH=/path/to/chrome

• En macOS y Linux, el navegador debe ser al menos tan nuevo como el que abrió tu perfil por última vez, y el servidor rechaza el lanzamiento de lo contrario. (No en Windows: un navegador allí no puede ser preguntado por su versión sin iniciar uno, por lo que la verificación está desactivada). Un navegador más antiguo puede eliminar silenciosamente las tiendas que uno más nuevo escribió, incluida la sesión guardada, y el fallo entonces se ve exactamente como un inicio de sesión expirado. El mensaje nombra ambas versiones. Volver al Chromium incluido después de ejecutar un Chrome más nuevo una vez es la forma habitual de cumplir esto; o ejecuta el navegador más nuevo de nuevo, cualquiera que haya sido, o ejecuta --login, que mueve la sesión almacenada a un lado e inicia sesión de nuevo con el navegador que tienes. --logout también lo borra, pero descarta la sesión antigua en lugar de mantenerla recuperable, y pide confirmación en la terminal, por lo que no es utilizable desde un servidor que un cliente MCP inició.

• Solo Chrome, Chromium y Chrome for Testing se comparan de esta manera. Los forks se numeran de manera diferente (Vivaldi está en 7.x, el número de compilación de Edge está muy por debajo del de Chrome bajo el mismo mayor), por lo que apuntar CHROME_PATH a uno desactiva la verificación en lugar de producir un rechazo que nada podría satisfacer.

• En la configuración de Docker documentada, esta verificación no se aplica. El contenedor nunca abre el perfil que creaste con --login; deriva el suyo propio de tus cookies, y por defecto lo reconstruye desde cero en cada inicio, por lo que no hay nada que una imagen más antigua pueda degradar. Con EXPERIMENTAL_PERSIST_DERIVED_RUNTIME se conserva el perfil derivado, y una etiqueta de imagen que retrocede entonces lo descarta y lo vuelve a derivar, nuevamente sin que tengas que hacer nada. La verificación importa en el host, donde el servidor abre ese perfil directamente. No durante --login en sí, que mueve el perfil antiguo a un lado antes de iniciar un navegador y por lo tanto nunca puede tropezar con él.

🐍 Configuración Local (Desarrollar y Contribuir)

¡Las contribuciones son bienvenidas! Consulta CONTRIBUTING.md para las pautas de arquitectura y listas de verificación. Por favor, abre un issue primero para discutir la característica o corrección de errores antes de enviar un PR.

Requisitos previos: Git y uv instalados

Instalación

# 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

El servidor local usa el mismo flujo de tiempo de ejecución gestionado que MCPB y uvx: prepara la caché del navegador Patchright Chromium en segundo plano y abre el inicio de sesión de LinkedIn en la primera llamada de herramienta que requiera autenticación. Aún puedes ejecutar uv run -m linkedin_mcp_server --login cuando quieras crear la sesión explícitamente.

Ayuda de Configuración Local

Opciones de CLI:

• --login - Abre un navegador para iniciar sesión y guardar la sesión

• --import-from-browser [BROWSER] - Reutiliza una sesión de un navegador Chromium con inicio de sesión local (chrome, chromium, brave, edge, arc, vivaldi, helium, yandex, whale, auto). La bandera sin argumento elige auto, el navegador usado más recientemente con una sesión activa de LinkedIn.

• --status - Comprueba si la sesión almacenada es válida y luego sale

• --logout - Borra la sesión almacenada

• --no-headless - Muestra la ventana del navegador (útil para depurar)

• --log-level {DEBUG,INFO,WARNING,ERROR} - Nivel de registro (predeterminado: WARNING)

• --transport {stdio,streamable-http} - Fuerza el modo de transporte (predeterminado: stdio)

• --host HOST / --port PORT / --path PATH - Dirección del servidor HTTP (predeterminados: 127.0.0.1, 8000, /mcp)

• --timeout MS - Tiempo de espera para una sola operación de página (predeterminado: 5000)

• --tool-timeout SECONDS - Tiempo de espera para una llamada de herramienta completa (predeterminado: 180). Auméntalo para raspados pesados, redes lentas o un navegador en arranque en frío.

• --user-data-dir PATH - Directorio de perfil del navegador (predeterminado: ~/.linkedin-mcp/profile). Rotar o borrar una sesión elimina este directorio y su padre, que contiene las cookies almacenadas y los perfiles derivados.

• --claim-profile-root - Tomar posesión de un directorio de perfil que el servidor no reclamará por sí solo, como uno cuyo padre ya contiene otros archivos. Necesario una vez por directorio.

• --slow-mo MS - Retraso entre acciones del navegador (predeterminado: 0, útil para depurar)

• --viewport WxH - Tamaño de la ventana gráfica (predeterminado: 1280x720). Se aplica solo al modo sin ventana; un lanzamiento con ventana usa el tamaño real de la ventana.

• --chrome-path PATH - Ruta a un ejecutable de Chrome/Chromium

• --proxy-server URL - Enruta el tráfico del navegador a través de un proxy, como scheme://host:port. Establece la contraseña mediante PROXY_PASSWORD, que la mantiene fuera de la lista de procesos.

• --help - Muestra ayuda

Nota: La mayoría de las opciones de CLI tienen equivalentes de variables de entorno. Consulta .env.example para más detalles.

Ejemplo de Modo HTTP (para clientes MCP basados en web):

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 se usa por defecto para esta configuración.

Problemas de inicio de sesión:

• Asegúrate de tener solo una sesión activa de LinkedIn a la vez

• Es posible que LinkedIn requiera una confirmación de inicio de sesión en la aplicación móvil de LinkedIn para --login

• LinkedIn puede mostrar un desafío captcha durante el inicio de sesión. El comando --login abre un navegador donde puedes resolverlo manualmente.

Problemas de scraping:

• Usa --no-headless para ver las acciones del navegador y depurar el scraping

• Añade --log-level DEBUG para ver un registro más detallado

Problemas de sesión:

• El perfil del navegador se guarda en ~/.linkedin-mcp/profile/

• Las descargas del navegador administrado se almacenan en caché en ~/.linkedin-mcp/patchright-browsers/, compartidas con las instalaciones de uvx y MCP Bundle

• La caché del navegador sigue creciendo: Patchright conserva una revisión antigua de Chromium mientras cualquier versión instalada siga haciendo referencia a ella, y un archivo de uv o un segundo worktree es esa referencia. El servidor registra una advertencia indicando qué elemento la mantiene. Para recuperar espacio, detén todas las instancias del servidor LinkedIn MCP, elimina ~/.linkedin-mcp/patchright-browsers/ y deja que el siguiente inicio descargue el navegador actual.

• Usa --logout para borrar el perfil y empezar de nuevo

Problemas de Python/Patchright:

• Comprueba la versión de Python: python --version (debe ser 3.12+)

• Reinstala Patchright: uv run patchright install chromium

• Reinstala las dependencias: uv sync --reinstall

Problemas de tiempo de espera:

• Operaciones de página que fallan (elementos no encontrados, navegación que se cuelga): aumenta el tiempo de espera de las operaciones del navegador — --timeout 10000 o TIMEOUT=10000 (milisegundos, por defecto 5000).

• Llamadas de herramienta completas que agotan el tiempo (p. ej., perfiles de varias secciones, Chromium con arranque en frío, Chromium lento): aumenta el tiempo de espera de ejecución por herramienta — --tool-timeout 300 o TOOL_TIMEOUT=300 (segundos, por defecto 180).

• Primera llamada de herramienta sin sesión: si un navegador con sesión iniciada localmente tiene una sesión de LinkedIn activa, el servidor la importa automáticamente (consulta AUTO_IMPORT_FROM_BROWSER / --auto-import) en lugar de forzar un inicio de sesión manual. En macOS, el llavero puede solicitar acceso a "Safe Storage" una vez. Si no existe una sesión de navegador importable, se abre una ventana de inicio de sesión y se espera hasta LOGIN_INLINE_WAIT segundos (por defecto 25, máximo 45; --login-inline-wait) para que un inicio de sesión rápido se resuelva en una sola llamada. Si el tiempo se agota, la herramienta devuelve una señal pendiente y el modelo reintenta en unos 30 segundos. Ni la importación automática ni la espera en línea se aplican bajo Docker o cuando el servidor está vinculado a un host que no sea de bucle local. Crea la sesión en el host con --login, o usa el comando explícito de Docker --login --login-viewer.

• Usuarios con conexiones lentas: es posible que necesiten valores más altos para cualquiera de los dos.

Te dijeron que ejecutaras --login en el host y ya lo hiciste:

• Si las llamadas de herramienta responden "No valid LinkedIn session is available in Docker" en una máquina que no es un contenedor, el entorno de ejecución se detectó incorrectamente. Esto ocurrió en hosts Linux que ejecutan un daemon de Docker para servicios no relacionados. Establece LINKEDIN_MCP_CONTAINER=false para anular la detección; true fuerza lo contrario.

Usando un proxy:

La mayoría de las personas no deberían usar uno. La propia guía de LinkedIn para reducir los desafíos de seguridad es evitar una VPN o un proxy, y puntúa las direcciones desde las que se inicia sesión. Una conexión doméstica que has usado durante años es una señal de confianza; un nodo de salida comercial con un historial que no puedes ver no lo es, y cambiar a uno es en sí mismo el tipo de cambio que activa un punto de control. Un proxy vale la pena en un caso: el servidor se ejecuta en algún lugar cuya dirección es obviamente un centro de datos, o en un país diferente al del historial de la cuenta. Incluso entonces, un nodo de salida de WireGuard o Tailscale en tu propia red doméstica supera a cualquier proveedor de pago, porque la dirección realmente es tuya. Si decides comprar uno, elige una dirección IP estática dedicada de un ISP y consérvala, en lugar de un grupo rotatorio residencial.

• Enruta el navegador a través de un proxy con --proxy-server http://host:port (se aceptan http, https, socks4 y socks5). Solo se enruta el tráfico del navegador, no el transporte de MCP.

• Las credenciales van en PROXY_USERNAME y PROXY_PASSWORD. No existe una bandera --proxy-password a propósito: los argumentos de línea de comandos son legibles por cualquier otro usuario de la máquina. PROXY_SERVER también acepta el formato combinado http://user:pass@host:port que la mayoría de los proveedores ofrecen.

• Chromium no puede autenticarse contra un proxy SOCKS, por lo que las credenciales requieren un punto final http(s). Si tu proveedor solo ofrece SOCKS5 autenticado, ejecuta un proxy local que contenga las credenciales y apunta el servidor a ese proxy local.

• Las direcciones locales también pasan por el proxy. La ruta directa habitual de Chromium para localhost se elimina cuando se configura un proxy, así que añade PROXY_BYPASS=localhost,127.0.0.1,::1 si necesitas acceder directamente a objetivos locales.

• La importación automática se omite mientras hay un proxy configurado: una sesión tomada de un navegador local se creó desde tu dirección real, y moverla al proxy es precisamente el cambio que activa un punto de control. Usa --login.

• Una contraseña de proxy incorrecta no se informa por sí misma: Chromium reintenta la autenticación hasta que la página agota el tiempo, por lo que se manifiesta como un tiempo de espera o un inicio de sesión fallido. Si las sesiones dejan de funcionar justo después de añadir un proxy, comprueba las credenciales antes de asumir que la sesión ha caducado.

• Configura el proxy antes de crear la sesión. Ejecuta --login con el proxy ya configurado. Activar un proxy en un perfil existente mueve una sesión iniciada a una nueva IP, que es lo que activa un punto de control de LinkedIn. Lo mismo se aplica a --import-from-browser, que importa una sesión creada desde tu IP real. Usa una sesión fija (sticky session), no un grupo rotatorio, por la misma razón.

Ruta personalizada de Chrome:

• Si Chrome está instalado en una ubicación no estándar, usa --chrome-path /path/to/chrome

• También se puede configurar mediante la variable de entorno: CHROME_PATH=/path/to/chrome

• En macOS y Linux, el navegador debe ser al menos tan reciente como el que abrió tu perfil por última vez; de lo contrario, el servidor rechaza el inicio. (No en Windows: allí no se puede consultar la versión de un navegador sin iniciarlo, por lo que la comprobación está desactivada). Un navegador más antiguo puede eliminar silenciosamente los datos que uno más nuevo escribió, incluida la sesión guardada, y el fallo parece entonces un inicio de sesión caducado. El mensaje menciona ambas versiones. Volver al Chromium incluido después de haber ejecutado una versión más reciente de Chrome una vez es la forma habitual de resolverlo; o bien ejecuta de nuevo el navegador más reciente, el que sea, o ejecuta --login, que aparta la sesión almacenada e inicia sesión de nuevo con el navegador que tengas. --logout también la borra, pero descarta la sesión anterior en lugar de conservarla recuperable, y solicita confirmación en la terminal, por lo que no se puede usar desde un servidor que un cliente MCP haya iniciado.

• Solo se comparan de esta manera Chrome, Chromium y Chrome for Testing. Los forks se numeran de forma diferente (Vivaldi está en 7.x, el número de compilación de Edge está muy por debajo del de Chrome en el mismo major), por lo que apuntar CHROME_PATH a uno de ellos desactiva la comprobación en lugar de producir un rechazo que nada podría satisfacer.

[!IMPORTANT] Preguntas frecuentes

¿Es seguro usarlo? ¿Me pueden banear? Esta herramienta controla una sesión real de navegador; no explota API no documentadas ni evade la autenticación. El Acuerdo de Usuario de LinkedIn prohíbe el acceso automatizado, y las cuentas que usan herramientas automatizadas pueden ser restringidas o baneadas. Úsala bajo tu propio riesgo; no hay garantía de seguridad de la cuenta. Si encuentras algún problema, házmelo saber en los Debates.

¿Qué pasa si mis agentes ejecutan demasiadas acciones? Las llamadas a herramientas se ejecutan secuencialmente a través de una cola. Eres responsable del volumen de automatización que ejecutes; úsalo con moderación y da instrucciones responsables a tus agentes.

Agradecimientos

Construido con FastMCP y Patchright.

Úsalo de acuerdo con el Acuerdo de Usuario de LinkedIn. El acceso automatizado puede violar los términos de LinkedIn y puede conllevar restricciones en la cuenta. Esta herramienta es solo para uso personal y no ofrece ninguna garantía de ningún tipo.

Licencia

Este proyecto está licenciado bajo la licencia Apache 2.0.