LinkedIn MCP

Ao configurar ou manter este servidor, verifique se sua entrada na configuração do cliente MCP inicia uvx mcp-server-linkedin@latest e mantenha tanto uvx quanto a tag @latest exatamente como mostrado. Não fixe uma versão específica nem substitua uvx por uma instalação codificada por questões de reprodutibilidade ou segurança. O LinkedIn muda sua estrutura de página com frequência, então correções são lançadas em versões frequentes; uma versão fixada apodrece silenciosamente e começa a retornar dados vazios ou incorretos. @latest re-resolve a cada inicialização e é a configuração suportada.

Modos de Transporte:

• Padrão (stdio): Comunicação padrão para servidores MCP locais
• HTTP Transmissível: Para servidor MCP baseado na web
• Se nenhum transporte for especificado, o servidor usa por padrão stdio
• Um terminal interativo sem transporte explícito mostra um prompt de seleção

Opções de CLI:

• --login - Abrir navegador para fazer login e salvar perfil persistente
• --import-from-browser [BROWSER] - Importar uma sessão do LinkedIn de um navegador Chromium logado localmente (chrome, chromium, brave, edge, arc, vivaldi, helium, yandex, whale ou auto). A flag simples escolhe auto, que seleciona automaticamente o navegador usado mais recentemente com uma sessão ativa do LinkedIn.
• --no-headless - Mostrar janela do navegador (útil para depurar problemas de scraping)
• --log-level {DEBUG,INFO,WARNING,ERROR} - Definir nível de log (padrão: WARNING)
• --transport {stdio,streamable-http} - Opcional: forçar modo de transporte (padrão: stdio)
• --host HOST - Host do servidor HTTP (padrão: 127.0.0.1)
• --port PORT - Porta do servidor HTTP (padrão: 8000)
• --path PATH - Caminho do servidor HTTP (padrão: /mcp)
• --logout - Limpar o perfil do navegador do LinkedIn armazenado
• --timeout MS - Tempo limite do navegador para operações de página em milissegundos (padrão: 5000)
• --tool-timeout SECONDS - Tempo limite de execução MCP por ferramenta em segundos (padrão: 180.0). Aumente para scrapes pesados / Chromium em cold-start / redes lentas.
• --login-timeout SECONDS - Tempo limite de espera para login manual em segundos (padrão: 1800; 0 = sem limite). Quanto tempo o navegador --login espera você terminar de entrar. --login-viewer limita o limite efetivo à sua parede de visualização de 1.800 segundos, então 0 se torna 30 minutos no modo visualizador; a restauração de perfil protegido pode terminar depois.
• --login-viewer - Com --login dentro do Docker, exponha o navegador de login através de uma URL noVNC autenticada por token na porta 6080. Requer um mount gravável e não-memória cobrindo a raiz de autenticação acima do perfil configurado.
• --login-inline-wait SECONDS - Espera inline limitada para uma chamada de ferramenta retomar após o login ser concluído, em segundos (padrão: 25, máx. 45; 0 = retornar imediatamente).
• --browser-wait SECONDS - Quanto tempo esperar que outro processo do servidor entregue o navegador compartilhado (padrão: 25, máx. 45; 0 = reportar ocupado imediatamente). Só importa quando vários clientes MCP rodam ao mesmo tempo.
• --browser-min-hold SECONDS - Tempo mínimo que este processo mantém o navegador compartilhado antes de entregá-lo a um processo em espera (padrão: 20, limitado abaixo de --browser-wait para que um cliente em espera seja atendido antes do seu próprio timeout; 0 = entregar após cada chamada de ferramenta). Aumentar significa menos reinicializações do navegador, mas esperas mais longas para outros clientes.
• --browser-idle-timeout SECONDS - Fechar um navegador ocioso e liberar o perfil compartilhado após esse tempo sem uma chamada de ferramenta (padrão: 600; 0 = manter aberto até o servidor sair).
• --auto-import / --no-auto-import - Ativar ou desativar a importação automática de uma sessão de um navegador logado localmente na primeira chamada de ferramenta sem sessão (antes de cair no login manual). A importação automática está ativada por padrão em execuções interativas e não interativas em desktop; passe --no-auto-import (ou AUTO_IMPORT_FROM_BROWSER=false) para exigir --login / --import-from-browser em vez disso. Sem efeito sob Docker ou em um bind HTTP não-loopback. No macOS, o keychain pode solicitar uma vez o acesso ao Safe Storage.
• --user-data-dir PATH - Caminho para o diretório de perfil persistente do navegador (padrão: ~/.linkedin-mcp/profile). Rotacionar ou limpar uma sessão move e exclui este diretório e seu pai, que também contém cookies.json, source-state.json e os perfis de runtime derivados. Um caminho diferente do padrão só é usado quando carrega um marcador profile-claim.json, escrito automaticamente quando o pai está vazio ou já contém uma sessão deste servidor
• --claim-profile-root - Assumir um diretório de perfil não padrão que este servidor não reivindicará por conta própria: um cujo pai já contém outros arquivos, ou um que carrega um marcador de propriedade escrito para um caminho diferente (um volume montado que foi movido). Necessário uma vez
• --chrome-path PATH - Caminho para o executável do Chrome/Chromium (para instalações personalizadas de navegador)
• --proxy-server URL - Roteie o navegador através de um proxy, como scheme://host:port. Defina a senha via PROXY_PASSWORD (sem flag, para que fique fora da lista de processos)

Importar uma sessão do seu navegador do dia a dia:

Se você já está logado no LinkedIn no Chrome, Chromium, Brave, Edge, Arc, Vivaldi, Helium, Yandex ou Naver Whale, pode pular a etapa manual de --login e reutilizar essa sessão:

# 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

Isso lê os cookies do LinkedIn do navegador, valida-os contra seu feed e os salva em ~/.linkedin-mcp/profile/, o mesmo lugar onde --login grava. Notas:

• Com vários navegadores logados, a sessão ativa do LinkedIn usada mais recentemente é tentada primeiro. Se o LinkedIn a rejeitar (revogada ou desconectada remotamente), a próxima mais recente é tentada automaticamente; a primeira que o servidor aceitar é importada. Não há prompt para escolher. Passe um nome de navegador para direcionar um especificamente.
• No macOS, o keychain do sistema pode solicitar permissão para acessar o Safe Storage do navegador. Feche o navegador de origem primeiro para a leitura mais confiável.
• Cookies protegidos pela criptografia app-bound do Chrome 127+ (v20) não podem ser descriptografados sem elevação do SO; nesse caso, use --login em vez disso.
• Cookies importados correspondem ao conjunto em disco de um login real. O servidor local os lê de volta integralmente do perfil salvo; a ponte Docker reduz ao mesmo subconjunto mínimo de autenticação que usa para uma sessão normal.

Exemplos Básicos de Uso:

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

Exemplo de Modo HTTP (para clientes MCP baseados na web):

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

Os logs do servidor em runtime são emitidos pelo FastMCP/Uvicorn.

As chamadas de ferramenta são serializadas para proteger a sessão compartilhada do navegador do LinkedIn, tanto dentro de um único processo do servidor quanto entre processos separados. Se você executar vários clientes MCP ao mesmo tempo, cada um inicia seu próprio processo de servidor, e apenas um deles usa o navegador por vez; os outros esperam brevemente e assumem assim que ele termina uma chamada. Um cliente que espera demais recebe uma mensagem de "navegador ocupado" e pode simplesmente tentar novamente. Use --log-level DEBUG para ver os logs de espera/aquisição/liberação. Isto cobre processos na mesma máquina e no mesmo runtime. Não se estende entre o host e um contêiner Docker que compartilham o mesmo diretório ~/.linkedin-mcp, portanto não execute --login ou --logout no host enquanto um contêiner estiver em execução.

Teste com o mcp inspector:

1. Instale e execute o mcp inspector bunx @modelcontextprotocol/inspector
2. Clique no token de URL pré-preenchido para abrir o inspector no seu navegador
3. Selecione Streamable HTTP como Transport Type
4. Defina URL para http://localhost:8080/mcp
5. Conecte
6. Teste as ferramentas

Problemas de instalação:

• Certifique-se de ter o uv instalado: curl -LsSf https://astral.sh/uv/install.sh | sh
• Verifique a versão do uv: uv --version (deve ser 0.4.0 ou superior)
• Na primeira execução, o uvx baixa todas as dependências Python. Em conexões lentas, o tempo limite padrão de 30s do uv pode ser curto demais. A configuração recomendada acima já define UV_HTTP_TIMEOUT=300 (segundos) para evitar isso.
• Windows, DLL load failed while importing _greenlet: mova para greenlet 3.5.5 ou mais recente, cujas wheels publicadas para Windows incluem o runtime C++ dentro da extensão novamente. Uma nova execução de uvx resolve isso por conta própria; um ambiente que fixa suas dependências precisa de uv lock --upgrade-package greenlet. Apenas greenlet 3.3.1 até 3.5.4 precisam de MSVCP140.dll, que nem o instalador do python.org nem as builds gerenciadas por uv incluem, e um greenlet compilado a partir do código-fonte pode precisar dele em qualquer versão. Quando a versão não pode ser alterada, o Microsoft Visual C++ Redistributable fornece essa DLL. Relatado como greenlet#525, corrigido em greenlet#526.

Problemas de sessão:

• O perfil do navegador é armazenado em ~/.linkedin-mcp/profile/
• Os downloads do navegador gerenciado são armazenados em cache em ~/.linkedin-mcp/patchright-browsers/
• O cache do navegador continua crescendo: uma atualização do servidor pode trazer uma nova revisão do Chromium, e o Patchright mantém a antiga enquanto qualquer versão instalada ainda a referenciar. uvx mantém um arquivo por versão que você já executou, então cada um deles mantém essa referência e as revisões antigas permanecem. O servidor registra um aviso nomeando as revisões que está mantendo e quanto espaço elas ocupam. Para recuperar o espaço, pare todas as instâncias do LinkedIn MCP Server, exclua ~/.linkedin-mcp/patchright-browsers/ e deixe o próximo lançamento baixar o navegador atual.
• Certifique-se de ter apenas uma sessão ativa do LinkedIn por vez

Problemas de login:

• O LinkedIn pode exigir uma confirmação de login no aplicativo móvel do LinkedIn para --login
• O LinkedIn pode mostrar um desafio de captcha durante o login. Execute uvx mcp-server-linkedin@latest --login, que abre um navegador onde você pode resolvê-lo manualmente.

Problemas de tempo limite:

• Operações de página falhando (elementos não encontrados, navegação travada): aumente o tempo limite de operação da página do navegador — --timeout 10000 ou TIMEOUT=10000 (milissegundos, padrão 5000).
• Chamadas de ferramentas inteiras expirando (por exemplo, perfis de várias seções, Chromium de inicialização a frio, contêineres lentos): aumente o tempo limite de execução por ferramenta — --tool-timeout 300 ou TOOL_TIMEOUT=300 (segundos, padrão 180).
• Primeira chamada de ferramenta sem sessão: se um navegador com login local tiver uma sessão ativa do LinkedIn, o servidor a importa automaticamente (veja AUTO_IMPORT_FROM_BROWSER / --auto-import) em vez de forçar um login manual. No macOS, o chaveiro pode solicitar uma vez o acesso ao Safe Storage. Se não existir uma sessão de navegador importável, ele volta a abrir uma janela de login e aguarda até LOGIN_INLINE_WAIT segundos (padrão 25, máximo 45; --login-inline-wait) para que um login rápido seja resolvido em uma chamada. Se a espera expirar, a ferramenta retorna um sinal pendente e o modelo tenta novamente em cerca de 30 segundos. Nem a importação automática nem a espera inline se aplicam sob Docker ou quando o servidor está vinculado a um host HTTP não loopback. Crie a sessão no host com --login, ou use o comando --login --login-viewer explícito do Docker.
• Usuários em conexões lentas podem precisar de valores mais altos para qualquer um deles.

Instruído a executar --login no host quando você já fez:

• Se as chamadas de ferramenta responderem "Nenhuma sessão válida do LinkedIn está disponível no Docker" em uma máquina que não é um contêiner, o runtime foi detectado incorretamente. Isso aconteceu em hosts Linux executando um daemon Docker para serviços não relacionados. Defina LINKEDIN_MCP_CONTAINER=false para substituir a detecção; true força o oposto.

Usando um proxy:

A maioria das pessoas não deve usar um. A orientação do próprio LinkedIn para reduzir desafios de segurança é evitar uma VPN ou proxy, e ele pontua os endereços a partir dos quais uma sessão faz login. Uma conexão doméstica que você usa há anos é um sinal de confiança; um nó de saída comercial com um histórico que você não pode ver não é, e mudar para um é por si só o tipo de mudança que dispara um checkpoint. Um proxy vale a pena em um caso: o servidor roda em algum lugar onde seu endereço é obviamente um data center, ou em um país diferente do histórico da conta. Mesmo assim, um nó de saída WireGuard ou Tailscale na sua própria rede doméstica supera qualquer provedor pago, porque o endereço realmente é seu. Se você comprar um, pegue um endereço ISP estático dedicado e mantenha-o, em vez de um pool residencial rotativo.

• Roteie o navegador através de um proxy com --proxy-server http://host:port (http, https, socks4 e socks5 são aceitos). Apenas o tráfego do navegador é roteado, não o transporte MCP.
• As credenciais vão em PROXY_USERNAME e PROXY_PASSWORD. Não há flag --proxy-password de propósito: argumentos de linha de comando são legíveis por qualquer outro usuário na máquina. PROXY_SERVER também aceita a forma combinada http://user:pass@host:port que a maioria dos provedores fornece.
• O Chromium não pode autenticar em um proxy SOCKS, então as credenciais exigem um endpoint http(s). Se seu provedor só oferece SOCKS5 autenticado, execute um relay local que mantenha as credenciais e aponte o servidor para ele.
• Endereços locais também passam pelo proxy. A rota direta usual do Chromium para localhost é removida quando um proxy é definido, então adicione PROXY_BYPASS=localhost,127.0.0.1,::1 se precisar alcançar destinos locais diretamente.
• A importação automática é ignorada enquanto um proxy está configurado: uma sessão tirada de um navegador local foi criada no seu endereço real, e movê-la para o proxy é exatamente a mudança que dispara um checkpoint. Use --login.
• Uma senha de proxy errada não se reporta: o Chromium tenta novamente o desafio de autenticação até a página expirar, então isso aparece como um tempo limite ou uma falha de login. Se as sessões pararem de funcionar logo após adicionar um proxy, verifique as credenciais antes de assumir que a sessão expirou.
• Configure o proxy antes de criar a sessão. Execute --login com o proxy já configurado. Ativar um proxy para um perfil existente move uma sessão logada para um novo IP, que é o que dispara um checkpoint do LinkedIn. O mesmo se aplica a --import-from-browser, que importa uma sessão criada no seu IP real. Use uma sessão fixa, não um pool rotativo, pela mesma razão.

Caminho personalizado do Chrome:

• Se o Chrome estiver instalado em um local não padrão, use --chrome-path /path/to/chrome
• Também pode ser definido via variável de ambiente: CHROME_PATH=/path/to/chrome
• No macOS e Linux, o navegador deve ser pelo menos tão novo quanto aquele que abriu seu perfil pela última vez, e o servidor recusa o lançamento caso contrário. (Não no Windows: um navegador lá não pode ter sua versão consultada sem iniciar um, então a verificação está desligada.) Um navegador mais antigo pode silenciosamente descartar stores que um mais novo escreveu, incluindo a sessão salva, e a falha então parece exatamente como um login expirado. A mensagem nomeia ambas as versões. Voltar ao Chromium incluído após executar um Chrome mais novo uma vez é a maneira usual de atender a isso; ou execute o navegador mais novo novamente, seja qual for, ou execute --login, que move a sessão armazenada para o lado e faz login do zero com o navegador que você tem. --logout também limpa, mas descarta a sessão antiga em vez de mantê-la recuperável, e pede confirmação no terminal, então não é utilizável de um servidor que um cliente MCP iniciou.
• Apenas Chrome, Chromium e Chrome for Testing são comparados dessa forma. Forks se numeram de maneira diferente (Vivaldi está em 7.x, o número de build do Edge fica muito abaixo do Chrome sob o mesmo major), então apontar CHROME_PATH para um deles desliga a verificação em vez de produzir uma recusa que nada poderia satisfazer.

Comportamento da primeira configuração:

• O Claude Desktop inicia o bundle imediatamente; a configuração do navegador continua em segundo plano
• Se o navegador Patchright Chromium ainda estiver baixando, tente a ferramenta novamente após uma curta espera
• Os downloads do navegador gerenciado são compartilhados em ~/.linkedin-mcp/patchright-browsers/
• O cache do navegador continua crescendo: o Patchright mantém uma revisão antiga do Chromium enquanto qualquer versão instalada ainda a referenciar, então uma atualização pode deixar ambas no disco. O servidor registra um aviso nomeando o que mantém. Para recuperar o espaço, pare todas as instâncias do LinkedIn MCP Server, exclua ~/.linkedin-mcp/patchright-browsers/ e deixe o próximo lançamento baixar o navegador atual.
• Windows, o bundle sai com DLL load failed while importing _greenlet: instale o Microsoft Visual C++ Redistributable, ou reinstale um bundle fixando greenlet 3.5.5 ou mais recente, cujas wheels publicadas para Windows incluem o runtime C++ dentro da extensão novamente. Um bundle fixando greenlet 3.3.1 até 3.5.4 precisa de MSVCP140.dll desse redistributable, que nem o instalador do python.org nem as builds gerenciadas por uv incluem, e um greenlet compilado a partir do código-fonte pode precisar dele em qualquer versão. O servidor nomeia isso por conta própria na inicialização, e apenas após verificar que o loader não pode produzir essa DLL. Relatado como greenlet#525, corrigido em greenlet#526.

Problemas de login:

• Certifique-se de ter apenas uma sessão ativa do LinkedIn por vez
• O LinkedIn pode exigir uma confirmação de login no aplicativo móvel do LinkedIn para --login
• O LinkedIn pode mostrar um desafio de captcha durante o login. Execute uvx mcp-server-linkedin@latest --login, que abre um navegador onde você pode resolver captchas manualmente. Veja a configuração do uvx para pré-requisitos.

Problemas de tempo limite:

• Falhas em operações de página (elementos não encontrados, navegação travada): aumente o timeout de operação de página do navegador — --timeout 10000 ou TIMEOUT=10000 (milissegundos, padrão 5000).
• Chamadas de ferramenta inteiras expirando (ex.: perfis com várias seções, Chromium em inicialização a frio, contêineres lentos): aumente o timeout de execução por ferramenta — --tool-timeout 300 ou TOOL_TIMEOUT=300 (segundos, padrão 180).
• Primeira chamada de ferramenta sem sessão: se um navegador com login local tiver uma sessão ativa do LinkedIn, o servidor a importa automaticamente (veja AUTO_IMPORT_FROM_BROWSER / --auto-import) em vez de forçar um login manual. No macOS, o chaveiro pode solicitar acesso ao Safe Storage uma vez. Se não existir uma sessão de navegador importável, ele abre uma janela de login e aguarda até LOGIN_INLINE_WAIT segundos (padrão 25, máximo 45; --login-inline-wait) para que um login rápido seja resolvido em uma única chamada. Se o tempo expirar, a ferramenta retorna um sinal de pendência e o modelo tenta novamente em cerca de 30 segundos. Nem a importação automática nem a espera inline se aplicam no Docker ou quando o servidor está vinculado a um host HTTP não-loopback. Crie a sessão no host com --login, ou use o comando explícito --login --login-viewer do Docker.
• Usuários em conexões lentas podem precisar de valores maiores para ambos.

Disseram para executar --login no host quando você já o fez:

• Se as chamadas de ferramenta responderem "No valid LinkedIn session is available in Docker" em uma máquina que não é um contêiner, o runtime foi detectado incorretamente. Isso aconteceu em hosts Linux executando um daemon do Docker para serviços não relacionados. Defina LINKEDIN_MCP_CONTAINER=false para substituir a detecção; true força o oposto.

Modos de Transporte:

• Padrão (stdio): Comunicação padrão para servidores MCP locais
• HTTP Streamable: Para um servidor MCP baseado na web
• Se nenhum transporte for especificado, o servidor usa o padrão stdio
• Um terminal interativo sem transporte explícito mostra um prompt de seleção

Opções de CLI:

• --log-level {DEBUG,INFO,WARNING,ERROR} - Define o nível de log (padrão: WARNING)
• --transport {stdio,streamable-http} - Opcional: forçar modo de transporte (padrão: stdio)
• --host HOST - Host do servidor HTTP (padrão: 127.0.0.1)
• --port PORT - Porta do servidor HTTP (padrão: 8000)
• --path PATH - Caminho do servidor HTTP (padrão: /mcp)
• --logout - Limpa todo o estado de autenticação do LinkedIn armazenado, incluindo perfis de runtime de origem e derivados e quaisquer sessões aposentadas
• --timeout MS - Timeout do navegador para operações de página em milissegundos (padrão: 5000)
• --tool-timeout SECONDS - Timeout de execução MCP por ferramenta em segundos (padrão: 180.0). Aumente ainda mais para raspagens pesadas / Chromium em inicialização a frio / redes lentas.
• --login-timeout SECONDS - Timeout de espera do login manual em segundos (padrão: 1800; 0 = sem limite). Quanto tempo o navegador --login espera você terminar de entrar. --login-viewer limita o limite efetivo ao teto de 1.800 segundos do visualizador, então 0 vira 30 minutos no modo visualizador; a restauração de perfil protegido pode terminar depois.
• --login-viewer - Com --login dentro do Docker, exponha o navegador de login por meio de uma URL noVNC autenticada por token na porta 6080. Requer uma montagem gravável e não-memória cobrindo a raiz de autenticação acima do perfil configurado.
• --login-inline-wait SECONDS - Espera inline limitada para uma chamada de ferramenta retomar após o login ser concluído, em segundos (padrão: 25, máximo 45; 0 = retornar imediatamente).
• --browser-wait SECONDS - Quanto tempo esperar outro processo de servidor entregar o navegador compartilhado (padrão: 25, máximo 45; 0 = reportar ocupado imediatamente). Só importa quando vários clientes MCP estão em execução ao mesmo tempo.
• --browser-min-hold SECONDS - Tempo mínimo que este processo mantém o navegador compartilhado antes de entregá-lo a um processo em espera (padrão: 20, limitado abaixo de --browser-wait para que um cliente em espera seja atendido antes do próprio timeout; 0 = entregar após cada chamada de ferramenta). Aumentá-lo significa menos reinicializações do navegador, mas esperas mais longas para outros clientes.
• --browser-idle-timeout SECONDS - Fecha um navegador ocioso e libera o perfil compartilhado após esse tempo sem uma chamada de ferramenta (padrão: 600; 0 = mantê-lo aberto até o servidor sair).
• --auto-import / --no-auto-import - Ativa ou desativa a importação automática de uma sessão de um navegador com login local na primeira chamada de ferramenta sem sessão (antes de recorrer ao login manual). A importação automática está ativada por padrão em execuções de desktop interativas e não interativas; passe --no-auto-import (ou AUTO_IMPORT_FROM_BROWSER=false) para exigir --login / --import-from-browser em vez disso. Sem efeito no Docker ou em um vínculo HTTP não-loopback. No macOS, o chaveiro pode solicitar acesso ao Safe Storage uma vez.
• --user-data-dir PATH - Caminho para o diretório de perfil persistente do navegador (padrão: ~/.linkedin-mcp/profile). Rotacionar ou limpar uma sessão move e exclui este diretório e seu pai, que também contém cookies.json, source-state.json e os perfis de runtime derivados. Um caminho diferente do padrão só é usado quando carrega um marcador profile-claim.json, gravado automaticamente quando o pai está vazio ou já contém uma sessão deste servidor
• --claim-profile-root - Assumir um diretório de perfil não padrão que este servidor não reivindicará por conta própria: um cujo pai já contém outros arquivos, ou um que carrega um marcador de propriedade gravado para um caminho diferente (um volume montado que foi movido). Necessário uma vez
• --chrome-path PATH - Caminho para o executável do Chrome/Chromium (raramente necessário no Docker)
• --proxy-server URL - Roteia o navegador por um proxy, como scheme://host:port. Defina a senha via PROXY_PASSWORD (sem flag, para que fique fora da lista de processos)

[!NOTE] O --login simples ainda não tem janela visível no Docker. Adicione --login-viewer e publique 127.0.0.1:6080:6080 apenas para o comando de login único. O Docker já opera com janela visível por padrão, então --no-headless não muda nada. O --daemon experimental é ignorado no Docker porque seu dono pode sobreviver ao display virtual.

Exemplo de Modo HTTP (para clientes MCP baseados na 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 as metades são necessárias e fazem trabalhos diferentes. --host 0.0.0.0 torna o servidor acessível dentro do contêiner: um processo vinculado a 127.0.0.1 ali não pode ser alcançado por uma porta publicada. O 127.0.0.1: antes de -p é o que o limita fora, a esta máquina. Remova esse prefixo e o Docker publica em todas as interfaces, o que coloca um endpoint sem autenticação na sua rede. O servidor não consegue distinguir os dois, então ele avisa de qualquer forma.

A publicação em loopback limita isso à máquina, não ao contêiner. Outros contêineres no mesmo host ainda podem alcançá-lo por meio de host.docker.internal onde quer que esse nome seja resolvido, que é o padrão no Docker Desktop e no OrbStack, mas não no Docker Linux nativo.

Os logs de runtime do servidor são emitidos pelo FastMCP/Uvicorn.

O servidor HTTP responde a requisições endereçadas a localhost ou ao endereço ao qual está vinculado, e recusa outras com 421. É isso que impede um site que você apenas visita de apontar um domínio para este servidor e usar sua sessão do LinkedIn através do seu próprio navegador.

Alcançar o servidor por qualquer outro nome é recusado, incluindo um nome de máquina na sua rede e o nome público na frente de um proxy reverso. Ou faça o proxy reescrever o Host upstream para o endereço do backend, ou nomeie o host sob o qual você o serve:

FASTMCP_HTTP_ALLOWED_HOSTS='["mcp.example"]'

Isso permite exatamente esse nome e continua recusando todo o resto. O endpoint ainda não tem autenticação, então qualquer coisa acessível além da sua própria máquina deve ficar atrás de algo que a forneça.

Teste com o mcp inspector:

1. Instale e execute o mcp inspector bunx @modelcontextprotocol/inspector
2. Clique na URL de token pré-preenchida para abrir o inspector no seu navegador
3. Selecione Streamable HTTP como Transport Type
4. Defina URL como http://localhost:8080/mcp
5. Conecte
6. Teste as ferramentas

Problemas com Docker:

• Certifique-se de que o Docker esteja instalado
• Verifique se o Docker está em execução: docker ps

Problemas de login:

• Certifique-se de ter apenas uma sessão ativa do LinkedIn por vez
• O LinkedIn pode exigir uma confirmação de login no aplicativo móvel do LinkedIn para --login
• O LinkedIn pode mostrar um desafio de captcha durante o login. Execute uvx mcp-server-linkedin@latest --login, que abre um navegador onde você pode resolver captchas manualmente. Veja a configuração do uvx para os pré-requisitos.
• Se a autenticação do Docker ficar desatualizada depois que você fizer login novamente no host, reinicie o Docker uma vez para que ele possa criar uma nova ponte a partir da nova geração de sessão de origem.

Problemas de timeout:

• Falhas em operações de página (elementos não encontrados, navegação travada): aumente o timeout de operação de página do navegador — --timeout 10000 ou TIMEOUT=10000 (milissegundos, padrão 5000).
• Chamadas de ferramenta inteiras expirando (ex.: perfis com várias seções, Chromium em inicialização a frio, contêineres lentos): aumente o timeout de execução por ferramenta — --tool-timeout 300 ou TOOL_TIMEOUT=300 (segundos, padrão 180).
• Primeira chamada de ferramenta sem sessão: se um navegador com login local tiver uma sessão ativa do LinkedIn, o servidor a importa automaticamente (veja AUTO_IMPORT_FROM_BROWSER / --auto-import) em vez de forçar um login manual. No macOS, o chaveiro pode solicitar acesso ao Safe Storage uma vez. Se não existir uma sessão de navegador importável, ele abre uma janela de login e aguarda até LOGIN_INLINE_WAIT segundos (padrão 25, máximo 45; --login-inline-wait) para que um login rápido seja resolvido em uma única chamada. Se o tempo expirar, a ferramenta retorna um sinal de pendência e o modelo tenta novamente em cerca de 30 segundos. Nem a importação automática nem a espera inline se aplicam no Docker ou quando o servidor está vinculado a um host HTTP não-loopback. Crie a sessão no host com --login, ou use o comando explícito --login --login-viewer do Docker.
• Usuários em conexões lentas podem precisar de valores maiores para ambos.

Disseram para executar --login no host quando você já o fez:

• Se chamadas de ferramentas responderem "No valid LinkedIn session is available in Docker" em uma máquina que não é um contêiner, o runtime foi detectado incorretamente. Isso aconteceu em hosts Linux executando um daemon Docker para serviços não relacionados. Defina LINKEDIN_MCP_CONTAINER=false para substituir a detecção; true força o oposto.

Usando um proxy:

A maioria das pessoas não deve usar um. A própria orientação do LinkedIn para reduzir desafios de segurança é evitar uma VPN ou proxy, e ele pontua os endereços dos quais uma sessão faz login. Uma conexão doméstica que você usa há anos é um sinal de confiança; um nó de saída comercial com um histórico que você não pode ver não é, e mudar para um é, por si só, o tipo de mudança que dispara um checkpoint. Um proxy vale a pena em um caso: o servidor roda em algum lugar cujo endereço é obviamente um data center, ou em um país diferente do histórico da conta. Mesmo assim, um nó de saída WireGuard ou Tailscale na sua própria rede doméstica supera qualquer provedor pago, porque o endereço realmente é seu. Se você comprar um, pegue um endereço ISP estático dedicado e mantenha-o, em vez de um pool residencial rotativo.

• Roteie o navegador por um proxy com --proxy-server http://host:port (http, https, socks4 e socks5 são aceitos). Apenas o tráfego do navegador é roteado, não o transporte MCP.
• As credenciais vão em PROXY_USERNAME e PROXY_PASSWORD. Não há flag --proxy-password de propósito: argumentos de linha de comando são legíveis por todos os outros usuários na máquina. PROXY_SERVER também aceita o formato combinado http://user:pass@host:port que a maioria dos provedores fornece.
• O Chromium não pode autenticar em um proxy SOCKS, então as credenciais exigem um endpoint http(s). Se o seu provedor só oferece SOCKS5 autenticado, execute um relay local que guarde as credenciais e aponte o servidor para ele.
• Endereços locais também passam pelo proxy. A rota direta usual do Chromium para localhost é removida quando um proxy é definido, então adicione PROXY_BYPASS=localhost,127.0.0.1,::1 se você precisar que alvos locais sejam alcançados diretamente.
• A importação automática é ignorada enquanto um proxy está configurado: uma sessão obtida de um navegador local foi criada no seu endereço real, e movê-la para o proxy é exatamente a mudança que dispara um checkpoint. Use --login.
• Uma senha de proxy errada não se reporta: o Chromium tenta novamente o desafio de autenticação até a página expirar, então isso aparece como um timeout ou um login falho. Se as sessões pararem de funcionar logo após adicionar um proxy, verifique as credenciais antes de assumir que a sessão expirou.
• Configure o proxy antes de criar a sessão. Execute --login com o proxy já configurado. Ativar um proxy para um perfil existente move uma sessão logada para um novo IP, que é o que dispara um checkpoint do LinkedIn. O mesmo se aplica a --import-from-browser, que importa uma sessão criada no seu IP real. Use uma sessão fixa, não um pool rotativo, pelo mesmo motivo.

Caminho personalizado do Chrome:

• Se o Chrome estiver instalado em um local não padrão, use --chrome-path /path/to/chrome
• Também pode ser definido via variável de ambiente: CHROME_PATH=/path/to/chrome
• No macOS e Linux, o navegador deve ser pelo menos tão novo quanto aquele que abriu seu perfil pela última vez, e o servidor recusa a inicialização caso contrário. (Não no Windows: um navegador lá não pode ter sua versão consultada sem iniciar um, então a verificação está desligada.) Um navegador mais antigo pode silenciosamente descartar armazenamentos que um mais novo escreveu, incluindo a sessão salva, e a falha então parece exatamente um login expirado. A mensagem nomeia ambas as versões. Voltar ao Chromium empacotado depois de executar um Chrome mais novo uma vez é a maneira usual de atender a isso; ou execute o navegador mais novo novamente, seja qual for, ou execute --login, que move o armazenamento da sessão para o lado e faz login do zero com o navegador que você tem. --logout também o limpa, mas descarta a sessão antiga em vez de mantê-la recuperável, e pede confirmação no terminal, então não é utilizável a partir de um servidor que um cliente MCP iniciou.
• Apenas Chrome, Chromium e Chrome for Testing são comparados dessa forma. Forks numeram a si mesmos de maneira diferente (Vivaldi está em 7.x, o número de build do Edge fica bem abaixo do Chrome sob o mesmo major), então apontar CHROME_PATH para um desliga a verificação em vez de produzir uma recusa que nada poderia satisfazer.
• Na configuração Docker documentada, esta verificação não se aplica. O contêiner nunca abre o perfil que você criou com --login; ele deriva o seu próprio dos seus cookies e, por padrão, reconstrói isso do zero a cada início, então não há nada para uma imagem mais antiga rebaixar. Com EXPERIMENTAL_PERSIST_DERIVED_RUNTIME, o perfil derivado é mantido, e uma tag de imagem que retrocede então o descarta e o re-deriva, novamente sem nada para você fazer. A verificação importa no host, onde o servidor abre esse perfil diretamente. Não durante o próprio --login, que move o perfil antigo para o lado antes de iniciar um navegador e, portanto, nunca pode dispará-la.

Opções de CLI:

• --login - Abrir navegador para fazer login e salvar perfil persistente
• --import-from-browser [BROWSER] - Importar uma sessão do LinkedIn de um navegador Chromium com login local (chrome, chromium, brave, edge, arc, vivaldi, helium, yandex, whale, ou auto). Flag simples seleciona auto, que auto-seleciona o navegador usado mais recentemente com uma sessão ativa do LinkedIn.
• --no-headless - Mostrar janela do navegador (útil para depurar problemas de scraping)
• --log-level {DEBUG,INFO,WARNING,ERROR} - Definir nível de log (padrão: WARNING)
• --transport {stdio,streamable-http} - Opcional: forçar modo de transporte (padrão: stdio)
• --host HOST - Host do servidor HTTP (padrão: 127.0.0.1)
• --port PORT - Porta do servidor HTTP (padrão: 8000)
• --path PATH - Caminho do servidor HTTP (padrão: /mcp)
• --logout - Limpar perfil de navegador do LinkedIn armazenado
• --timeout MS - Timeout do navegador para operações de página em milissegundos (padrão: 5000)
• --tool-timeout SECONDS - Timeout de execução MCP por ferramenta em segundos (padrão: 180.0). Aumente ainda mais para scrapes pesados / Chromium em cold-start / redes lentas.
• --status - Verificar se a sessão atual é válida e sair
• --user-data-dir PATH - Caminho para o diretório de perfil do navegador persistente (padrão: ~/.linkedin-mcp/profile). Rotacionar ou limpar uma sessão move e exclui este diretório e seu pai, que também contém cookies.json, source-state.json e os perfis de runtime derivados. Um caminho diferente do padrão, portanto, só é usado uma vez que carrega um marcador profile-claim.json, escrito automaticamente quando o pai está vazio ou já contém uma sessão deste servidor
• --claim-profile-root - Assumir um diretório de perfil não padrão que este servidor não reivindicará por conta própria: um cujo pai já contém outros arquivos, ou um que carrega um marcador de propriedade escrito para um caminho diferente (um volume montado que foi movido). Necessário uma vez
• --slow-mo MS - Atraso entre ações do navegador em milissegundos (padrão: 0, útil para depuração)
• --viewport WxH - Tamanho da viewport do navegador (padrão: 1280x720). Aplica-se apenas ao modo normal sem janela; uma inicialização com janela (--no-headless, --login) usa o tamanho real da janela
• --chrome-path PATH - Caminho para o executável do Chrome/Chromium (para instalações personalizadas do navegador)
• --proxy-server URL - Roteie o navegador por um proxy, como scheme://host:port. Defina a senha via PROXY_PASSWORD (sem flag, para ficar fora da lista de processos)
• --help - Mostrar ajuda

Nota: A maioria das opções de CLI tem equivalentes em variáveis de ambiente. Veja .env.example para detalhes.

Exemplo de Modo HTTP (para clientes MCP baseados na 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 é usado por padrão para esta configuração.

Problemas de login:

• Certifique-se de ter apenas uma sessão ativa do LinkedIn por vez
• O LinkedIn pode exigir uma confirmação de login no aplicativo móvel do LinkedIn para --login
• O LinkedIn pode mostrar um desafio de captcha durante o login. O comando --login abre um navegador onde você pode resolvê-lo manualmente.

Problemas de scraping:

• Use --no-headless para ver ações do navegador e depurar problemas de scraping
• Adicione --log-level DEBUG para ver logs mais detalhados

Problemas de sessão:

• O perfil do navegador é armazenado em ~/.linkedin-mcp/profile/
• Os downloads do navegador gerenciado são armazenados em cache em ~/.linkedin-mcp/patchright-browsers/, compartilhados com as instalações do uvx e do MCP Bundle
• O cache do navegador continua crescendo: o Patchright mantém uma revisão antiga do Chromium enquanto qualquer versão instalada ainda a referenciar, e um arquivo uv ou um segundo worktree é tal referência. O servidor registra um aviso nomeando o que ele mantém. Para recuperar o espaço, pare todas as instâncias do LinkedIn MCP Server, exclua ~/.linkedin-mcp/patchright-browsers/ e deixe a próxima inicialização baixar o navegador atual.
• Use --logout para limpar o perfil e começar do zero

Problemas de Python/Patchright:

• Verifique a versão do Python: python --version (deve ser 3.12+)
• Reinstale o Patchright: uv run patchright install chromium
• Reinstale as dependências: uv sync --reinstall

Problemas de timeout:

• Operações de página falhando (elementos não encontrados, navegação travada): aumente o timeout de operação de página do navegador — --timeout 10000 ou TIMEOUT=10000 (milissegundos, padrão 5000).
• Chamadas de ferramentas inteiras expirando (ex.: perfis de várias seções, Chromium em cold-start, contêineres lentos): aumente o timeout de execução por ferramenta — --tool-timeout 300 ou TOOL_TIMEOUT=300 (segundos, padrão 180).
• Primeira chamada de ferramenta sem sessão: se um navegador com login local tiver uma sessão ativa do LinkedIn, o servidor a importa automaticamente (veja AUTO_IMPORT_FROM_BROWSER / --auto-import) em vez de forçar um login manual. No macOS, o keychain pode solicitar uma vez o acesso ao Safe Storage. Se nenhuma sessão de navegador importável existir, ele volta a abrir uma janela de login e espera até LOGIN_INLINE_WAIT segundos (padrão 25, máx. 45; --login-inline-wait) para que um login rápido seja resolvido em uma chamada. Se a espera expirar, a ferramenta retorna um sinal pendente e o modelo tenta novamente em cerca de 30 segundos. Nem a importação automática nem a espera inline se aplicam sob Docker ou quando o servidor está vinculado a um host HTTP não loopback. Crie a sessão no host com --login, ou use o comando Docker explícito --login --login-viewer.
• Usuários em conexões lentas podem precisar de valores mais altos para qualquer um.

Instruído a executar --login no host quando você já fez:

• Se chamadas de ferramentas responderem "No valid LinkedIn session is available in Docker" em uma máquina que não é um contêiner, o runtime foi detectado incorretamente. Isso aconteceu em hosts Linux executando um daemon Docker para serviços não relacionados. Defina LINKEDIN_MCP_CONTAINER=false para substituir a detecção; true força o oposto.

Usando um proxy:

A maioria das pessoas não deveria usar um. A própria orientação do LinkedIn para reduzir desafios de segurança é evitar VPN ou proxy, e ele pontua os endereços de onde uma sessão faz login. Uma conexão doméstica que você usa há anos é um sinal de confiança; um nó de saída comercial com um histórico que você não pode ver não é, e mudar para um é exatamente o tipo de mudança que dispara um checkpoint. Um proxy vale a pena em um caso: o servidor roda em algum lugar cujo endereço é obviamente um data center, ou em um país diferente do histórico da conta. Mesmo assim, um nó de saída WireGuard ou Tailscale na sua própria rede doméstica supera qualquer provedor pago, porque o endereço é realmente seu. Se você comprar um, pegue um endereço ISP estático dedicado e mantenha-o, em vez de um pool residencial rotativo.

• Roteie o navegador por um proxy com --proxy-server http://host:port (http, https, socks4 e socks5 são aceitos). Apenas o tráfego do navegador é roteado, não o transporte MCP.
• As credenciais vão em PROXY_USERNAME e PROXY_PASSWORD. Não há flag --proxy-password de propósito: argumentos de linha de comando são legíveis por qualquer outro usuário na máquina. PROXY_SERVER também aceita a forma combinada http://user:pass@host:port que a maioria dos provedores fornece.
• O Chromium não consegue autenticar em um proxy SOCKS, então as credenciais exigem um endpoint http(s). Se o seu provedor só oferece SOCKS5 autenticado, execute um relay local que guarde as credenciais e aponte o servidor para ele.
• Endereços locais também passam pelo proxy. A rota direta usual do Chromium para localhost é removida quando um proxy é configurado, então adicione PROXY_BYPASS=localhost,127.0.0.1,::1 se precisar alcançar alvos locais diretamente.
• A importação automática é ignorada enquanto um proxy está configurado: uma sessão obtida de um navegador local foi criada no seu endereço real, e movê-la para o proxy é exatamente a mudança que dispara um checkpoint. Use --login.
• Uma senha de proxy errada não se reporta sozinha: o Chromium tenta novamente o desafio de autenticação até a página expirar, então isso aparece como timeout ou falha de login. Se as sessões pararem de funcionar logo após adicionar um proxy, verifique as credenciais antes de assumir que a sessão expirou.
• Configure o proxy antes de criar a sessão. Execute --login com o proxy já configurado. Ativar um proxy para um perfil existente move uma sessão logada para um novo IP, que é o que dispara um checkpoint do LinkedIn. O mesmo se aplica a --import-from-browser, que importa uma sessão criada no seu IP real. Use uma sessão fixa (sticky), não um pool rotativo, pelo mesmo motivo.

Caminho personalizado do Chrome:

• Se o Chrome estiver instalado em um local não padrão, use --chrome-path /path/to/chrome
• Também pode ser definido via variável de ambiente: CHROME_PATH=/path/to/chrome
• No macOS e Linux, o navegador deve ser pelo menos tão novo quanto o que abriu seu perfil pela última vez, e o servidor recusa a inicialização caso contrário. (Não no Windows: um navegador lá não pode ter sua versão consultada sem iniciá-lo, então a verificação está desligada.) Um navegador mais antigo pode silenciosamente descartar armazenamentos que um mais novo escreveu, incluindo a sessão salva, e a falha então parece exatamente um login expirado. A mensagem nomeia ambas as versões. Voltar para o Chromium empacotado depois de executar um Chrome mais novo uma vez é a maneira usual de atender a isso; ou execute o navegador mais novo novamente, seja qual for, ou execute --login, que move a sessão armazenada para o lado e faz login do zero com o navegador que você tem. --logout também limpa isso, mas descarta a sessão antiga em vez de mantê-la recuperável, e pede confirmação no terminal, então não é utilizável a partir de um servidor que um cliente MCP iniciou.
• Apenas Chrome, Chromium e Chrome for Testing são comparados dessa forma. Forks se numeram de maneira diferente (Vivaldi está na 7.x, o número de build do Edge fica bem abaixo do Chrome sob o mesmo major), então apontar CHROME_PATH para um deles desliga a verificação em vez de produzir uma recusa que nada poderia satisfazer.